# 中间件高可用部署综合指南

## 1. 文档概述

本指南基于两台高性能服务器加一台低配置服务器的组合方案，详细介绍各中间件的核心功能、高可用部署方案以及灾备转换的基本原理。所有中间件均采用容器化部署，确保部署一致性和可维护性。

## 2. 部署架构总览

### 2.1 节点配置

| 节点类型     | 数量 | 配置                  | 角色分配                             |
| ------------ | ---- | --------------------- | ------------------------------------ |
| 高性能服务器 | 2    | CPU/内存/存储配置较高 | 核心业务处理节点，部署所有中间件服务 |
| 低配置服务器 | 1    | CPU/内存/存储配置较低 | 仅参与选举和监控，不部署核心业务服务 |

### 2.2 整体架构图

```mermaid
graph TB
    %% 机器 A
    subgraph Srv_A [高性能服务器 A: .230]
        direction TB
        KA[Keepalived M]
        AppA[业务应用集群]
        subgraph MW_A [中间件/数据库]
            MA[(MySQL M1)]
            RA[Redis Master]
            RMA[RocketMQ Broker M]
        end
        subgraph Cluster_Comp_A [集群仲裁/管理 A]
            RS1[Redis Sentinel 1]
            RNC1[RMQ NS/Controller 1]
            NA[Nacos/PowerJob]
        end
    end

    %% 机器 B
    subgraph Srv_B [高性能服务器 B: .200]
        direction TB
        KB[Keepalived B]
        AppB[业务应用集群]
        subgraph MW_B [中间件/数据库]
            MB[(MySQL M2)]
            RB[Redis Slave]
            RMB[RocketMQ Broker S]
        end
        subgraph Cluster_Comp_B [集群仲裁/管理 B]
            RS2[Redis Sentinel 2]
            RNC2[RMQ NS/Controller 2]
            NB[Nacos/PowerJob]
        end
    end

    %% 机器 C
    subgraph Srv_C [仲裁服务器 C: .110]
        KC[Keepalived Arbiter]
        RS3[Redis Sentinel 3]
        RNC3[RMQ NS/Controller 3]
    end

    %% VIP 逻辑
    VIP((Virtual IP: .233))
    KA -.->|管理| VIP
    KB -.->|管理| VIP

    %% 核心访问流
    AppA & AppB ==> VIP
    VIP ==> MA & MB

    %% 跨机数据同步
    MA <==>|双主复制| MB
    RA --->|主从同步| RB
    RMA <==>|同步| RMB
    NA <==>|同步| NB

    %% 集群内部协调 (逻辑表示)
    RS1 --- RS2 --- RS3
    RNC1 --- RNC2 --- RNC3

    %% 监控选主关系 (虚线)
    RS1 & RS2 & RS3 -.->|监控/选主| RA & RB
    RNC1 & RNC2 & RNC3 -.->|路由/选主| RMA & RMB

    %% 样式
    classDef server fill:#f0f5ff,stroke:#2f54eb;
    classDef arbiter fill:#fff1f0,stroke:#ff4d4f;
    classDef vip fill:#f6ffed,stroke:#52c41a,stroke-width:2px;

    class Srv_A,Srv_B server;
    class Srv_C arbiter;
    class VIP vip;
```

## 3. 中间件详细说明

### 3.1 Keepalived

#### 3.1.1 核心功能

- 实现VIP（虚拟IP）的高可用管理
- 自动故障检测和VIP切换
- 防止脑裂问题

#### 3.1.2 高可用部署方案

- **部署模式**：三节点集群（2台高性能服务器+1台低配置服务器）
- **角色分配**：
  - 高性能服务器A：Master节点（基础优先级110）
  - 高性能服务器B：Backup节点（基础优先级100）
  - 低配置服务器C：Arbiter节点（基础优先级40，仅参与选举）
- **核心配置**：
  - VIP：192.168.3.233
  - 采用单播通信方式
  - 集成MySQL健康检查脚本

#### 3.1.3 灾备转换原理

- **优先级规则**：VIP归属由有效优先级决定，基础优先级A > B > C
- **故障检测**：通过脚本检测MySQL端口，故障时优先级扣减50
- **脑裂防护**：Arbiter节点确保至少2/3节点正常才能进行VIP切换
- **切换流程**：
  1. 检测到Master节点故障
  2. Backup节点发起选举
  3. 获得Arbiter节点支持后成为新Master
  4. 绑定VIP并提供服务

### 3.2 MySQL

