本文作者： 张显华、窦智浩、卢进文
与集中式架构比较，分布式架构的系统复杂性呈指数级增加，混沌工程在信创转型、分布式架构转型、小机下移等过程中有用保障了出产的安稳性。本文共享了 TiDB 分布式数据库在银行中心事务系统落地中进行混沌测验的场景规划和实践。
混沌工程概述
混沌工程是一种全面的测验方法，它掩盖了从运用层前端到底层硬件环境的所有环节，确保整个系统在面临各种反常和毛病时的安稳性和弹性。本文将聚集于与 TiDB 分布式数据库相关的混沌工程场景。
混沌工程和一般测验在软件系统工程中都扮演着重要的角色，但它们重视的质量属性和测验施行的方法存在明显差异。混沌工程更侧重于系统的健壮性和在面临反常状况时的响应才能，而一般测验则侧重于验证系统的功用正确性和功用方针。两者的差异详见下表：
在着手进行混沌测验的场景规划和施行之前，有几个要害问题需求咱们深思熟虑：
首要，需求明确混沌测验的方针，期望经过测验掌需求重视的才能鸿沟、容错才能、安稳性等。其次，挑选合适的混沌测验东西，这些东西可以协助咱们在分布式环境中模仿各种毛病和反常状况。接下来，精心规划测验用例，确保它们可以掩盖到或许影响系统安稳性的要害环节。最终，整理总结混沌测验或许带来的收益，包含提高系统可靠性、优化毛病康复流程、增强团队对系统行为的理解等。经过这些环节的综合考量，咱们可以更有用地施行混沌测验演练，为 TiDB 分布式数据库的安稳性供给坚实的保障。
混沌测验目的
TiDB 作为一款原生分布式数据库，其架构规划与银行系统中的传统集中式数据库比较具有显著的差异。银行中心系统对功用、安稳性、跨地域的高可用性都有着苛刻的要求。为了满意这些要求，咱们计划经过混沌测验来了解功用鸿沟、评价系统高可用性和容灾才能、验证系统的弹性、查验应急预案有用性、优化监控和告警机制、并精确评价外围作业的影响。
2.1 了解功用鸿沟
了解数据库的才能鸿沟，对上线后的运维作业具有重要的参阅含义。一个新的事务系统在规划之初，不只要满意当时的事务需求，还要考虑满意未来的事务发展需求，尤其是在极致安稳性要求下，银行中心系统的规划需求考虑未来 5 年至 10 年以上的事务发展需求。经过混沌测验，在总体规划的装备下，测验数据库的才能鸿沟，将成果作为上线后运维的重要参阅方针，并查验系统是否满意总设要求下未来事务的承载体量。
此外，经过混沌测验还可以发现整个事务链路或许存在的一些瓶颈点。
2.2 评价系统高可用和容灾才能
TiDB 的存算别离架构由中心组件和外围组件组成。中心组件包含 TiDB、TiKV、PD 和 TiFlash，用于处理核算和存储任务。外围组件包含 BR 和 TiCDC 等，用于满意备份、数据共享等事务场景的需求。这些组件可以独自布置或混合布置，以满意隔离性和资源运用率的平衡。
在银行中心系统中，常见的布置方法是两地三中心。经过混沌测验，可以在实践的布置架构下模仿各种毛病场景，评价系统的高可用才能和灾备接收才能。测验成果可以供给每个场景或多场景组合下的 RTO 和 RPO 方针，并协助辨认运用连接康复的健壮性和通明性问题，以及发现或许存在的拜访链路瓶颈。
2.3 验证系统的弹性
事务发展具有动态性，在突发的高流量高负载事务活动中，或许需求进行系统扩容以统筹效率和安稳性。此外，X86 服务器比较小型机安稳性差、毛病率高、生命周期短，需求经过扩缩容动作完成对硬件的晋级和替换。基于这些要素，咱们从两个维度对扩展性进行评价：
- TiDB 的线性扩展才能：评价 TiDB 在扩容后能否保持功用的线性增加，满意事务增加带来的功用需求。
- 扩缩容调整的快捷性、通明性和对事务的影响：评价扩缩容操作是否简略易行，对运用是否通明，对事务是否有影响以及影响程度。
2.4 查验应急预案有用性
运用混沌测验中触及的破坏性测验场景，对应急预案进行全面的查验和优化，为上线后的运转维护做好充分准备。
2.5 优化监控和告警机制
运用混沌测验，可以有用查验告警系统的有用性和精确性，并对告警进行全面的查漏补缺和优化。经过测验验证和继续优化，确保告警及时、精确、等级合理、防止过度冗余。
2.6 精确评价外围作业的影响
出产事务系统触及数据库备份、计算信息搜集、TiCDC 数据同步等外围作业，以及版别/补丁晋级、重启、扩缩容、硬件替换、容灾切换等运维作业。混沌测验应重视此类作业对系统负载、事务方针、网络流量等方面的影响，并优化相关的作业窗口和并发度，确保事务平稳运转。
混沌测验东西
咱们以某商业银行中心场景为例，运用 Chaosd 东西来进行混沌测验的场景规划和演练。Chaosd 组件 ( chaos-mesh.org/zh/docs/cha… ) 是 Chaos Mesh ( chaos-mesh.org/zh/ ) 供给的一款混沌工程测验东西（需求独自下载和布置 ( chaos-mesh.org/zh/docs/cha… )），用于在物理机环境上注入毛病，并供给毛病康复功用。
Chaos Mesh 是 PingCAP 自主研制的开源云原生混沌工程渠道，供给丰厚的毛病模仿类型，具有强大的毛病场景编列才能，方便用户在开发测验中以及出产环境中模仿现实世界中或许呈现的各类反常，协助用户发现系统潜在问题。
Chaosd 具有以下中心优势：
- 易用性强：输入简略的 Chaosd 命令即可创立混沌实验，并对实验进行办理。
- 毛病类型丰厚：在物理机的不同层次、不同类型上都供给了毛病注入的功用，包含进程、网络、压力、磁盘、主机等，且更多的功用在不断扩展中。
- 支撑多种方法：Chaosd 既可作为命令行东西运用，也可以作为服务运用，满意不同场景的运用需求。
Chaosd 供给完善的可视化操作，旨在降低用户进行混沌工程的门槛。用户可以方便地在 Web UI 界面上规划自己的混沌场景，以及监控混沌实验的运转状况。你可以运用 Chaosd 模仿以下毛病类型：
- 进程：对进程进行毛病注入，支撑进程的 kill、stop 等操作。
- 网络：对物理机的网络进行毛病注入，支撑增加网络推迟、丢包、损坏包等操作。
- 压力：对物理机的 CPU 或内存注入压力。
- 磁盘：对物理机的磁盘进行毛病注入，支撑增加读写磁盘负载、填充磁盘等操作。
- 主机：对物理机本身进行毛病注入，支撑关机等操作。
关于每种毛病类型的详细介绍和运用方法，请参阅对应的说明文档 Chaosd 组件简介 | Chaos Mesh ( chaos-mesh.org/zh/docs/cha… )。
混沌测验场景规划
混沌测验场景规划的原则是尽或许的模仿实在的出产状况。为了最大程度地模仿实在环境，测验的方针环境引荐运用准出产环境或按照出产环境规划要求建立 1:1 仿真测验环境，并确保环境装备、布置架构、数据容量和事务负载等方面与预估上线后或系统规划要求一致。
测验从事务压力、毛病注入、外围作业和运维操作等多个维度进行全方位测验，包含但不限于：
- 模仿实在的用户拜访量和事务负载，以评价系统在高并发状况下的功用和安稳性。
- 注入各种硬件毛病、软件毛病和网络毛病，以评价系统的毛病处理才能和快速康复才能。
- 模仿数据同步、备份作业等相关外围作业对资源运用的影响和 SQL 时延的影响。
- 模仿运维人员的日常操作，以评价系统的易用性和可维护性。
4.1 事务压力
买卖型事务压力
混沌测验主张选用实在事务模型，经过等份额的事务流量进行压测，或许有条件的选用流量回放（ 出产环境流量需严厉遵循安全管控流程，仅适用于出产域，且需进行脱敏处理 ）的方法进行。关于项目前期无法基于实在事务模型进行压力模仿的状况，可以挑选部分较为中心（或简化）的事务模型进行压力模仿。
如果上述条件均不具有，也可选用 sysbench 进行压力注入。由于 sysbench 与实在事务模型存在较大差异，对功用鸿沟的评价含义有限，但根本不影响对高可用、容灾才能、扩展性、查验和优化监控告警等其他方面的验证成果。
关于注入压力的巨细，主张按队伍逐层加压展开：
- 出产（预估）TPS 方针
- 总设要求的 TPS 方针
- 总设要求的 TPS 方针 * N 倍 （1.5、2、3 ….，截止满意事务时延下的最高压力）
- 满意事务时延下的最高压力
- 根底环境负载打满的压力
以上几个队伍可以按需进行，统筹测验本钱，不主张过度细分压力场景 。
对每个压力场景，记载各项根底环境和数据库实例级别的资源运用率、数据库 QPS/TPS、数据库 SQL 时延、端到端的事务时延、事务 TPS 等要害信息，主张将当时的压测场景结合要害的监控信息进行存档。以下登记表供参阅（为方便展示，部分信息项简化合并)：
批量事务压力
银行中心事务中的日终、日切、日结、报表等批量类事务，并发量大，负载高，需按照实在的用户量和总设要求的承载用户量别离进行压力测验。除了依据用户量维度施加压力外，还需重视此类事务的并发度、作业编列等方面，以探索最佳的事务实践。
长稳压测
长稳压测主张以买卖型事务压力为主（总设要求的 TPS 方针压力），结合实践状况周期性注入批量事务压力，展开 7*24 小时长稳压测，全面验证系统全体的可靠性和安稳性。此外，长稳压测还可以有用发现一些简单被疏忽的潜在问题，例如根底硬件的质量问题、装备是否合理、全链路中的脆弱点和功用瓶颈等。
其他场景
按需依据实践的事务特色扩展测验场景，针对性地进行验证。例如测验表数据量增加对 SQL 响应时延的影响：
- 依据实践表结构进行数据量增加压测，模仿从百万级到十亿级数据量（甚至更多，统筹测验本钱按需进行即可，无需过度扩大）的改变。
- 在同等事务压力下，运用实践的事务 SQL 测验响应时延、QPS、TPS 方针的改变。
4.2 毛病注入
针对 TiDB 的毛病注入测验可以从实践布置架构和毛病面积两个维度进行规划，本文以同城双机房双活的 DR Auto-Sync 架构 ( docs.pingcap.com/zh/tidb/sta… ) （即 Data Replication Auto Synchronous，简称 DR Auto-Sync）进行介绍，其他布置架构的毛病注入测验用例规划思路与此相似。毛病注入和康复后，需求重视的事项有：
- 关于事务量、QPS、TPS 的影响份额和继续时刻
- 事务端到端的时延改变和继续时刻
- SQL 的时延改变和继续时刻
- 存活节点的资源运用改变
- 集群本身的负载均衡才能（如 leader 重新推举）
- 运用连接池重连才能（注意重视并优化连接池装备、负载探活装备）
以下毛病注入跟踪表供参阅（为方便展示，部分信息项简化合并)：
主张选用分级毛病注入战略，实例级毛病注入时需求依据不同的实例角色进行，服务器级毛病注入时需求结合布置架构（尤其是存在混合布置状况下）进行。
4.3 外围作业
外围作业注入应重视相关作业对资源运用和 SQL 推迟的影响，并结合出产实践事务周期性改变的状况，优化作业窗口和并发度等装备。首要的外围作业包含全量物理备份、全量逻辑备份、BR log 备份（常驻作业）、计算信息搜集和 TiCDC 数据同步（常驻作业）等。
4.4 运维操作
运维操作注入是模仿实在运维操作对 TiDB 系统的影响，需求重视的事项与毛病注入一致，部分运维操作场景和毛病注入场景或许存在堆叠，首要包含的场景有：滚动重启、 扩容（重视线性扩展比、对运用的通明度） 、缩容、补丁/版别晋级、在线 DDL（增、删、修改字段、创立索引）和容灾切换等。其中，容灾切换需求模仿各类场景进行要点测验，如测验系统在计划内切换（主备机房不停机）和计划外切换（主备机房彻底失联）场景下的表现。
4.5 DR Auto-Sync 专项场景
DR Auto-Sync 架构 ( docs.pingcap.com/zh/tidb/sta… ) 适用于同城双机房 RPO=0 的高可用容灾架构 （本系列后续文章将进行详细介绍，敬请重视）
该计划在同一区域布置两个 AZ (Availability Zone, AZ)，以满意高可用和容灾要求，且本钱更低 。下图为集群布置架构图：
- 集群选用引荐的 6 副本方法，其中 AZ1 中放 3 个 Voter，AZ2 中放 2 个 Follower 副本和 1 个 Learner 副本。TiKV 按机房的实践状况打上合适的 Label。
- 副本间经过 Raft 协议确保数据的一致性和高可用，对用户彻底通明。
该布置计划定义了三种状况来操控和标示集群的同步状况，该状况约束了 TiKV 的同步方法。集群的仿制方法可以主动在三种状况之间自适应切换。
- sync：同步仿制方法，此刻从 AZ (DR) 至少有一个副本与主 AZ (PRIMARY) 进行同步，Raft 算法确保每条日志按 Label 同步仿制到 DR。
- async：异步仿制方法，此刻不确保 DR 与 PRIMARY 彻底同步，Raft 算法运用经典的 majority 方法仿制日志。
- sync-recover：康复同步，此刻不确保 DR 与 PRIMARY 彻底同步，Raft 逐步切换成 Label 仿制，切换成功后汇报给 PD。
针对运用双机房布置的状况，经过混沌测验的场景规划，来验证 TiKV 和 PD leader 的最佳放置方位以及流量分发的最优链路，以期实现最佳的功用。如图所示，依据事务流量拜访和数据 Leader 分布别离在单、双中心的四种场景组合进行测验，然后找到最佳计划。
混沌测验的收益和实战举例
5.1 把握才能鸿沟
混沌测验可以协助咱们全面了解系统的才能鸿沟，为事务上线及后续的运维供给重要的参阅依据， 详细包含：获得当时装备和部 署下数据库最高可承载的事务量，为容量规划供给辅导；评价数据库的扩展才能，为未来的扩容供给辅导；模仿各类毛病对数据库服务才能的影响，进而验证和优化应急预案规划；模仿各类运维操作对数据库服务才能的影响，然后辅导变更流程规划；模仿单表数据快速增加，评价对数据库功用的影响，并采纳相应的优化措施。
实测结 果举例：
- 系统弹性才能评价：
- 在线扩容、操作简略，对运用、对表物理模型彻底通明。
- 容量、功用线性扩展比超越 90%。
- 单表数据量增加对 SQL 时延影响场景：
银行中心事务中，部分事务表（如买卖流水表）数据量会随着事务办理而急剧增加，并需在出产集群中保存必定时刻（超越必定周期转移到近线库，超越在线查询周期转移到带库存储）。这类表一般体积较大，银行客户基于对集中式数据库的运用经验，会忧虑单表数据量增加对功用产生影响。
为此，咱们经过测验进行了验证。测验成果表明，单表数据（实测多张相关联事务表等份额增加）从百万级到 10 亿 急速增加的状况下，相关事务的 SQL 时延几乎不受影响，打消了客户的疑虑。如下图所示，短时刻内少量事务流水表数据量急剧增加，相关事务 SQL 时延十分安稳，无明显改变。
5.2 获得最佳实践
混沌测验可以协助咱们发现系统全链路中的瓶颈点，然后进行针对性的优化，实现最佳实践。经过混沌测验，咱们可以辨认数据库布置架构和装备、负载均衡和探活装备、运用连接池和探活装备、双活架构下的数据库装备和流量分发、各类外围作业的时刻窗口和并发度装备等方面存在的潜在问题，并进行相应的优化，例如调整数据库参数、调整流量分发规矩、优化导入导出作业的并发度等。
实测成果举例:
- Label 标签和服务器物理方位结合可以增强高可用才能：
- 以 5 副本架构为例，最多可以一起忍受两个 Label 标签下的服务器掉线
- 结合服务器物理方位规划，即可以一起忍受两组机柜下的服务器掉线
- 在“DR Auto-Sync 架构 + 运用双活布置”专项场景中咱们得出的最佳实践：
- TiKV Leader 、PD Leader 指定在主机房
- 主、备机房负载均衡别离拜访本机房 TiDB-Server
- 主、备机房流量按照 9:1 分发分发到本机房负载
5.3 提高高可用才能和优化应急预案
混沌测验可以协助咱们全面了解数据库在不同毛病状况下服务才能的改变，然后查验应急预案的有用性，并针对性地进行优化。
实测成果举例:
- 单点的离线类（实例和服务器级的反常 Crash ）毛病对 TiDB 数据库服务全体影响面小或许时刻短，且可以自愈，根本不需求应急预案。
- 单点离线类毛病针对不同组件的影响程度从大到小排序：PD-Server (Leader) > TiDB-Server > TiKV-Server (主机房) ；其他，不影响在线服务，无感知。
- 布置架构和 Label 装备结合物理方位规划状况下，机柜级毛病约等同于单点毛病 （因触及实例多，影响面积略大，继续时刻略久），可自愈，且根本不需求应急预案。
- 单点的才能恶化类毛病（服务器夯 / 实例夯 / IO 时延 / 网络时延等）对 TiDB 数据库服务影响较大，不行自愈，自愈方法可选用强制隔离下线或重启方法，这也契合分布式数据库 Fast-Fail 的应急思路。
- 跨机房网络才能下降（非中止），对 TiDB 数据库的 DR Auto-Sync 架构的服务影响较大，不行自愈，需求应急预案（如将 Sync 方法降级为 Majority 方法 ）。
- 机房级中止类毛病分为两种状况：
- 同城 (从) 机房离线（同城网络中止、批量宕机失联等）会导致 TiDB 服务中止，RPO=0，RTO 时刻受服务降级参数影响 (一般设置 10s-30s)，可自愈，不需求应急预案。
- 主机房离线（主机房网络中止，批量宕机失联等）会导致 TiDB 服务中止，可以确保 RPO=0，需求计划外容灾切换的应急预案。
这里的 “应急预案”仅指毛病场景中满意 SLA 状况下的应急，不包含集群全体健壮性或健康度的修正。
若统筹健壮性或健康度的修正，还需求重视的事项：
- 存活节点的资源运用率和负载均衡状况；
- 根底环境或硬件毛病不行康复状况，过后需求经过扩容、装备调整等手法补齐高可用才能。
常见的毛病场景关于 TiDB 数据库服务的影响（下表中的 MTTR、事务影响份额受集群布置架构、毛病实例个数、集群规划、事务负载特征、负载均衡探活战略等要素影响）：
5.4 优化监控告警机制
混沌测验可以协助咱们查验和优化监控告警，确保监控告警可以及时、有用地发现和辨认系统毛病。以下是一些对监控告警设置的主张：
- 确保告警掩盖所有的要害方针和组件，设置合理的勘探频率。
- 设置适度的冗余，确保根因可以经过告警直接发现，提高告警的可靠性。
- 区别于集中式数据库，TiDB 作为原生分布式数据库具有原生高可用、高并发等特色，设置告警规矩时需求考虑这些特色，防止简略的套用集中式数据库的告警思维。
- 主张以分类法进行告警整理，确保告警掩盖面，可参阅的分类维度有：运转状况类、黄金方针类、资源运用类、阈值类（结合装备参数）、日志和报错类、开发标准管控类（如慢 SQL / 全表扫描 SQL / 非标准语法）等。
过去一年，PingCAP 在金融职业场景累计完成数千个混沌演练测验，发现近百个问题。展望未来，PingCAP 将继续深耕金融职业，积极探索混沌工程在分布式数据库范畴的运用，经过不断丰厚的毛病场景，结合毛病诊断、根因剖析等技术手法，做好毛病沉淀积累，稳步提高 TiDB 处理反常事端及极点场景的应变才能，为金融事务稳健运转供给有力保障。
