渲染后台架构
渲染集群几个机房，每个机房有proxy、renderservice、redis、mysql
- Proxy：控制节点，角色为 master 或 slave，每个集群至少部署 2 个以成环；
- Render：渲染节点，每个集群有上百个；
- Redis：存储任务信息、配置信息等等，以主备的方式部署；
- MySQL ：存储任务调度信息、任务结果等持久化数据。
演练项
（图片来自网络）
渲染后台是较为底层的服务，redis是主要依赖的中间件，也是发生故障最多的地方。所以演练的重点是redis；
Redis
- 单点故障：kill one sentinel，kill all sentinel，kill master，
- 主从切换：来回 kill master
- 服务器宕机：one sentinel宕机，all sentinel 宕机，master宕机，all 宕机
- 网络异常： one sentinel网络不通，master网络不通
- 内存异常：redis maxme meroy打满，服务器内存耗尽
- CPU异常：one sentinel满载，master满载
- 磁盘异常：disk io 高，磁盘写满
- 备用redis切换
proxy
- 单点故障
- master 选举
- 负载均衡
- proxy 高负载压测
后续目标：
- CPU异常、网络异常、内存异常、磁盘异常
- 千台大集群proxy验证
mysql
- 网络异常
- 异常重连
网络
淮南机房目前渲染服务器接近一半的渲染资源在淮南机房。淮南机房公网出口为了稳定性保障，网络组已经部署两条电信线路：合肥和 江苏 ，目前现网渲染业务走合肥线路，江苏线路做为备份线路
主要模拟场景：当合肥线路中断后，防火墙自动切换到江苏线路后，业务层面使用域名DNS地址从合肥ip地址切换到江苏ip地址，保证业务能正常运行
演练目的
- 预案有效性：主要验证“备胎”靠不靠谱；系统强依赖的模块需要有降级、备用方案；需要对这类方案做有效性验证；
- 监控报警：报警的有无、提示消息是否准确、报警实效是5分钟还是半小时；
- 故障复现：故障的后续Action是否真的有效，完成质量如何，只有真实重现和验证，才能完成闭环。发生过的故障也应该时常拉出来练练，看是否有劣化趋势；
- 架构容灾测试：主备切换、负载均衡，流量调度等为了容灾而存在的手段的时效和效果，容灾手段本身健壮性如何；
- 参数调优：限流的策略调优、报警的阈值、超时值设置等；
关注我们
酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。
我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。
