如何设计一个高可用的 Seata 集群？

——从零搭建永不宕机的分布式事务协调系统

---

一、为什么需要高可用 Seata 集群？

在分布式系统中，事务协调器TC是全局事务的“大脑”。一旦TC单点故障：

• 灾难性后果：所有进行中的全局事务将卡死，业务完全不可用
• 数据不一致风险：已提交的事务可能无法完成最终提交或回滚
  因此，构建高可用Seata集群是生产环境的必选项！

---

二、Seata 高可用架构设计核心要点

1. TC 集群化部署

• 多节点部署：至少部署3个TC实例（奇数节点，便于选举）
• 注册中心集成：使用 Nacos、Eureka 或 Zookeeper 实现服务发现

  # seata-server 配置注册中心  
  registry {  
    type = "nacos"  
    nacos {  
      application = "seata-server"  
      serverAddr = "192.168.1.10:8848,192.168.1.11:8848"  
      namespace = ""  
      cluster = "default"  
    }  
  }  
  

2. 存储层高可用

Seata依赖存储层持久化事务日志，需保证存储层无单点故障：

• 推荐方案：
  • 数据库模式：MySQL集群（主从复制 + VIP漂移）

    store {  
      mode = "db"  
      db {  
        datasource = "druid"  
        url = "jdbc:mysql://mysql-vip:3306/seata?useSSL=false"  
        user = "seata"  
        password = "seata@123"  
      }  
    }  
    

  • Redis模式：Redis Sentinel 或 Redis Cluster

    store {  
      mode = "redis"  
      redis {  
        host = "redis-sentinel:26379"  
        mode = "sentinel"  
        sentinelMasterId = "mymaster"  
      }  
    }  
    

3. 客户端负载均衡

客户端需支持自动切换TC节点：

• Spring Cloud 方案：

  seata:  
    tx-service-group: my_tx_group  
    service:  
      vgroup-mapping:  
        my_tx_group: "default"  
      enable-degrade: false  
      disable-global-transaction: false  
    registry:  
      type: nacos  
      nacos:  
        application: seata-server  
        server-addr: 192.168.1.10:8848,192.168.1.11:8848  
        namespace: ""  
  

• 非Spring Cloud方案：在 file.conf 中配置多个TC地址

4. 集群节点自动发现

通过注册中心实现动态扩缩容：

• Nacos 示例：

  # 启动Seata Server时指定集群名  
  sh seata-server.sh -p 8091 -h 192.168.1.20 -n 3 \  
    -e test -m db -r nacos  
  

---

三、高可用保障进阶策略

1. 异地多活部署

• 同城双活：在同一城市部署2个机房，TC跨机房组成集群
• 异地灾备：通过 Seata的AP模式（最终一致性）容忍网络分区

2. 健康检查与自动故障转移

• Kubernetes方案：

  # Kubernetes Deployment配置存活探针  
  livenessProbe:  
    httpGet:  
      path: /actuator/health  
      port: 7091  
    initialDelaySeconds: 30  
    periodSeconds: 10  
  readinessProbe:  
    httpGet:  
      path: /actuator/health  
      port: 7091  
    initialDelaySeconds: 30  
    periodSeconds: 10  
  

3. 监控与告警

• 监控指标：
  • TC节点存活状态
  • 全局事务TPS/RT
  • 锁竞争次数、重试次数
• Prometheus + Grafana：

  # Seata暴露Metrics端点  
  metrics:  
    enabled: true  
    registry-type: compact  
    exporter:  
      enabled: true  
      port: 9898  
  

---

四、避坑指南：生产环境血泪教训

1. 存储层必须高可用

• 绝对禁止：使用单机MySQL或单Redis节点！
• 定期备份：事务日志表（global_table、branch_table）

2. 网络分区容错

• 设置合理超时：

  # 客户端与TC通信超时  
  client.tm.degradeCheckPeriod=2000  
  client.rm.reportRetryCount=3  
  

3. 避免脑裂问题

• 注册中心配置：Nacos/Zookeeper自身需集群化
• TC节点时钟同步：使用NTP服务确保时间一致

---

五、验证方案：如何测试高可用性？

1. 模拟TC节点宕机：

   # 随机kill一个TC进程  
   kill -9 $(ps -ef | grep seata-server | grep -v grep | awk '{print $2}')  
   

2. 观察事务恢复：
   • 检查其他TC节点是否接管事务
   • 确认客户端自动重连新节点

---

六、终极架构图

        Client Apps
              │  
              ▼  
        Load Balancer
              │  
       ┌──────┼──────┐  
       ▼      ▼      ▼  
    [TC1]  [TC2]  [TC3]  ← 通过注册中心同步状态  
       │      │      │  
       └──────┼──────┘  
              ▼  
   高可用存储层（MySQL Cluster/Redis Sentinel）

---

记住黄金法则：
“TC无单点、存储多副本、客户端能切换、监控无盲区”
做好这四点，你的Seata集群将坚如磐石！