374 lines
12 KiB
Markdown
374 lines
12 KiB
Markdown
# 中间件高可用部署综合指南
|
||||
|
|
|
|||
|
|
## 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的统一管理,确保了系统在节点故障时能够自动进行灾备转换,保障业务的连续性和可用性。
|
|||
|
|
|
|||
|
|
建议在实际部署过程中,根据业务需求和资源情况,对各中间件的配置进行适当调整和优化,以达到最佳的性能和可用性。
|