文章插图
发现问题，那么就要解决问题，redis 的 qps 优化方案有两步：
• 扩容 redis 节点，迁移 slot 使其分担流量 • 尽量把程序中 redis 的请求改成批量模式
增加节点容易，批量也容易 。起初在优化推送系统时，已经把同一个逻辑中的 redis 操作改为批量模式了 。但问题来了，很多的 redis 操作在不同的逻辑块里面，没法合成一个 pipeline 。
然后做了进一步的优化，把不同逻辑中的 redis 请求合并到一个 pipeline 里，优点在于提高了 redis 的吞吐，减少了 socket 系统调用、网络中断开销，缺点是增加了逻辑复杂度，使用 channal 管道做队列及通知增加了 runtime 调度开销，pipeline worker 触发条件是满足 3 个 command 或 5ms 超时，定时器采用分段的时间轮 。
对比优化修改前，cpu开销减少了 3% 左右，redis qps降到 7w 左右，当然概率上消息的时延会高了几个ms 。
实现的逻辑参考下图，调用方把redis command和接收结果的chan推送到任务队列中，然后由一个worker去消费，worker组装多个redis cmd为pipeline，向redis发起请求并拿回结果，拆解结果集后，给每个命令对应的结果chan推送结果 。调用方在推送任务到队列后，就一直监听传输结果的chan 。
文章插图
这个方案来自我在上家公司做推送系统的经验，有兴趣的朋友可以看看 PPT，内涵不少高并发经验 。分布式推送系统设计与实现
总结推送系统设计之初是预计 15w 的长连接数，稳定后再无优化调整，也一直稳定跑在线上 。后面随着业务的暴涨，长连接数也一直跟着暴涨，现在日常稳定在 35w，出问题时暴到 50w，我们没有因为业务暴增进行整条链路压测及优化 。
话说，如果对推送系统平时多上点心也不至于出这个问题 。我曾经开发过相对高规格的推送系统，而现在公司的推送系统我是后接手的，由于它的架子一般，但业务性又太强，看着脑仁疼，所以就没有推倒来重构 。一直是在这个架子上添添补补，做了一些常规的性能优化 。嗯，看来不能掉以轻心，免得绩效离我远去 。
推荐阅读
- Linux快速找出Java应用占用CPU最高的线程
- 有很高史学和文学价值的三史 中国古代文学和史学的主要成就
- 翡翠|高昂或者低廉的翡翠都有人购买，任何一个品种，都有喜爱它的人群
- 挂靠社保被罚4.2万！新规实施，这样交社保将有高风险
- 10000支付宝余额宝收益?余额宝收益忽然很高
- 十一高速免费几号到几号？
- 骢马原文注释翻译及赏析 高都护骢马行答案
- 世界上含金量最高的奖项是什么？
- 资深架构师：深入聊聊获取屏幕高度这件事
- 导演和主演谁的片酬高？