消息队列 on Liangweidong's blog

分布式锁 + 接口幂等 + 分布式事务 + 消息可靠性

Fri, 15 Sep 2023 00:00:00 +0800

本文写于 2023 年 9 月——Redisson 已经成为分布式锁事实标准，Seata AT 模式广泛落地，RocketMQ / RabbitMQ 可靠性投递也趋于成熟。

一、分布式锁

1.1 为什么需要分布式锁

ZooKeeper 有 Znode 顺序节点，数据库有表级锁和乐观/悲观锁，Redis 有 SETNX，殊途同归——最终还是要回到互斥上来。

实现	一致性	性能	复杂度	推荐场景
MySQL 行锁	强	低	低	不推荐
ZooKeeper 临时顺序节点	强	中	中	强一致场景
Redis SETNX + Lua	最终	高	低	通用
Redisson	最终	高	低	Java 生态首选

1.2 Redisson 分布式锁

引入依赖：

1
2
3
4
5


<dependency>
 <groupId>org.redisson</groupId>
 <artifactId>redisson</artifactId>
 <version>3.15.5</version>
</dependency>

配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@Configuration
public class MyRedissonConfig {
 
 @Bean(destroyMethod = "shutdown")
 public RedissonClient redisson() throws IOException {
 Config config = new Config();
 // 单机模式
 config.useSingleServer()
 .setAddress("redis://127.0.0.1:6379")
 .setDatabase(0);
 // 集群模式
 // config.useClusterServers()
 // .addNodeAddress("redis://127.0.0.1:7001", "redis://127.0.0.1:7002");
 return Redisson.create(config);
 }
}

伪代码：

1
2
3
4
5
6
7
8
9


// 1. 设置分布式锁
RLock lock = redisson.getLock("orderLock");
// 2. 占锁
lock.lock();
// 3. 执行业务
createOrder();
deductStock();
// 4. 释放锁
lock.unlock();

1.3 Redisson 锁的高级特性

锁类型	API	用途
可重入锁	`getLock(key)`	同一线程可多次 lock
公平锁	`getFairLock(key)`	按请求顺序排队
读写锁	`getReadWriteLock(key)`	读共享 / 写互斥
联锁（MultiLock）	`getMultiLock(lock1, lock2, ...)`	多资源原子加锁
红锁（RedLock）	`getRedLock(lock1, lock2, ...)`	跨机房强一致（谨慎使用）
信号量	`getSemaphore(key)`	限流
闭锁	`getCountDownLatch(key)`	协调多线程

1.4 接口防重（基于 Redisson）

思路：用 Redisson 的分布式锁给"幂等性"做兜底——同一用户 1 秒内多次点击只处理第一次。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


public boolean isRepeatSubmit(String userId, String bizType) {
 String key = "repeat:" + bizType + ":" + userId;
 RLock lock = redisson.getLock(key);
 try {
 // 尝试加锁，最多等 0 秒，锁 1 秒过期
 return lock.tryLock(0, 1, TimeUnit.SECONDS);
 } catch (InterruptedException e) {
 return false;
 }
}

二、接口幂等性

2.1 什么是接口幂等

幂等性：多次调用产生的结果与一次调用相同。

典型场景：

订单创建（重复点击 → 多个订单）
支付回调（网络重试 → 多次扣款）
表单提交（重复提交 → 重复数据）

2.2 基于 Redis + Lua 的接口幂等

思路：用 SETNX 抢锁，抢到就执行业务，LUA 保证释放锁时只删自己加的（避免误删别人的锁）。

Lua 释放锁脚本：

1
2
3
4
5


if redis.call('get', KEYS[1]) == ARGV[1] then
 return redis.call('del', KEYS[1])
else
 return 0
end

2.3 完整实现（注解 + AOP + CacheLock）

第一步：Redis 依赖

1
2
3
4


<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

第二步：自定义注解

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface CacheLock {
 /** key 前缀 */
 String prefix() default "";
 /** 过期秒数，默认 5 秒 */
 int expire() default 5;
 /** 超时时间单位 */
 TimeUnit timeUnit() default TimeUnit.SECONDS;
 /** Key 分隔符 */
 String delimiter() default ":";
}

第三步：AOP 切面

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


@Aspect
@Component
public class LockCheckAspect {
 
