流量对系统参数的影响

随着并发请求的增大，对系统的影响主要集中在以下几个方面

系统CPU、LOAD等参数。随着TPS的增加，系统线程上下文切换频繁，需要处理的业务请求也变多，CPU会上升。系统内存MEM一般不会有太大波动

在工作中遇到的一个接口的情况：

接口的QPS日均在1w。RPC连接池，默认核心连接数是80，最大连接数是100，队列是1000。

接口平均耗时2ms，假设每秒处理500个请求，那么就拿核心连接数80算，接口能承载的QPS也达到了500*80=4w

所以正常来说TPS的增加，对线程池对压力影响并不是很大。
外部依赖耗时增加。比如Redis缓存，随着并发请求量的增加，耗时也会增加。流量越大，耗时增加的越明显。主要考虑是应用系统频繁的GC占用用户线程，导致TBase调用超时。

在工作中的实际例子：

一个接口平常访问Redis集群，耗时在0.4ms左右（其中包含了很多连接超时请求），在双十一大流量下，平均耗时可以达到1.2ms，翻了3倍左右。

另外，Redis集群在删除记录时候，也会占用CPU，在记录大面积同时失效的时候，可以看见明显的Redis请求耗时增加。
JVM参数。随着TPS增加，新生代开始疯狂GC，而后导致老年代空间利用率快速增大，逐渐产生较多的Full GC。频繁Full GC占用用户线程时间，导致服务超时。如果堆内存空间不能及时释放掉，将会逐渐导致服务不可以用。
系统Error。在高并发下，明显有增加。
1. 当前进程以及达到Linux最大文件打开数量
2. 连接池已满
3. 。。。

系统“宕机”的理解

系统宕机。所谓“宕机”，是指网络空间的信息系统无法提供正常服务，出现卡顿甚至“停顿”现象，用户的直接体验就是系统长时间无响应，比如无法正常访问、搜索无响应等

机器在突然的大流量打过来时，可能由于上述种种原因，请求被阻塞。那上游就会提示处理超时或其他保错，无法提供正常服务。但是此时机器可能病没有真正的宕机。此时机器可能CPU和LOAD快被打满了而已。

对于高可用的线上系统机器集群，运行的各种容器状态会有相关监控。当容器状态不好，特别是CPU、内存快打满，命中相关监控规则，机器会重启（自愈，猜测运维人员对容器部署了相关的shell脚本进行监控）

运维层面保证服务高可用

事前：保证物理机、虚拟机等容量充足、节点服务正常
事中：如果发生了高并发导致服务不可用。

如果系统有10台机器，在高并发状态下，每个机器都高负荷运作。如果此时1台机器挂了，流量会打到其他9台机器上，那其他机器也会一个接一个挂掉，产生雪崩。
- 紧急扩容，分散流量
- 系统降级。如果紧急扩容时间等问题无法及时止血，接口需要及时降级。
事后：根据系统需要，加机器资源。