背景

业务中有一个组件会产生每秒千级的数据读写，与之交互的是redis。

组件采用负载均衡，多个组件共同作业。

这几个组件都往一个内网的redis上读写。

问题

在业务高峰，用户反馈加载数据信息慢。

排查

网络正常、组件、redis所在服务器性能充足。故认为瓶颈在服务内部。

同时可知，redis支持千级的并发显然是不会成为瓶颈的。

所以判断问题在组件本身。

检索组件日志，发现与redis交互的数据操作，队列积压已到2000,。

解决

横向扩展，增加一个组件，以均摊负载

再次检索日志，发现队列积压迅速回落

进一步思考

由于没有服务内部的监控策略，所以要及时了解队列积压就比较麻烦，所以运维和开发之间就需要进一步沟通，开发在程序内部抛出具体的队列数据，然后运维这边从响应的接口获取数据，然后在平台上进行展示。

这样就可以监控组件的性能状态，可以据此考虑是否可以优化程序内部逻辑，或者需要横向扩展的数量。