C. 高可用架构 --- 连锁故障处理
概述
由于整个系统的一小部分出现故障，进而导致系统其他部分也出现故障
原因
服务器过载：原本均衡的两个系统，由于其中一个服务出现问题，导致另外一个服务出现过载
资源耗尽
CPU，副作用：
正在处理的请求数量上升
队列过长
线程卡住
CPU死锁或者请求卡住
RPC超时
CPU缓存效率下降
内存，副作用：
任务崩溃
Java垃圾回收速率加快，从而导致CPU使用率上升
缓存命中率下降
线程
文件描述符
资源之间的相互依赖
慢启动
必需的初始化过程
运行时性能优化，尤其是java
冷缓存
原因
上线一个新的集群
在某个集群维护之后恢复服务状态
带缓存的任务重启
措施
过量配备该服务。
使用限流降级机制
当为一个集群增加负载时，需要慢慢增加。初期的小流量会加热缓存，一旦缓存热起来，就可以增加更多的请求。
常见触发条件
进程崩溃
进程更新
新的发布
业务自然增长
计划中或计划外的不可用
请求特征的变化：负载均衡配置改动，导致用户流量发生变化
资源限制
测试，发现薄弱环节 --- 压力测试
测试直到出现故障，还要继续测试
测试环境测试
如果一个组件在高负载条件下进入了降级模式，它是否能哦鼓在无人干预的情况下退出该模式
如果高负载情况下几个服务器崩溃，负载需要降低多少才能使系统重新稳定下来
生产测试：确保有足够的可用额外容量依备自动保护措施失败，需要人工进行切换
快速或者缓慢地降低任务数量，超越之前预期的流量模式
快速去掉某一个集群的容量
屏蔽不同的后端（试验超时等因素对系统的影响）
测试最常用的客户端
测试非关键性后端：确保它们的不可用不会影响到系统值的其他关键性组件
预防措施
限流降级
解决方案
增加资源
停止健康检查导致的任务死亡
重启软件服务器
丢弃流量
进入降级模式
消除批处理负载
消除有害的流量