#### 3.2.1 核心功能

- 关系型数据库服务
- 数据持久化存储
- 双主双向复制

#### 3.2.2 高可用部署方案

- **部署模式**：双主（Source-Source）复制集群
- **节点分配**：仅部署在2台高性能服务器上
- **核心配置**：
  - GTID + AUTO_POSITION：自动定位同步位点
  - ROW模式binlog：保证复制一致性
  - 自增键隔离：A节点生成奇数主键，B节点生成偶数主键
  - 持久化配置：innodb_flush_log_at_trx_commit=1，sync_binlog=1

#### 3.2.3 灾备转换原理

- **双主同步**：两台节点互为主从，实时同步数据
- **故障检测**：通过Keepalived的健康检查脚本检测MySQL端口
- **切换流程**：
  1. Keepalived检测到MySQL故障
  2. 降低对应节点优先级
  3. VIP自动切换到健康节点
  4. 应用通过VIP继续访问MySQL服务

### 3.3 Redis

#### 3.3.1 核心功能

- 分布式缓存服务
- 数据持久化存储
- 高可用故障转移

#### 3.3.2 高可用部署方案

- **部署模式**：Redis Sentinel集群
- **节点分配**：
  - 2台高性能服务器：部署Redis主从节点
  - 3台服务器：均部署Sentinel节点
- **核心配置**：
  - 主从复制：1主1从
  - Sentinel集群：3节点，quorum=2
  - 持久化：AOF + RDB混合模式
  - 密码认证：统一密码管理

#### 3.3.3 灾备转换原理

- **健康检测**：Sentinel节点定期检查Redis主从状态
- **故障判定**：当quorum个Sentinel节点判定主节点故障时触发故障转移
- **切换流程**：
  1. Sentinel集群选举Leader
  2. Leader选择最优Slave节点
  3. 将Slave提升为新Master
  4. 配置其他Slave指向新Master
  5. 通知客户端更新主节点信息

### 3.4 Nacos

#### 3.4.1 核心功能

- 服务注册与发现
- 配置中心
- Dubbo注册中心

#### 3.4.2 高可用部署方案

- **部署模式**：集群部署
- **节点分配**：部署在2台高性能服务器上，配置1个虚拟节点
- **核心配置**：
  - 数据库存储：MySQL持久化元数据
  - 集群规模：3节点（2实际+1虚拟）
  - 数据同步：基于数据库的共享存储

#### 3.4.3 灾备转换原理

- **无状态设计**：所有节点共享同一MySQL数据库
- **故障恢复**：节点故障后，其他节点自动接管服务
- **客户端容错**：客户端配置多个Nacos地址，自动切换

### 3.5 PowerJob

#### 3.5.1 核心功能

- 分布式任务调度
- 多样化任务类型支持
- 任务管理与监控

#### 3.5.2 高可用部署方案

- **部署模式**：集群部署
- **节点分配**：部署在2台高性能服务器上
- **核心配置**：
  - 数据库存储：MySQL持久化任务信息
  - 集群通信：基于Akka实现节点间通信
  - 负载均衡：任务自动分配到可用节点

#### 3.5.3 灾备转换原理

- **无状态设计**：所有节点共享同一MySQL数据库
- **任务容错**：节点故障时，任务自动转移到其他节点执行
- **客户端配置**：Worker节点配置多个Server地址，自动切换

### 3.6 RocketMQ

#### 3.6.1 核心功能

- 分布式消息中间件
- 高吞吐、高可用
- 支持事务消息、延时消息
- 自动主从切换

#### 3.6.2 高可用部署方案

- **部署模式**：Controller模式集群
- **节点分配**：
  - 3台服务器：均部署NameServer和Controller
  - 2台高性能服务器：部署Broker（1主1从）
- **核心配置**：
  - Controller集群：基于jRaft实现，3节点
  - Broker配置：ASYNC_MASTER + SLAVE
  - 持久化：异步刷盘

#### 3.6.3 灾备转换原理

- **Controller集群**：基于Raft协议选举Leader，管理Broker元数据
- **自动主从切换**：
  1. Controller监控Master Broker状态
  2. 检测到故障后，选举最优Slave
  3. 将Slave提升为新Master
  4. 更新NameServer中的路由信息
  5. 客户端自动获取新的Master地址

## 4. 灾备转换流程

### 4.1 单节点故障场景

