阳春三月在成都

发表于由
回复

这是一篇月末总结，如果你是不小心被标题吸引误入，那么我更加建议你把这篇月志读完。既来之，则安之?

三月工作上发生了挺大变化，很多老朋友离开了，很多新同学加入了。无论是离开还是加入的人，里面都有自己喜欢和欣赏的人。成都的圈子只有这么大，鄙人都祝福他们。

自己又回到3年前的类似位置，做着类似的事情，此乃物是。三年前犯过的错误、苦恼纠结的事情，无一缺席，但是已经没有了当初面对类似事情的不确定性，此乃人非。

这个月重新找到了写字的愉悦感。在某些平台居然还被特别推荐过，我跟妞儿说这是一件funny的事情，没有开心的成分。算是把延期了好几年的课程补上了一小步。

在这个过程中，鄙人也开始逐渐体会到了自己订阅的公众号作者写作的内心感受。写作的目的可能有很多种，但是对于某一类人来说，写作就是一种习惯性的分配特定时间进行思考。这种思考可能在写作开始之前已经在潜意识中发生。写作就是讲这些思考的尘埃落定和梳理的过程。另外，根据我的观察，一般擅长写作的人，大多都是逻辑清晰且沟通起来很愉快的人。

三月挺幸运，包括今天。接触到了很多交流起来很愉快的人。鄙人跟妞儿说，遇到聪明的人的时候，有一种发自内心的欣赏和热爱。这种热爱跟基情没有关系，对于没有那么熟络的人，珍惜交流的效率和时间；对于熟悉的人，会聊很多平时不会聊的话题和看法。要知道，其实这个世界上，能够一起沟通和讨论一些深度想法的人太少太少了，遇到一个，怎能不喜？有那么一群人，注定就是寂寞。

马上而立之年了，责任随不至于越来越重，但是却只越来越真实。这个月似乎也硬着头皮处理了很多家庭上的事情。也许有时候过于追求效率，以及当面揭穿一些人的套路伎俩吧，给人的感觉是脾气太冲，经常惹恼很多人，包括家人。在这个点上，我从来不抱怨什么路长且累呀，什么不理解呀。我挺同意韩路的观点：如果你对目标足够清晰和强壮，那么做一些事的时候必然会有取舍和付出。想通了这件事，很多事情就是理所当然的，哪里还有什么抱怨。我花了挺长时间想清楚这个问题，也会有心情郁闷的时候，也会有到家以后，熄火在车里闷两分钟的时候，但是只要踏入家门，我必然是女儿的好爸爸，妞儿的好丈夫，父母的好儿子，而这一切，内心是举重若轻，毫无纠结的。

三月：

  • 最喜欢的物品：飞行棋手机架
  • 最喜欢的书：《原则》
  • 最惺惺相惜的人：至今不知道他的名字，但是却有过一次非常深入、愉快的交流
  • 财务目标一个都没有达到，且存在浮亏的款项
  • 独立项目新开了一个项目，看能走多远吧

三月开始，南方逐渐进入一年中最好的日子。在期待四月中，2018已经过去25%.

一次非典型性 Redis 阻塞总结

发表于由
回复

南方逐渐进入一年中最好的时节，用户也开始骚动起来。看了眼数据，活跃用户已经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持久化