 /** Lua：释放锁时校验 value，避免误删 */
 private static final String RELEASE_LOCK_LUA_SCRIPT = 
 "if redis.call('get', KEYS[1]) == ARGV[1] then " +
 " return redis.call('del', KEYS[1]) " +
 "else return 0 end";
 
 @Autowired
 private RedisTemplate<String, Object> redisTemplate;
 
 @Pointcut("@annotation(cn.example.api.config.aop.CacheLock)")
 public void pointCut() {}
 
 @Around("pointCut()")
 public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
 // 1. 获取业务唯一 key（如用户手机号）
 String phone = getUserPhone();
 
 MethodSignature signature = (MethodSignature) joinPoint.getSignature();
 Method method = signature.getMethod();
 CacheLock cacheLock = method.getAnnotation(CacheLock.class);
 String prefix = cacheLock.prefix();
 if (StringUtils.isBlank(prefix)) {
 throw new GlobalException("CacheLock prefix can't be null");
 }
 
 // 2. 拼接 key
 String lockKey = prefix + cacheLock.delimiter() + phone;
 String uuid = cn.hutool.core.lang.UUID.fastUUID().toString();
 
 try {
 // 3. 抢锁：SETNX + 过期时间
 boolean success = redisTemplate.opsForValue()
 .setIfAbsent(lockKey, uuid, cacheLock.expire(), cacheLock.timeUnit());
 if (!success) {
 throw new CustomDeniedException("请勿重复提交");
 }
 
 // 4. 执行业务
 return joinPoint.proceed();
 } finally {
 // 5. 释放锁（Lua 原子操作，避免误删）
 DefaultRedisScript<Long> redisScript = 
 new DefaultRedisScript<>(RELEASE_LOCK_LUA_SCRIPT, Long.class);
 redisTemplate.execute(redisScript, Collections.singletonList(lockKey), uuid);
 }
 }
}

第四步：Controller

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@RestController
@RequestMapping("/charge")
@AllArgsConstructor
public class ChargeController {
 
 @PostMapping("/startCharge")
 @CacheLock(prefix = "recharge")
 public Result startCharge(@RequestBody @Validated ChargeQuery query) {
 return chargeService.startCharge(query);
 }
}

2.4 幂等性方案对比

方案	实现成本	性能	适用场景
数据库唯一索引	低	低	强幂等（如订单号）
Redis SETNX + Lua	中	高	通用
状态机	中	中	业务流（订单状态扭转）
Token 机制	中	高	防重提交
乐观锁 / version	低	中	更新场景

三、Seata 分布式事务

3.1 什么是 Seata

Seata（Simple Extensible Autonomous Transaction Architecture） 是阿里开源的分布式事务解决方案，致力于在微服务架构下提供 高性能 + 简单易用 的分布式事务服务。

官网：https://seata.io/zh-cn/

4 种事务模式：

AT（Auto Transaction，默认 + 最常用）
TCC（Try-Confirm-Cancel）
SAGA（长事务）
XA（强一致）

3.2 三大核心组件

角色	简称	作用
Transaction Coordinator	TC	事务协调器（Seata Server），维护全局/分支事务状态，驱动提交/回滚
Transaction Manager	TM	事务管理器（业务侧），定义全局事务范围，发起开始/提交/回滚决议
Resource Manager	RM	资源管理器（业务侧数据库），管理分支事务资源

部署架构：

TC：以 Seata Server 形式独立部署
TM + RM：以 Seata Client 形式集成在微服务中

3.3 工作流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


TM TC RM (Service-A) RM (Service-B)
│ │ │ │
│ 1. begin global tx │ │ │
│ ──────────────────> │ │ │
│ 2. 创建 XID = 192.168│ │ │
│ <────────────────── │ │ │
│ │ │ │
│ 3. RPC call ──────────────────────────────────────> │ │
│ (XID 透传) │ │ │
│ │ │ 4. register local │
│ │ <────────────────────────── │ branch to XID │
│ │ │ │
│ │ 5. RPC call ──────────────────────────────────────> │
│ │ │ │
│ │ <────────────────────────────────────── 6. register │
│ │ │ │
│ 7. commit / rollback │ │ │
│ ──────────────────> │ │ │
│ │ 8. 调度所有分支 ──────────> │ ────────────────────> │
│ │ 提交/回滚 │ │
│ │ <────────────── 9. 上报结果 │ <──────────────────── │

