1. 引言

在当今的在线数据处理与交易处理（OLTP）业务场景中，数据库的高可用性与横向扩展能力是保障业务连续性与性能的关键。MyCat作为一个开源的分布式数据库中间件，通过实现MySQL协议的代理，提供了数据分片、读写分离、故障切换等核心功能，是构建高可用、可扩展数据库集群的重要组件。本文档（工作笔记0030）旨在记录基于MyCat构建高可用集群架构的设计要点，并阐述在模拟在线交易业务场景下进行高可用性验证的具体实践。

2. MyCat高可用集群架构设计

一个典型的、面向高可用的MyCat分布式数据库集群架构通常包含以下几个层次：

2.1 应用接入层
业务应用程序通过标准MySQL驱动连接MyCat服务。为实现高可用，应用端需配置多个MyCat节点地址，并具备连接失败重试机制，或使用VIP（虚拟IP）结合Keepalived等工具实现访问入口的自动漂移。

2.2 MyCat中间件层（核心）
这是架构的核心。高可用设计主要在此层实现：

• 多节点部署：至少部署两个或以上的MyCat服务节点，避免单点故障。
• 状态同步：确保所有MyCat节点共享相同的配置文件（如schema.xml, rule.xml, server.xml），可通过分布式配置中心（如ZooKeeper、Nacos）或自动化同步工具管理。
• 故障检测与切换：借助Keepalived或HAProxy实现。常用方案是MyCat + Keepalived：
• 为多个MyCat节点分配一个虚拟IP（VIP）。

• Keepalived运行在主备MyCat节点上，通过心跳机制监控MyCat进程健康状态。

• 当主节点MyCat服务失效，Keepalived将VIP自动漂移到健康的备用节点，实现客户端的无感知切换。

2.3 后端数据库层
- 数据分片集群：数据被水平拆分到多个MySQL分片（Shard）中，每个分片本身也需要高可用。
- 分片高可用：每个分片采用MySQL主从复制（或基于Group Replication的MGR集群）构成一组。MyCat可配置读写分离，写操作发往主库，读操作可分发到从库。
- 故障感知：MyCat需要能够检测后端MySQL节点的状态。通过heartbeat标签在配置中定义心跳SQL，MyCat定期执行以判断节点是否存活。

3. 高可用性验证方案（模拟OLTP业务场景）

验证目标是确保在MyCat节点或后端数据库节点发生故障时，整个数据库服务对前端OLTP业务的影响最小，数据一致性与业务连续性得到保障。

3.1 验证环境准备
- 部署架构：两个MyCat节点（MyCat-01, MyCat-02）+ Keepalived，后端为两组MySQL主从集群（分片db01group, db02group）。
- 模拟业务：开发简单的模拟OLTP应用，持续执行典型操作：用户登录验证（SELECT）、下单（INSERT）、支付更新（UPDATE）、查询订单（JOIN查询）等。
- 监控工具：监控MyCat日志、MySQL状态、网络连接及业务应用错误率。

3.2 验证场景与步骤

场景一：MyCat中间件节点故障
1. 初始状态：VIP位于MyCat-01（主），模拟业务稳定运行，所有请求通过MyCat-01处理。
2. 故障注入：手动停止MyCat-01的服务进程。
3. 观察与验证：
- Keepalived应检测到MyCat-01失效，并在数秒内将VIP漂移至MyCat-02。

• 模拟业务可能会出现短暂的连接异常（取决于客户端连接池设置），但应能在超时重试后自动连接到新的VIP（即MyCat-02），业务逐渐恢复。

• 验证所有业务操作（增删改查）在恢复后均能正常执行，且数据一致性无误（如刚提交的订单不丢失）。

1. 恢复操作：重启MyCat-01，它应作为备用节点加入，不影响当前流量。

场景二：后端MySQL主库故障（某个分片）
1. 初始状态：业务正常运行，例如订单表数据分布在两个分片。
2. 故障注入：停止db01_group的主库（写库）。
3. 观察与验证：
- MyCat通过心跳检测应能快速（取决于心跳间隔）标记该主库为down。

• 对于路由到该故障分片的写操作，MyCat应能根据配置的switchType（如切换至备库写）进行响应。本例中，若配置了主从切换且从库可写（需配合半同步等确保数据安全），写请求应被路由至提升后的新主库。

• 模拟业务中涉及该分片的操作，在短暂失败后应能继续。需重点关注数据一致性，确保故障前已确认的交易在从库升级后可见。

• 对于其他健康分片的业务应完全无影响。

1. 恢复操作：修复原主库，以从库身份重新同步后加入集群。

场景三：网络分区或脑裂情况
测试Keepalived的优先级、抢占机制及心跳线配置，确保VIP不会出现脑裂。可断开主节点网络，观察VIP切换及恢复后的抢占行为是否符合预期。

4. 关键注意事项与优化点

• 心跳配置：合理设置heartbeat语句与间隔，在故障检测速度和数据库压力间取得平衡。
• 超时与重试：业务客户端和连接池（如Druid, HikariCP）必须配置合理的连接超时、查询超时和失败重试逻辑。
• 数据一致性：在MySQL主从切换时，是强一致性方案（如使用MGR）还是最终一致性方案（异步复制），需根据业务容忍度选择，并制定相应的数据核对与补偿流程。
• 监控告警：建立完善的监控，覆盖MyCat节点状态、后端数据库状态、VIP归属、业务关键指标（TPS、响应时间、错误率）等。
• 定期演练：高可用架构不应只停留在设计，需定期进行故障演练，确保自动切换流程可靠，团队应对熟练。

5.

通过构建MyCat（多节点+Keepalived） + MySQL（分片+主从）的集群架构，并针对在线交易业务特点设计全面的故障注入验证方案，可以建立起一个具备较高可用性的分布式数据库解决方案。验证的核心在于证明故障发生时，服务的恢复是自动、快速且数据一致的，从而为核心OLTP业务提供稳定可靠的数据支撑。后续工作应聚焦于性能压测、更复杂的故障场景模拟（如双节点同时故障）以及自动化运维工具的集成。