一次非典型性 Redis 阻塞总结-

沙海

3185
文章

2
评论

2021年4月19日04:17:46Java评论34字数 1672阅读5分34秒阅读模式

摘要

速读摘要

速读摘要文章源自JAVA秀-https://www.javaxiu.com/18477.html

南方逐渐进入一年中最好的时节，用户也开始骚动起来。我们的这个Redis示例使用AOF进行持久化(appendonly)，appendfsync策略采用的是everysec刷盘。这样的方式的风险是如果master挂掉，尚没有同步到salve的数据会丢失。清晨的告警日志不是某一个Redis实例告警，而是该机器上的所有Redis实例都在告警。我们使用的是阿里云的云SSD，而阿里云目前的架构还没有做到计算和存储分离，即计算和存储的网络IO是共享的。文章源自JAVA秀-https://www.javaxiu.com/18477.html

原文约 1261 字 | 图片 10 张 | 建议阅读 3 分钟 | 评价反馈文章源自JAVA秀-https://www.javaxiu.com/18477.html

一次非典型性 Redis 阻塞总结

侠梦的开发笔记文章源自JAVA秀-https://www.javaxiu.com/18477.html

一次非典型性 Redis 阻塞总结文章源自JAVA秀-https://www.javaxiu.com/18477.html

点击上方蓝字，关注我们文章源自JAVA秀-https://www.javaxiu.com/18477.html

一次非典型性 Redis 阻塞总结文章源自JAVA秀-https://www.javaxiu.com/18477.html

来源：行思錄，文章源自JAVA秀-https://www.javaxiu.com/18477.html
liudanking.com/performance/一次非典型性-redis-阻塞总结/文章源自JAVA秀-https://www.javaxiu.com/18477.html

南方逐渐进入一年中最好的时节，用户也开始骚动起来。看了眼数据，活跃用户已经double很远，马上triple了。文章源自JAVA秀-https://www.javaxiu.com/18477.html

一日睡眼惺忪的清晨，正看着数据默默yy时候，线上开始告警…… MMP，用户早上骚动的增长比想象好快呢。同事第一时间打开立体监控瞥了一眼，结合服务的错误日志，很快把问题锁定到了一个Redis实例（事实上，自从立体监控上线以后，基本上处理流程从以前的 < 80%时间定位问题 + 20%解决问题 > 变成了 < 少量时间确认问题 + 解决问题 >）。团队处理效率还是挺快的，原因定位到AOF持久化：文章源自JAVA秀-https://www.javaxiu.com/18477.html

一次非典型性 Redis 阻塞总结文章源自JAVA秀-https://www.javaxiu.com/18477.html

这是当时的Redis配置：文章源自JAVA秀-https://www.javaxiu.com/18477.html

127.0.0.1:6379> config get *append*文章源自JAVA秀-https://www.javaxiu.com/18477.html
1) "no-appendfsync-on-rewrite"文章源自JAVA秀-https://www.javaxiu.com/18477.html
2) "no"文章源自JAVA秀-https://www.javaxiu.com/18477.html
3) "appendonly"文章源自JAVA秀-https://www.javaxiu.com/18477.html
4) "yes"文章源自JAVA秀-https://www.javaxiu.com/18477.html
5) "appendfsync"文章源自JAVA秀-https://www.javaxiu.com/18477.html
6) "everysec"文章源自JAVA秀-https://www.javaxiu.com/18477.html

从配置看，原因理论上就很清楚了：我们的这个Redis示例使用AOF进行持久化(appendonly)，appendfsync策略采用的是everysec刷盘。但是AOF随着时间推移，文件会越来越大，因此，Redis还有一个rewrite策略，实现AOF文件的减肥，但是结果的幂等的。我们no-appendfsync-on-rewrite的策略是 no. 这就会导致在进行rewrite操作时，appendfsync会被阻塞。如果当前AOF文件很大，那么相应的rewrite时间会变长，appendfsync被阻塞的时间也会更长。文章源自JAVA秀-https://www.javaxiu.com/18477.html

这不是什么新问题，很多开启AOF的业务场景都会遇到这个问题。解决的办法有这么几个：文章源自JAVA秀-https://www.javaxiu.com/18477.html

将no-appendfsync-on-rewrite设置为yes. 这样可以避免与appendfsync争用文件句柄，但是在rewrite期间的AOF有丢失的风险。文章源自JAVA秀-https://www.javaxiu.com/18477.html
给当前Redis实例添加slave节点，当前节点设置为master, 然后master节点关闭AOF，slave节点开启AOF。这样的方式的风险是如果master挂掉，尚没有同步到salve的数据会丢失。文章源自JAVA秀-https://www.javaxiu.com/18477.html

我们采取了折中的方式：在master节点设置将no-appendfsync-on-rewrite设置为yes，同时添加slave节点。文章源自JAVA秀-https://www.javaxiu.com/18477.html

理论上，问题应该解决了吧？啊蛤，的确是理论上。文章源自JAVA秀-https://www.javaxiu.com/18477.html

修改后第一天，问题又出现了。惊不惊喜，意不意外？文章源自JAVA秀-https://www.javaxiu.com/18477.html

于是，小伙伴又重新复习了一下当时出问题时候的Redis日志：文章源自JAVA秀-https://www.javaxiu.com/18477.html

一次非典型性 Redis 阻塞总结文章源自JAVA秀-https://www.javaxiu.com/18477.html

有两个点比较可以：文章源自JAVA秀-https://www.javaxiu.com/18477.html

前几条AOF日志告警日志发生在晚上3~5点之间，而那个时候，我们整个系统负载是非常低的。文章源自JAVA秀-https://www.javaxiu.com/18477.html
清晨的告警日志不是某一个Redis实例告警，而是该机器上的所有Redis实例都在告警。文章源自JAVA秀-https://www.javaxiu.com/18477.html

在这种百思不得骑姐的情况下，结合历史上被坑的经验，我们99%断定是我们使用的云主机存在问题。文章源自JAVA秀-https://www.javaxiu.com/18477.html

这个问题有可能是宿主机超售太多导致单个租户实际能使用到的云盘IO比标称值低，也有可能是租户隔离做得不好，导致坏邻居过度占用IO影响其他租户。文章源自JAVA秀-https://www.javaxiu.com/18477.html

这个很好理解：我们使用的是阿里云的云SSD，而阿里云目前的架构还没有做到计算和存储分离，即计算和存储的网络IO是共享的。文章源自JAVA秀-https://www.javaxiu.com/18477.html

当然目前这个问题还没有实锤，我们也还在跟阿里云积极沟通解决。同时为了避免给自己惹麻烦，我还是留了1%的其他可能性。文章源自JAVA秀-https://www.javaxiu.com/18477.html

文章源自JAVA秀-https://www.javaxiu.com/18477.html