流程详解：

TM 向 TC 申请开启一个全局事务，全局事务创建成功后，TC 会针对这个全局事务生成全局唯一的 XID
XID 通过服务的调用链传递到其他服务
RM 向 TC 注册一个分支事务，并将其纳入 XID 对应全局事务的管辖
TM 根据 TC 收集的各个分支事务的执行结果，向 TC 发起全局事务提交或回滚决议
TC 调度 XID 下管辖的所有分支事务完成提交或回滚操作

3.4 AT 模式（最常用）

特点：与 AT 模式相比，AT 模式可以应对大多数业务场景，且基本可以做到无业务入侵，开发人员能够有更多精力关注于业务逻辑开发。

核心机制：

解析 SQL → 生成前镜像 + 后镜像 + 回滚日志（undo log）
提交本地事务，释放本地锁
申请全局锁（Seata Server 协调）
根据全局决议：
- 提交：异步删除回滚日志
- 回滚：用后镜像反向恢复为前镜像

使用示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Service
public class OrderService {
 
 @GlobalTransactional // 关键注解
 public void createOrder(Order order) {
 // 1. 扣库存（远程调用）
 storageService.deduct(order.getProductId(), order.getCount());
 // 2. 创建订单
 orderMapper.insert(order);
 // 3. 扣账户余额（远程调用）
 accountService.debit(order.getUserId(), order.getMoney());
 }
}

业务代码只需加 @GlobalTransactional 注解，Seata 自动处理分布式事务。

3.5 4 种模式对比

模式	一致性	性能	业务侵入	适用场景
AT	最终	高	无	通用（首选）
TCC	强	高	大	高性能 + 强一致
SAGA	最终	中	中	长事务 / 跨服务多步骤
XA	强	低	无	数据库支持 XA

四、消息队列可靠性

4.1 延迟消息的 4 种实现

场景：

网上直播授课时，在课程开始前 15 分钟通知所有学生准备上课
订单提交成功后1 小时内未支付，订单需要及时关闭并且释放对应商品的库存
用户超过 15 天未登录时，给该用户发送召回推送
工单提交后超过 24 小时未处理，向相关责任人发送催促处理的提醒

5 种实现方案：

方案	复杂度	精度	推荐
Redis 有序集合	低	秒级	短期延迟
RabbitMQ 插件 `rabbitmq_delayed_message_exchange`	中	毫秒级	短期延迟
ActiveMQ 内置	中	毫秒级	老项目
RocketMQ 内置	中	毫秒级	生产首选
定时任务 + 数据库扫描	低	分钟级	长延迟（> 小时）

4.2 RocketMQ 延迟消息实战

1
2
3
4
5
6


Message msg = new Message("OrderTopic", "orderTag", 
 JSON.toJSONBytes(order));
// 1 = 1s, 2 = 5s, 3 = 10s, 4 = 30s, 5 = 1m, 6 = 2m, 7 = 3m, 8 = 4m, ...
// 18 = 2h, ... 0 = 不延迟
msg.setDelayTimeLevel(3);
SendResult result = producer.send(msg);

4.3 定时任务 + 数据库（长延迟）

1
2
3
4
5
6
7
8


-- 订单表加字段
ALTER TABLE t_order ADD COLUMN close_status INT DEFAULT 0;
ALTER TABLE t_order ADD COLUMN expire_time DATETIME;

-- 每分钟扫描过期订单
SELECT id FROM t_order 
WHERE close_status = 0 AND expire_time < NOW() 
LIMIT 100;

1
2
3
4
5
6
7


@Scheduled(cron = "0 * * * * ?")
public void closeExpiredOrders() {
 List<Long> ids = orderMapper.selectExpiredIds(100);
 for (Long id : ids) {
 orderService.closeOrder(id);
 }
}

4.4 消息重复消费解决方案

问题根源：生产端为了保证消息发送成功，可能会重复推送（直到收到成功 ACK），会产生重复消息。

生产端：成熟的 MQ Server 框架一般会想办法解决，避免存储重复消息（比如空间换时间，存储已处理过的 message_id），给生产端提供一个幂等性的发送消息接口。

消费端：靠业务幂等性保证。

幂等方案	实现
唯一 ID + 数据库	消费前查 message_id 是否已处理
Redis SETNX	message_id 作为 key，重复消费被 Redis 拒绝
业务状态机	订单状态从 `已创建` → `已支付`，重复支付被业务拒绝
乐观锁 / version	每次更新带 version 字段

