南边逐渐进入一年中最好的时节，用户也开始纷扰起来。看了眼数据，活泼用户已经double很远，昆山软件开发，顿时triple了。

一日睡眼惺忪的清晨，昆山软件开发，正看着数据冷静yy时候，线上开始告警…… MMP，用户早上纷扰的增长比想象好快呢。同事第一时间打开立体监控瞥了一眼，团结处事的错误日志，很快把问题锁定到了一个Redis实例（事实上，自从立体监控上线今后，根基上处理惩罚流程从以前的 < 80%时间定位问题 + 20%办理问题 > 酿成了 < 少量时间确认问题 + 办理问题 >）。团队处理惩罚效率照旧挺快的，原因定位到AOF耐久化：

这是其时的Redis设置：

127.0.0.1:6379> config get *append*
1) "no-appendfsync-on-rewrite"
2) "no"
3) "appendonly"
4) "yes"
5) "appendfsync"
6) "everysec"

从设置看，原因理论上就很清楚了：我们的这个Redis示例利用AOF举办耐久化(appendonly)，appendfsync计策回收的是everysec刷盘。可是AOF跟着时间推移，文件会越来越大，因此，Redis尚有一个rewrite计策，实现AOF文件的减肥，可是功效的幂等的。我们no-appendfsync-on-rewrite的计策是 no. 这就会导致在举办rewrite操纵时，appendfsync会被阻塞。假如当前AOF文件很大，那么相应的rewrite时间会变长，appendfsync被阻塞的时间也会更长。

这不是什么新问题，许多开启AOF的业务场景城市碰着这个问题。办理的步伐有这么几个：

1. 将no-appendfsync-on-rewrite配置为yes. 这样可以制止与appendfsync争用文件句柄，可是在rewrite期间的AOF有丢失的风险。
2. 给当前Redis实例添加slave节点，当前节点配置为master, 然后master节点封锁AOF，slave节点开启AOF。这样的方法的风险是假如master挂掉，尚没有同步到salve的数据会丢失。

我们采纳了折中的方法：在master节点配置将no-appendfsync-on-rewrite配置为yes，同时添加slave节点。

理论上，劳务派遣管理系统，问题应该办理了吧？啊蛤，简直是理论上。

修改后第一天，问题又呈现了。惊不惊喜，意不料外？

于是，小同伴又从头温习了一下其时出问题时候的Redis日志：

有两个点较量可以：

1. 前几条AOF日志告警日志产生在晚上3~5点之间，而谁人时候，我们整个系统负载长短常低的。
2. 清晨的告警日志不是某一个Redis实例告警，而是该呆板上的所有Redis实例都在告警。

在这种百思不得骑姐的环境下，团结汗青上被坑的履历，我们99%断定是我们利用的云主机存在问题。

这个问题有大概是宿主机超售太多导致单个租户实际能利用到的云盘IO比标称值低，也有大概是租户断绝做得欠好，导致坏邻人太过占用IO影响其他租户。

这个很好领略：我们利用的是阿里云的云SSD，而阿里云今朝的架构还没有做到计较和存储疏散，即计较和存储的网络IO是共享的。

虽然今朝这个问题还没有实锤，我们也还在跟阿里云努力相同办理。同时为了制止给本身惹贫苦，我照旧留了1%的其他大概性。

参考资料

Redis相关—Redis耐久化