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