消费端代码示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@RocketMQMessageListener(topic = "OrderTopic", consumerGroup = "order-consumer")
public class OrderConsumer implements RocketMQListener<Order> {
 
 @Override
 public void onMessage(Order order) {
 String msgId = order.getMsgId();
 // 幂等：检查是否已处理
 Boolean processed = redisTemplate.opsForValue()
 .setIfAbsent("msg:" + msgId, "1", 7, TimeUnit.DAYS);
 if (Boolean.FALSE.equals(processed)) {
 log.info("重复消息，跳过：{}", msgId);
 return;
 }
 
 // 执行业务
 orderService.process(order);
 }
}

五、4 大方案对比与组合

问题	推荐方案	备选
分布式锁	Redisson	ZK 临时节点
接口幂等	Redis SETNX + Lua + 业务状态	数据库唯一索引
分布式事务	Seata AT	RocketMQ 事务消息
消息可靠性	RocketMQ 事务消息 + 消费端幂等	RabbitMQ confirm + 本地消息表

完整链路组合：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


用户下单
 ↓
@CacheLock (Redis SETNX 防重提交)
 ↓
@GlobalTransactional (Seata AT 分布式事务)
 ├── 1. 扣库存 RPC
 ├── 2. 创建订单 DB
 └── 3. 扣账户 RPC
 ↓
RocketMQ 事务消息发到下游
 ├── 库存系统消费（幂等）
 ├── 物流系统消费（幂等）
 └── 延迟消息：30 分钟后检查未支付订单关闭

六、面试常问

Q：Redisson 分布式锁怎么续期？ A：Redisson 默认开启 Watch Dog（看门狗）——加锁成功后，每 lockWatchdogTimeout / 3（默认 10s）自动续期到 30s。业务执行完调 unlock() 终止看门狗。如果业务执行超过 30s，看门狗会自动续期不会让锁过期。

Q：Redis 主从切换时分布式锁会失效吗？怎么解决？ A：会——主从复制是异步的，Master 写入锁后还没同步到 Slave 就宕机，Slave 升级为新 Master 但没有这个锁。解法：① Redisson RedLock（部署到多个独立 Master 节点）；② 业务幂等兜底（更推荐）。

Q：Seata AT 模式的全局锁和本地锁有什么区别？ A：

本地锁（SELECT ... FOR UPDATE）：事务执行期间持有，保证本事务内不并发写
全局锁（Seata Server 协调）：事务提交前持有，保证其他全局事务不会并发修改同一行
AT 模式先释放本地锁，再申请全局锁——这是它性能高的关键（写隔离）

Q：MQ 消息为什么一定会重复？怎么彻底解决？ A：网络不可靠 → 生产端重试 → 重复消息。彻底解决只能靠消费端业务幂等，因为没有任何 MQ 能保证"恰好一次"投递。RocketMQ 事务消息能保证"至少一次 + 业务幂等"。

七、小结

Redisson 分布式锁：Java 生态首选，可重入 / 公平 / 读写锁 + Watch Dog 自动续期
Redis + Lua 接口幂等：注解 + AOP 一行代码搞定重复提交
Seata AT 模式：无业务侵入的分布式事务，4 种模式中最常用
MQ 可靠性：生产端事务消息 + 消费端幂等 = 至少一次 + 幂等 = 恰好一次（业务层）

微服务中间件集群实战：Nacos / Gateway / MySQL / Redis / MQ

Wed, 15 Sep 2021 00:00:00 +0800

本文写于 2021 年 9 月——微服务架构全面铺开，Nacos 2.0+ 已发布一年（2020 年初）、Spring Cloud Gateway 已成事实标准（替代 Zuul）、Redis Cluster 在生产大规模使用，5 大微服务中间件的"集群"方案成为面试必考点。

〇、2021 视角开篇

本文主体内容是 5 大微服务中间件（Gateway / Nacos / MySQL / Redis / MQ）的集群部署实战。2021-09 这个时点选得很巧：