```mermaid
graph TB
    %% 故障离线节点 (服务器 A)
    subgraph Srv_A [高性能服务器 A: .230 <br/> 🔴 全机离线]
        direction TB
        KA[Keepalived - 离线]
        AppA[业务应用 - 离线]
        subgraph MW_A [中间件/数据库]
            MA[(MySQL - 离线)]
            RA[Redis - 离线]
            RMA[RMQ Broker - 离线]
        end
    end

    %% 故障转移后的活动节点 (服务器 B)
    subgraph Srv_B [高性能服务器 B: .200 <br/> 🟢 承载全量业务]
        direction TB
        KB[Keepalived - Master]
        AppB[业务应用 - 正常]
        subgraph MW_B [中间件/数据库]
            MB[(MySQL - Master)]
            RB[Redis - NEW Master]
            RMB[RMQ Broker - NEW Master]
        end
        subgraph Cluster_B [管理节点]
            NB[Nacos/PowerJob]
            RNCB[RMQ NS/Controller]
        end
    end

    %% 仲裁节点 (服务器 C)
    subgraph Srv_C [仲裁服务器 C: .110]
        KC[Keepalived Arbiter]
        RS[Redis Sentinel 集群]
        RNCC[RMQ NS/Controller]
    end

    %% VIP 与流量重定向
    VIP((Virtual IP: .233))
    KB ==>|接管| VIP
    AppB ==>|内部访问| VIP
    VIP ==>|读写| MB

    %% 故障转移逻辑 (核心连线)
    RS -.->|1.检测到故障| RA
    RS ==>|2.提升为主| RB

    RNCC -.->|1.检测到故障| RMA
    RNCC ==>|2.提升为主| RMB

    %% 样式定义
    classDef offline fill:#f5f5f5,stroke:#d9d9d9,stroke-dasharray: 5 5,color:#bfbfbf;
    classDef active fill:#e6f7ff,stroke:#1890ff,stroke-width:2px;
    classDef arbiter fill:#fff1f0,stroke:#ff4d4f;
    classDef highlight fill:#f6ffed,stroke:#52c41a,stroke-width:2px;

    class Srv_A,KA,AppA,MA,RA,RMA offline;
    class Srv_B,KB,AppB,MB,RB,RMB,NB,RNCB active;
    class Srv_C,KC,RS,RNCC arbiter;
    class VIP highlight;
```

### 4.2 灾备转换步骤

1. **故障检测**：各中间件自身的健康检查机制或外部监控系统检测到节点故障
2. **优先级调整**：Keepalived根据健康状态调整节点优先级
3. **VIP切换**：Keepalived将VIP绑定到优先级最高的健康节点
4. **服务接管**：
   - Redis：Sentinel选举新Master
   - RocketMQ：Controller自动将Slave提升为Master
   - MySQL：应用通过VIP访问健康节点
   - Nacos/PowerJob：健康节点自动接管服务
5. **客户端切换**：客户端通过配置的多节点地址自动连接到健康节点

## 5. 监控与维护

### 5.1 监控指标

| 中间件     | 核心监控指标                               |
| ---------- | ------------------------------------------ |
| Keepalived | VIP状态、节点优先级、健康检查结果          |
| MySQL      | 主从复制状态、连接数、查询响应时间、慢查询 |
| Redis      | 主从状态、内存使用率、命中率、连接数       |
| Nacos      | 服务注册数量、配置更新次数、节点状态       |
| PowerJob   | 任务执行成功率、任务堆积量、节点状态       |
| RocketMQ   | 消息堆积量、发送/消费TPS、Broker状态       |

### 5.2 维护建议

1. **定期备份**：定期备份数据库、配置文件和重要数据
2. **日志管理**：配置日志轮转，定期清理过期日志
3. **安全加固**：
   - 开启访问认证
   - 配置防火墙规则
   - 定期更新密码
4. **性能优化**：
   - 根据负载调整资源配置
   - 优化中间件参数
   - 定期进行性能测试
5. **灾备演练**：定期进行故障模拟演练，验证灾备转换流程

## 6. 总结

本指南基于两台高性能服务器加一台低配置服务器的组合方案，详细介绍了各中间件的高可用部署方案和灾备转换原理。通过合理的角色分配和架构设计，实现了资源的优化利用和系统的高可用性。

各中间件均采用容器化部署，通过Keepalived实现VIP的统一管理，确保了系统在节点故障时能够自动进行灾备转换，保障业务的连续性和可用性。

建议在实际部署过程中，根据业务需求和资源情况，对各中间件的配置进行适当调整和优化，以达到最佳的性能和可用性。