对高并发与系统优化的一些感想与总结

1.背景

针对暑期高峰时段的防范，保护暑期直播的稳定性。于暑期前和团队一起进行防火演练以及压测，一直缺乏整理，此次记录并分享。

2.目标

接口QPS>=2W。
能容纳50W同时在线。
可通过资源线性扩容快速支撑100万在线能力。

3.前期思考

服务性能瓶颈点究竟由什么决定？
机器？DB？架构？代码？

木桶理论：

木桶理论又称短板理论，其核心思想是一只木桶盛水多少，并不取决于最高的木板，而取决于最短的那块木板。
木桶原理应用在系统分析中，即系统的最终性能取决于系统中性能表现最差的组件，为了提升系统整体性能，对系统中表现最差的组件进行优化可以得到最好的效果。

找寻当前系统最差的点至关重要。而上述的每一点都可能成为系统的短板

4.压测（以下压测都基于优化完代码之后，压测不合格请第一时间考虑代码设计问题！！！）

第一次压测

1.第一轮压测评估当前哪些接口性能低下，从这些接口入手。
2.开启性能监控的工具。监控压测过程中机器，DB等情况。
机器监控：http://book.open-falcon.org/zh/intro/index.html
DB监控：用的公司运维老师搭建的监控平台，主要监控的点CPU，used_memory，OPS，traffic_in，traffic_out。
可参考此博客：https://blog.csdn.net/sanyaoxu_2/article/details/88832426

失败告终

压测某一接口导致redis主从切换，从库只允许读不允许写，导致大量报错。
监控显示redisCPU一下干到100。
内存毛刺状。

失败后的思考

1.为什么会压切？
代码层面的问题。进行review代码。
压测有四个场次，一个场次4W人，是用redis的set，一个zset 4W条数据，接口频繁zrange，导致redis严重阻塞。
解决方案后面详说。

解决上述问题后第二次压测，又遇问题，性能依旧不高

监控：

指标	状况
压力机	未打满
db瓶颈	未满
接口耗时排查	心跳初始化接口耗时过长，大量1s-120s
机器指标	部分机器性能idle，cpu不正常

去kibana上绘制机器流量图以及慢响应机器分布图

发现某一台机器出问题。继续跟进。因为无线上机子root权限，联系运维老师一起查，运维老师没有发现原因，选择暂时下掉此机器[记得当时的方案是这样子的]。

并且这一次有了重大的突破，发现不仅仅这一台有问题。

这一批机子是新产的机子，发现运维配置新机器的时候，某监控服务配置有误，导致性能普遍偏低。

第三次压测

解决完如上问题之后，再压测。
性能提高40%左右。

之前QPS	现在QPS
16000	28000

5.总结以及自己的一点心得

来当下的公司经历了2次压测了，每一次都有不同的问题出现。这次总结一下自己两年来所碰到的问题。
1.代码层面的问题

无论什么时候，都应该先从自身找原因。看看是不是代码层面的问题，代码层面的瓶颈是最容易解决，成本最低的。

	问题	详细描述
1	代码质量问题	1.循环调用第三方。 2. 数据结构设计不合理。 大key，热key情况常常出现。 3.二级缓存的必要性。 对于经常调用，但是一定时间内固定的数据，应设置合理的二级缓存，不必要每次都去调用第三方。
2	第三方接口	第三方接口拖累。 第三方响应时间过慢，若设置超时时间会导致数据有误，若不设置会导致接口响应过慢。
3	对应的存储架构	1.长连接与连接数的控制。 我们用的twemproxy与redis建立长连接，发现并不是server_connections连接数越多就越好。文档：https://github.com/twitter/twemproxy 2.根据业务形态考虑相应的读写分离机制。 mysql的binlog。 3.pipeline和异步重要性。最好使用pipeline去批量写入redis。不需要实时的数据可以考虑异步。

2.外部问题
网卡，机器CPU，DB问题等等
此问题比较难解决，需要根据具体情况具体分析。

3.必要时设计优雅降级方案
保护核心业务。通过配置后台实现优雅降级。

4.针对业务合理拆分
如提交接口单独集群。耗费性能的统计接口单独集群。
不让统计影响主流程提交。