Nacos 2.0（2020-01 发布）刚满 1.5 年，集群方案已稳定（Distro + Raft 双协议）
Spring Cloud Gateway（2018 年发布）替代 Zuul 已成定局，2021.x 是生产主流
Redis Cluster（3.0 起）经过 4 年迭代，3 主 3 从 6 节点模式是生产标配
RocketMQ 4.x（2017 年起）多主多从模式是阿里系标配，Kafka 同期竞争

下文涉及 2016 年时实际并不存在的工具（Nacos / Spring Cloud Gateway），是以 2021 视角讲解"这些工具是何时出现、何时成熟、2021 时点怎么用"。

一、Spring Cloud Gateway 集群

1.1 概述

Spring Cloud Gateway 是 Spring Cloud 的全新项目，基于 Spring 5.0 + Spring Boot 2.0 实现，旨在提供一种简单有效的方式对 API 进行路由，并提供强大的过滤功能：熔断、限流、监控、校验、鉴权。

为什么取代 Zuul？

Zuul 1.x 基于 Servlet 阻塞模型，性能有限
Zuul 2.0 跳票多年（被 Netflix 弃坑），Spring 社区转向基于 WebFlux + Netty 的响应式网关
Gateway 基于 WebFlux 框架，底层用 Netty 通信框架，性能远超 Zuul

1.2 集群部署

Gateway 是无状态服务，集群化非常简单：多实例 + 统一入口。

第一步：pom.xml 依赖

1
2
3
4
5
6
7
8


<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

第二步：application.yml 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


server:
 port: 9527

