背景
业务中有一个组件会产生每秒千级的数据读写，与之交互的是redis。
组件采用负载均衡，多个组件共同作业。
这几个组件都往一个内网的redis上读写。
问题
在业务高峰，用户反馈加载数据信息慢。
排查
网络正常、组件、redis所在服务器性能充足。故认为瓶颈在服务内部。
同时可知，redis支持千级的并发显然是不会成为瓶颈的。
所以判断问题在组件本身。
检索组件日志，发现与redis交互的数据操作，队列积压已到2000,。
解决
横向扩展，增加一个组件，以均摊负载
再次检索日志，发现队列积压迅速回落
进一步思考
由于没有服务内部的监控策略，所以要及时了解队列积压就比较麻烦，所以运维和开发之间就需要进一步沟通，开发在程序内部抛出具体的队列数据，然后运维这边从响应的接口获取数据，然后在平台上进行展示。
这样就可以监控组件的性能状态，可以据此考虑是否可以优化程序内部逻辑，或者需要横向扩展的数量。