系列导读
徐戟（白鳝）：数据库技术专家，Oracle ACE，PostgreSQL ACE Director
当前，国内大量的关键行业的核心系统正在实现国产化替代，而与此同时，这些行业的数字化转型也正在进入深水区。在信息系统的升级换代过程中，夯实 IT 基础设施是极其关键的。从服务器、操作系统、中间件、数据库等基础软硬件选型到系统架构、应用架构的重新设计，再到数据迁移、系统迁移、系统优化、运维体系重构的一系列工作都是十分具有挑战性的。大多数工作中，都会遇到无法完全参考前人的探索和创新。
一些勇敢的先行者已经在这条荆棘丛生的道路上硬生生的创出了一条血路，而更多的人还在未知与迷茫中摸索。“银⾏核⼼背后的落地⼯程体系”系列技术文章来自于金融行业用户真实故事，从中可以窥见的不仅是国产化替代路上的艰辛历程，更多的是对于后来者极其宝贵的实践经验。
在本系列文章中你不仅可以看到 TiDB 与 Oracle 的异构迁移、基于 TiCDC 的逻辑容灾与数据共享、构建双活数据中心的真实案例，还可以了解到混沌测试、应急预案等方面，以及利用数据库可观测性构建智能化、自动化运维体系的方案与技巧。“积小流，成江海”，希望这些案例能够对您有所裨益。
与集中式架构相比，分布式架构的系统复杂性呈指数级增长，混沌工程在信创转型、分布式架构转型、小机下移等过程中有效保障了生产的稳定性。本文分享了 TiDB 分布式数据库在银行核心业务系统落地中进行混沌测试的场景设计和实践。
混沌工程概述
混沌工程是一种全面的测试方法，它覆盖了从应用层前端到底层硬件环境的所有环节，确保整个系统在面对各种异常和故障时的稳定性和弹性。本文将聚焦于与 TiDB 分布式数据库相关的混沌工程场景。
混沌工程和普通测试在软件系统工程中都扮演着重要的角色，但它们关注的质量属性和测试实施的方式存在明显差异。混沌工程更侧重于系统的健壮性和在面对异常情况时的响应能力，而普通测试则侧重于验证系统的功能正确性和性能指标。两者的差异详见下表：
在着手进行混沌测试的场景设计和实施之前，有几个关键问题需要我们深思熟虑：
首先，需要明确混沌测试的目标，希望通过测试掌需要关注的能力边界、容错能力、稳定性等。其次，选择合适的混沌测试工具，这些工具能够帮助我们在分布式环境中模拟各种故障和异常情况。接下来，精心设计测试用例，确保它们能够覆盖到可能影响系统稳定性的关键环节。最后，梳理总结混沌测试可能带来的收益，包括提高系统可靠性、优化故障恢复流程、增强团队对系统行为的理解等。通过这些环节的综合考量，我们可以更有效地实施混沌测试演练，为 TiDB 分布式数据库的稳定性提供坚实的保障。
混沌测试目的
TiDB 作为一款原生分布式数据库，其架构设计与银行系统中的传统集中式数据库相比具有显著的差异。银行核心系统对性能、稳定性、跨地域的高可用性都有着严苛的要求。为了满足这些要求，我们计划通过混沌测试来摸底性能边界、评估系统高可用性和容灾能力、验证系统的弹性、检验应急预案有效性、优化监控和告警机制、并准确评估外围作业的影响。
摸底性能边界
摸底数据库的能力边界，对上线后的运维工作具有重要的参考意义。一个新的业务系统在设计之初，不仅要满足当前的业务需求，还要考虑满足未来的业务发展需求，尤其是在极致稳定性要求下，银行核心系统的设计需要考虑未来 5 年至 10 年以上的业务发展需求。通过混沌测试，在总体设计的配置下，测试数据库的能力边界，将结果作为上线后运维的重要参考指标，并检验系统是否满足总设要求下未来业务的承载体量。
此外，通过混沌测试还可以发现整个业务链路可能存在的一些瓶颈点。
评估系统高可用和容灾能力
TiDB 的存算分离架构由核心组件和外围组件组成。核心组件包括 TiDB、TiKV、PD 和 TiFlash，用于处理计算和存储任务。外围组件包括 BR 和 TiCDC 等，用于满足备份、数据共享等业务场景的需求。这些组件可以单独部署或混合部署，以满足隔离性和资源利用率的平衡。
在银行核心系统中，常见的部署模式是两地三中心。通过混沌测试，可以在实际的部署架构下模拟各种故障场景，评估系统的高可用能力和灾备接管能力。测试结果可以提供每个场景或多场景组合下的 RTO 和 RPO 指标，并帮助识别应用连接恢复的健壮性和透明性问题，以及发现可能存在的访问链路瓶颈。
验证系统的弹性
业务发展具有动态性，在突发的高流量高负载业务活动中，可能需要进行系统扩容以兼顾效率和稳定性。此外，X86 服务器相比小型机稳定性差、故障率高、生命周期短，需要通过扩缩容动作完成对硬件的升级和更换。基于这些因素，我们从两个维度对扩展性进行评估：
- TiDB 的线性扩展能力：评估 TiDB 在扩容后能否保持性能的线性增长，满足业务增长带来的性能需求。
- 扩缩容调整的便捷性、透明性和对业务的影响：评估扩缩容操作是否简单易行，对应用是否透明，对业务是否有影响以及影响程度。
检验应急预案有效性
利用混沌测试中涉及的破坏性测试场景，对应急预案进行全面的检验和优化，为上线后的运行维护做好充分准备。
优化监控和告警机制
利用混沌测试，可以有效检验告警系统的有效性和准确性，并对告警进行全面的查漏补缺和优化。通过测试验证和持续优化，确保告警及时、准确、等级合理、避免过度冗余。
准确评估外围作业的影响
生产业务系统涉及数据库备份、统计信息收集、TiCDC 数据同步等外围作业，以及版本/补丁升级、重启、扩缩容、硬件替换、容灾切换等运维作业。混沌测试应关注此类作业对系统负载、业务指标、网络流量等方面的影响，并优化相关的作业窗口和并发度，确保业务平稳运行。
混沌测试工具
我们以某商业银行核心场景为例，使用 Chaosd 工具来进行混沌测试的场景设计和演练。Chaosd 组件 ( https://chaos-mesh.org/zh/docs/chaosd-overview/ ) 是 Chaos Mesh ( https://chaos-mesh.org/zh/ ) 提供的一款混沌工程测试工具（需要单独下载和部署 ( https://chaos-mesh.org/zh/docs/chaosd-overview/#下载和部署 )），用于在物理机环境上注入故障，并提供故障恢复功能。
Chaos Mesh 是 PingCAP 自主研发的开源云原生混沌工程平台，提供丰富的故障模拟类型，具有强大的故障场景编排能力，方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常，帮助用户发现系统潜在问题。
Chaosd 具有以下核心优势：
- 易用性强：输入简单的 Chaosd 命令即可创建混沌实验，并对实验进行管理。
- 故障类型丰富：在物理机的不同层次、不同类型上都提供了故障注入的功能，包括进程、网络、压力、磁盘、主机等，且更多的功能在不断扩展中。
- 支持多种模式：Chaosd 既可作为命令行工具使用，也可以作为服务使用，满足不同场景的使用需求。
Chaosd 提供完善的可视化操作，旨在降低用户进行混沌工程的门槛。用户可以方便地在 Web UI 界面上设计自己的混沌场景，以及监控混沌实验的运行状态。你可以使用 Chaosd 模拟以下故障类型：
- 进程：对进程进行故障注入，支持进程的 kill、stop 等操作。
- 网络：对物理机的网络进行故障注入，支持增加网络延迟、丢包、损坏包等操作。
- 压力：对物理机的 CPU 或内存注入压力。
- 磁盘：对物理机的磁盘进行故障注入，支持增加读写磁盘负载、填充磁盘等操作。
- 主机：对物理机本身进行故障注入，支持关机等操作。
对于每种故障类型的详细介绍和使用方式，请参考对应的说明文档 Chaosd 组件简介 | Chaos Mesh ( https://chaos-mesh.org/zh/docs/chaosd-overview/ )。
混沌测试场景设计
混沌测试场景设计的原则是尽可能的模拟真实的生产情况。为了最大程度地模拟真实环境，测试的目标环境推荐使用准生产环境或按照生产环境设计要求搭建 1:1 仿真测试环境，并确保环境配置、部署架构、数据容量和业务负载等方面与预估上线后或系统设计要求一致。
测试从业务压力、故障注入、外围作业和运维操作等多个维度进行全方位测试，包括但不限于：
-
模拟真实的用户访问量和业务负载，以评估系统在高并发情况下的性能和稳定性。
-
注入各种硬件故障、软件故障和网络故障，以评估系统的故障处理能力和快速恢复能力。
-
模拟数据同步、备份作业等相关外围作业对资源使用的影响和 SQL 时延的影响。
-
模拟运维人员的日常操作，以评估系统的易用性和可维护性。
业务压力
交易型业务压力
混沌测试建议采用真实业务模型，通过等比例的业务流量进行压测，或者有条件的采用流量回放（生产环境流量需严格遵循安全管控流程，仅适用于生产域，且需进行脱敏处理）的形式进行。对于项目前期无法基于真实业务模型进行压力模拟的情况，可以选择部分较为核心（或简化）的业务模型进行压力模拟。
如果上述条件均不具备，也可采用 sysbench 进行压力注入。由于 sysbench 与真实业务模型存在较大差异，对性能边界的评估意义有限，但基本不影响对高可用、容灾能力、扩展性、检验和优化监控告警等其他方面的验证结果。
对于注入压力的大小，建议按梯队逐层加压展开：
- 生产（预估）TPS 指标
- 总设要求的 TPS 指标
- 总设要求的 TPS 指标 * N 倍 （1.5、2、3 ....，截止满足业务时延下的最高压力）
- 满足业务时延下的最高压力
- 基础环境负载打满的压力
以上几个梯队可以按需进行，兼顾测试成本，不建议过度细分压力场景。
对每个压力场景，记录各项基础环境和数据库实例级别的资源使用率、数据库 QPS/TPS、数据库 SQL 时延、端到端的业务时延、业务 TPS 等关键信息，建议将当时的压测场景结合关键的监控信息进行存档。以下登记表供参考（为方便展现，部分信息项简化合并)：
批量业务压力
银行核心业务中的日终、日切、日结、报表等批量类业务，并发量大，负载高，需按照真实的用户量和总设要求的承载用户量分别进行压力测试。除了根据用户量维度施加压力外，还需关注此类业务的并发度、作业编排等方面，以探索最佳的业务实践。
长稳压测
长稳压测建议以交易型业务压力为主（总设要求的 TPS 指标压力），结合实际情况周期性注入批量业务压力，开展 7*24 小时长稳压测，全面验证系统整体的可靠性和稳定性。此外，长稳压测还可以有效发现一些容易被忽略的潜在问题，例如基础硬件的质量问题、配置是否合理、全链路中的脆弱点和性能瓶颈等。
其他场景
按需根据实际的业务特点扩展测试场景，针对性地进行验证。例如测试表数据量增长对 SQL 响应时延的影响：
- 根据实际表结构进行数据量增长压测，模拟从百万级到十亿级数据量（甚至更多，兼顾测试成本按需进行即可，无需过度放大）的变化。
- 在同等业务压力下，使用实际的业务 SQL 测试响应时延、QPS、TPS 指标的变化。
故障注入
针对 TiDB 的故障注入测试可以从实际部署架构和故障面积两个维度进行设计，本文以同城双机房双活的 DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) （即 Data Replication Auto Synchronous，简称 DR Auto-Sync）进行介绍，其他部署架构的故障注入测试用例设计思路与此类似。故障注入和恢复后，需要关注的事项有：
- 对于业务量、QPS、TPS 的影响比例和持续时间
- 业务端到端的时延变化和持续时间
- SQL 的时延变化和持续时间
- 存活节点的资源使用变化
- 集群自身的负载均衡能力（如 leader 重新选举）
- 应用连接池重连能力（注意关注并优化连接池配置、负载探活配置）
以下故障注入跟踪表供参考（为方便展现，部分信息项简化合并)：
建议采用分级故障注入策略，实例级故障注入时需要根据不同的实例角色进行，服务器级故障注入时需要结合部署架构（尤其是存在混合部署情况下）进行。
外围作业
外围作业注入应关注相关作业对资源使用和 SQL 延迟的影响，并结合生产实际业务周期性变化的情况，优化作业窗口和并发度等配置。主要的外围作业包括全量物理备份、全量逻辑备份、BR log 备份（常驻作业）、统计信息收集和 TiCDC 数据同步（常驻作业）等。
运维操作
运维操作注入是模拟真实运维操作对 TiDB 系统的影响，需要关注的事项与故障注入一致，部分运维操作场景和故障注入场景可能存在重叠，主要包括的场景有：滚动重启、扩容（关注线性扩展比、对应用的透明度）、缩容、补丁/版本升级、在线 DDL（增、删、修改字段、创建索引）和容灾切换等。其中，容灾切换需要模拟各类场景进行重点测试，如测试系统在计划内切换（主备机房不停机）和计划外切换（主备机房完全失联）场景下的表现。
DR Auto-Sync 专项场景
DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) 适用于同城双机房 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 分布分别在单、双中心的四种场景组合进行测试，从而找到最佳方案。
混沌测试的收益和实战举例
掌握能力边界
混沌测试能够帮助我们全面了解系统的能力边界，为业务上线及后续的运维提供重要的参考依据，具体包括：获得当前配置和部署下数据库最高可承载的业务量，为容量规划提供指导；评估数据库的扩展能力，为未来的扩容提供指导；模拟各类故障对数据库服务能力的影响，进而验证和优化应急预案设计；模拟各类运维操作对数据库服务能力的影响，从而指导变更流程设计；模拟单表数据快速增长，评估对数据库性能的影响，并采取相应的优化措施。
实测结果举例：
系统弹性能力评估：
- 在线扩容、操作简单，对应用、对表物理模型完全透明。
- 容量、性能线性扩展比超过 90%。
单表数据量增长对 SQL 时延影响场景：
银行核心业务中，部分业务表（如交易流水表）数据量会随着业务办理而急剧增长，并需在生产集群中保留一定时间（超过一定周期转移到近线库，超过在线查询周期转移到带库存储）。这类表通常体积较大，银行客户基于对集中式数据库的使用经验，会担心单表数据量增长对性能产生影响。
为此，我们通过测试进行了验证。测试结果表明，单表数据（实测多张相关联业务表等比例增长）从百万级到 10 亿 急速增长的情况下，相关业务的 SQL 时延几乎不受影响，打消了客户的疑虑。如下图所示，短时间内少量业务流水表数据量急剧增长，相关业务 SQL 时延非常稳定，无明显变化。
获得最佳实践
混沌测试可以帮助我们发现系统全链路中的瓶颈点，从而进行针对性的优化，实现最佳实践。通过混沌测试，我们可以识别数据库部署架构和配置、负载均衡和探活配置、应用连接池和探活配置、双活架构下的数据库配置和流量分发、各类外围作业的时间窗口和并发度配置等方面存在的潜在问题，并进行相应的优化，例如调整数据库参数、调整流量分发规则、优化导入导出作业的并发度等。
实测结果举例:
-
Label 标签和服务器物理位置结合可以增强高可用能力：
- 以 5 副本架构为例，最多可以同时容忍两个 Label 标签下的服务器掉线
- 结合服务器物理位置规划，即可以同时容忍两组机柜下的服务器掉线
-
在“DR Auto-Sync 架构 + 应用双活部署”专项场景中我们得出的最佳实践：
- TiKV Leader 、PD Leader 指定在主机房
- 主、备机房负载均衡分别访问本机房 TiDB-Server
- 主、备机房流量按照 9:1 分发分发到本机房负载
提升高可用能力和优化应急预案
混沌测试能够帮助我们全面了解数据库在不同故障情况下服务能力的变化，从而检验应急预案的有效性，并针对性地进行优化。
实测结果举例:
- 单点的离线类（实例和服务器级的异常 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、业务影响比例受集群部署架构、故障实例个数、集群规模、业务负载特征、负载均衡探活策略等因素影响）：
优化监控告警机制
混沌测试可以帮助我们检验和优化监控告警，确保监控告警能够及时、有效地发现和识别系统故障。以下是一些对监控告警设置的建议：
- 确保告警覆盖所有的关键指标和组件，设置合理的探测频率。
- 设置适度的冗余，保证根因可以通过告警直接发现，提升告警的可靠性。
- 区别于集中式数据库，TiDB 作为原生分布式数据库具有原生高可用、高并发等特点，设置告警规则时需要考虑这些特点，避免简单的套用集中式数据库的告警思维。
- 建议以分类法进行告警梳理，确保告警覆盖面，可参考的分类维度有：运行状态类、黄金指标类、资源使用类、阈值类（结合配置参数）、日志和报错类、开发规范管控类（如慢 SQL / 全表扫描 SQL / 非规范语法）等。
过去一年，PingCAP 在金融行业场景累计完成数千个混沌演练测试，发现近百个问题。展望未来，PingCAP 将持续深耕金融行业，积极探索混沌工程在分布式数据库领域的应用，通过不断丰富的故障场景，结合故障诊断、根因分析等技术手段，做好故障沉淀积累，稳步提升 TiDB 处理异常事故及极端场景的应变能力，为金融业务稳健运行提供有力保障。
延展阅读：
- 金融行业内容专区上线，为金融机构数据库选型和应用提供深入洞察和可靠参考路径。立即浏览
目录