spring:
 application:
 name: cloud-gateway
 cloud:
 nacos:
 discovery:
 server-addr: nacos-cluster.internal:8848  # Nacos 集群地址
 gateway:
 discovery:
 locator:
 enabled: true # 开启从注册中心自动创建路由
 routes:
 - id: payment_route
 uri: lb://cloud-payment-service  # lb = load balance
 predicates:
 - Path=/payment/**

第三步：Nginx 入口负载均衡

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


upstream gateways {
 server 192.168.6.29:9527 weight=1;
 server 192.168.6.29:9528 weight=1; # 同一台机器两个端口模拟集群
 # server 192.168.6.30:9527 weight=1; # 多机部署
}

server {
 listen 80;
 server_name api.example.com;
 location / {
 proxy_pass http://gateways;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 }
}

关键点：

Gateway 实例之间不需要通信，各自从 Nacos 拉服务列表
网关自身的负载均衡交给 Nginx / F5 / SLB
网关是无状态服务，可以水平扩展

二、Nacos 集群

2.1 三种部署模式

单机模式：用于测试和单机使用
集群模式：用于生产环境，确保高可用
多集群模式：用于多数据中心场景

2.2 集群部署（Nacos ≥ 2.0）

前置：nacos 集群至少需要 3 个节点，因此准备 3 台服务器。

第一步：安装依赖

1
2
3


# 1. 安装 MySQL（nacos 配置持久化）
# 2. 安装 JDK 8+
# 3. 安装 Maven（仅首次构建时需要）

第二步：初始化数据库

执行 nacos 自带 SQL：conf/nacos-mysql.sql，创建 nacos_config 数据库和表。

第三步：配置 cluster.conf

将 conf/cluster.conf.example 改名为 cluster.conf：

1
2
3
4


# cluster.conf
192.168.6.21:8848
192.168.6.22:8848
192.168.6.23:8848

第四步：配置 application.properties

1
2
3
4
5


spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://192.168.6.10:3306/nacos_config?useUnicode=true&characterEncoding=utf-8
db.user=nacos
db.password={{REDACTED}}

第五步：启动

1

sh startup.sh

单台服务器启动成功后，对集群其他服务器重复同样操作即可。

2.3 集群原理

Distro 协议（AP 模式，默认）：nacos 自研的最终一致协议，每个节点负责一部分服务，多节点互写互读
Raft 协议（CP 模式，配置中心）：持久化配置走 Raft，保证强一致
节点间通过 gRPC 长连接 同步数据

三、MySQL 主从集群

3.1 集群目的

采用 MySQL 集群需要部署主从关系：

主节点：写数据（INSERT / UPDATE / DELETE）
从节点：读数据（SELECT）
关系：一主多从，用户从多个从节点读数据，大大缓解读取压力
额外收益：主节点写入自动同步到从节点，降低数据丢失风险

3.2 主从复制原理

MySQL 主从复制基于主服务器二进制日志（binlog） 跟踪所有对数据库的更改。

工作过程：

1
2
3
4
5
6
7
8
9


┌─────────┐ ┌─────────┐
│ Master │ │ Slave │
│ │ │ │
│ binlog │ <── (1) 读 binlog ─── I/O 线程 ──│ relay │
│ dump │ │ log │
│ 线程 │ ── (2) 传 binlog ───────────> │ │
│ │ │ SQL 线程│
│ │ <── (3) 同步完成通知 ───────────│ │
└─────────┘ └─────────┘

从库生成两个线程：一个 I/O 线程，一个 SQL 线程
I/O 线程请求主库的 binlog，并将 binlog 写到 relay log（中继日志）
主库生成 log dump 线程，用来给从库 I/O 线程传 binlog
SQL 线程读取 relay log，解析成具体操作，实现主从一致

3.3 核心配置

主库 my.cnf：

1
2
3
4
5


[mysqld]
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
binlog-format = ROW
sync_binlog = 1

从库 my.cnf：

1
2
3
4


[mysqld]
server-id = 2
relay-log = /var/lib/mysql/relay-log
read-only = 1

主库授权：

1
2


grant replication slave on *.* to 'repl_user'@'%' identified by '{{REDACTED}}';
flush privileges;

从库配置同步：

1
2
3
4
5
6
7
8
9


CHANGE MASTER TO
 MASTER_HOST='192.168.6.21',
 MASTER_USER='repl_user',
 MASTER_PASSWORD='{{REDACTED}}',
 MASTER_LOG_FILE='mysql-bin.000001',
 MASTER_LOG_POS=0;

START SLAVE;
SHOW SLAVE STATUS\G # 看 Slave_IO_Running: Yes, Slave_SQL_Running: Yes

3.4 读写分离

两种实现方式：

数据库中间件（Mycat / Sharding-Proxy）：单独部署服务，配置实现读写分离，不侵入业务代码
客户端 SDK（dynamic-datasource / shardingsphere-jdbc）：业务代码引入 jar 包，通过注解切换

dynamic-datasource 示例（Spring Boot）：

1
2
3
4
5


<dependency>
 <groupId>com.baomidou</groupId>
 <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
 <version>3.3.2</version>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


spring:
 datasource:
 dynamic:
 primary: master
 datasource:
 master:
 url: jdbc:mysql://192.168.6.21:3306/test
 username: root
 password: {{REDACTED}}
 driver-class-name: com.mysql.cj.jdbc.Driver
 slave1:
 url: jdbc:mysql://192.168.6.22:3306/test
 username: root
 password: {{REDACTED}}
 driver-class-name: com.mysql.cj.jdbc.Driver

1
2
3
4
5
6
7
8


@Service
public class OrderService {
 @DS("master") // 写主库
 public void createOrder(Order order) { ... }
 
 @DS("slave1") // 读从库
 public List<Order> listOrders() { ... }
}

3.5 分库分表

两种方案：

Sharding Sphere（推荐）：JDBC 代理 / Proxy 模式
Mycat 2：数据库中间件，需要独立部署

四、Redis 集群

4.1 三种集群方案

主从复制模式：1 主 N 从，主写从读，但主挂了不会自动切换（需要手动）
Sentinel（哨兵）模式：在主从基础上加哨兵进程监控，主挂了自动选举新主（推荐中小规模）
Cluster 模式：Redis 3.0+ 官方方案，数据分片 + 主从 + 自动故障转移（推荐大规模）

4.2 集群部署（Cluster 模式）

官方推荐：集群至少 3 个 master 节点，最好用 3 主 3 从 6 节点模式。

1
2
3
4
5
6


# 启用集群模式
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
# 至少 3 个 master
cluster-migration-barrier 1

创建集群：

1
2
3
4


redis-cli --cluster create \
 192.168.6.31:6379 192.168.6.32:6379 192.168.6.33:6379 \
 192.168.6.34:6379 192.168.6.35:6379 192.168.6.36:6379 \
 --cluster-replicas 1

4.3 Cluster 原理

数据分片：16384 个 slot（哈希槽），每个 master 负责一段
请求路由：客户端通过 CRC16(key) % 16384 计算 slot
重定向：如果请求路由到错误节点，会返回 MOVED 或 ASK 让客户端重试
故障转移：master 挂了，从节点通过 Raft-like 协议选举新主

五、消息队列集群

5.1 RabbitMQ 集群

普通集群：多节点共享元数据，队列只在单节点，性能提升有限
镜像集群：队列数据多节点同步，HA 能力强但性能低
推荐方案：普通集群 + HAProxy + 镜像队列（关键业务队列）

5.2 RocketMQ 集群

NameServer 集群：无状态，多节点即可
Broker 集群：分 Master / Slave
- 多 Master：高性能但无 HA
- 多 Master 多 Slave（异步复制）：性能 + HA 平衡
- 多 Master 多 Slave（同步双写）：强 HA，性能低
推荐方案：2 主 2 异步从 + 异步刷盘

六、5 大集群对比

集群	核心协议	关键配置	HA 能力	数据一致性
Gateway	无（无状态）	Nginx upstream	自动（多实例）	无（无状态）
Nacos	Distro + Raft	cluster.conf + MySQL	自动（≥3 节点）	AP+CP 混合
MySQL	binlog + relay log	server-id + log-bin	半自动（需切换）	最终一致
Redis Cluster	哈希槽（16384）	cluster-enabled	自动（≥3 master）	最终一致
RabbitMQ	镜像队列	cluster_partition_handling	自动（镜像）	最终一致
RocketMQ	主从同步	brokerRole	自动（多主多从）	异步/同步

七、面试常问

Q：为什么 Nacos 集群至少 3 个节点？ A：Raft 协议要求过半节点存活才能选举 Leader，3 节点允许 1 节点宕机，5 节点允许 2 节点宕机。奇数节点是性价比最高的选择。

Q：MySQL 主从延迟怎么解决？ A：① 业务容忍延迟（异步复制天然有 ms 级延迟）；② 强制读主（重要业务读写都走主）；③ 半同步复制（MySQL 5.7+ rpl_semi_sync_master_wait_slave_count）；④ 用 Canal 订阅 binlog 同步到 ES / Redis。

Q：Redis Cluster 为什么是 16384 个 slot？ A：因为 16384 足够均匀分布，节点间心跳包大小可控（每个 slot 1 bit，16384 / 8 = 2KB，远小于 1MB 网络包上限）。如果用 65536，心跳包会膨胀到 8KB，且实际场景下节点数不会超过 1000，16384 足够。

Q：Spring Cloud Gateway 怎么限流？ A：内置 RequestRateLimiter GatewayFilter，基于 Redis + Lua 脚本实现令牌桶。Key 可以基于 IP / User / API Path。

八、小结

Gateway 无状态：集群 = 多实例 + 入口 LB
Nacos 集群：3 节点起步 + MySQL 持久化
MySQL 主从：binlog 同步 + 读写分离中间件
Redis Cluster：16384 哈希槽 + 3 主 3 从
MQ 集群：RabbitMQ 镜像队列 / RocketMQ 多主多从

九、2021 视角回望（微服务面试考点演化）

站在 2021-09 收尾，回看"5 大集群对比"那一节，再补充几点2021 时点的面试新趋势：

Nacos 2.0 的 gRPC 长连接：2020 年 Nacos 2.0 把数据同步从 HTTP 短连接改成长连接，性能提升 10 倍，是高频面试追问点
Spring Cloud Gateway 限流细节：内置 RequestRateLimiter + Redis Lua 是高频八股文，几乎所有 Java 面试都会问
MySQL 5.7 → 8.0 升级：2021 年 5.7 EOL 时间已定（2023-10），8.0 的 MGR（MySQL Group Replication）开始被生产采用
Redis 6.x 的多线程 IO：2020 年 Redis 6.0 发布，IO 多线程化但执行命令仍单线程，集群方案未变
Kafka vs RocketMQ 二选一：阿里系项目用 RocketMQ（事务消息），其他用 Kafka（生态 + 吞吐），2021 年仍是常见面试题

2021 时点的"5 大集群面试"标准答案：

Gateway 无状态 → 集群 = Nginx upstream + 多实例
Nacos 集群 → 至少 3 节点（过半选举） + MySQL 持久化 + gRPC 2.0 同步
MySQL 主从 → binlog + relay log + 读写分离（ShardingSphere / dynamic-datasource）
Redis Cluster → 16384 哈希槽 + 3 主 3 从 + 客户端路由
MQ 集群 → RabbitMQ 镜像队列 / RocketMQ 多主多从（同步双写保 HA）