你是否有过对 Spring Cloud Alibaba 、Spring Cloud、Spring Boot 版本之间的选择而脑壳疼？是否有过对源码环境搭建的迷茫？是否思考过多个源码环境之间的依赖问题？本文将给与你一切答案。

## 版本选择

[Spring Cloud Alibaba 与 Spring Cloud 、Spring Boot 版本依赖](https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E)

![image.png](https://blog.liushigong.cn/static/img/968fd77d667f99e2511010e37befabec.image.webp)

## Nacos 源码下载

首先需要下载源码 [Nacos-2.2.0](https://gitee.com/mirrors/Nacos/tree/2.2.0/)，默认 master 分支，下载后切换标签为 `2.2.0` 即可

接着进行编译

```
mvn clean install -DskipTests -Drat.skip=true -f pom.xml
```

提示 potobuf 的引用类不存在的处理

先找到 `consistency`、`istio` 和 `api` 模块进行编译

启动是在 `console` 模块下，找到 `com.alibaba.nacos.Nacos`

![image.png](https://blog.liushigong.cn/static/img/b5700d6d34c58decf95fd1c6a9c42834.image.webp)

启动源码服务时候指定参数 `-Dnacos.standalone=true`

![image.png](https://blog.liushigong.cn/static/img/e001f06cf59eaae596795b74ccb0a599.image.webp)

## Spring Cloud Alibaba 源码下载

现在主流的微服务方式都是结合 Spring Cloud Alibaba，现在我们来解决下多个源码之间的依赖

下载源码 [Spring-Cloud-Alibaba](https://gitee.com/mirrors/Spring-Cloud-Alibaba/tree/2021.x/)

下载源码 [spring-cloud-commons](https://github.com/spring-cloud/spring-cloud-commons.git)

将下载的源码合并到一个 idea 中

![image.png](https://blog.liushigong.cn/static/img/d21abfe1db5f0b0b191d53a34313a871.image.webp)

查看 Spring Cloud Alibaba 项目中的对 `nacos-client` 依赖包，发现此处没有源码包，那我们就调整成依赖本地的服务当做源码

![image.png](https://blog.liushigong.cn/static/img/b62ebe74edbb1efd62c2834a3d4a371e.image.webp)

首先查看本地 Naocs 的版本，在最外层的 pom 中，版本是 `2.2.0-SNAPSHOT`

![image.png](https://blog.liushigong.cn/static/img/d8fa8e70ae6d18195855b0cf53289406.image.webp)

由于源码中内置了 `maven-source-plugin` 插件，所以直接 install 便可打出 source.jar 包

![image.png](https://blog.liushigong.cn/static/img/1802f30c493d95aaa697f18018136cab.image.webp)

找到 `Spring-Cloud-Alibaba` 项目中的 `nacos-client` 的版本依赖，将此源码依赖调整为 `2.2.0-SNAPSHOT`

![image.png](https://blog.liushigong.cn/static/img/88aca8b1147d2b9d13267e156c7c4ce5.image.webp)

此时刷新下maven，在查看依赖，就会显示我们本地的项目做为源码环境了

![image.png](https://blog.liushigong.cn/static/img/f432e55bd168d2875912265222d70129.image.webp)

此时查看 Spring Cloud Alibaba 中对 nacos-client 的依赖，则会直接跳转到本地源码项目中

![image.png](https://blog.liushigong.cn/static/img/36557f51076ffa24a4f96b19e0227b18.image.webp)

Spring Cloud Alibaba 版本选择与源码环境搭建

某天，监控警报突然响起，"消息队列积压量已达10万+"。你手忙脚乱地打开系统，看着堆积如山的消息，是不是第一反应就是"赶紧加消费者"？别急，让我告诉你：MQ堆积不是问题，而是常态；没有堆积，MQ 就失去了存在的意义。

## 你真的会应对消息队列中的消息堆积吗？

咱们今天来聊一个老生常谈，但一出事就能让你手忙脚乱的话题：消息队列（MQ）里的消息堆积了，咋整？

先给大家吃个定心丸：**MQ堆积，从本质上来说，就是一种常态，是常有发生的事情**。

为啥？因为 MQ 的核心使命就是“削峰填谷”啊！想象一下，上游业务像洪水一样哗哗地来，如果没有 MQ 这个“大水库”先存着，下游的业务“小村庄”分分钟就被冲垮了。如果 MQ 里从来都是即来即走，一丁点堆积都没有，那反而说明它根本没起到缓冲作用，这钱白花了。

提示

**MQ 的核心价值就是削峰填谷** ——当流量突增时，它把压力缓冲下来，让下游系统能平稳处理。如果MQ从不堆积，那它就不是在削峰，而是在"添峰"。所以，当看到堆积时，请先深呼吸：这不是故障，而是MQ在正常工作。

所以，给业务做了削峰填谷，MQ这个“水库”里肯定得有积水（也就是堆积）。那么，洪水来了，总要有人去开闸泄洪或者加固堤坝吧？没错，那个人就是你，那个可能深夜里被告警短信吵醒的“运维/开发大冤种”。

但当你看到监控告警红灯闪烁，CPU飙升的时候，千万别脑子一热，第一反应就是：“快！加机器！加消费者！” 这就好比家里漏水了，你不管三七二十一先叫来一队装修工人，结果发现只是猫把水龙头打开了——纯属瞎折腾。

注意

**所以说遇到堆积，先别急着加机器~~~~**

### 第一步：冷静下来，先“望闻问切”

你得像个老中医一样，先沿着告警的问题去排查，搞清楚当前是哪个业务场景的消息堆积了。

* 看场景：是哪个Topic？哪个Consumer Group出了问题？
* 看上游：上游业务的流量是不是突然爆增了？比如搞了大促活动，或者有个定时任务（比如对账、报表生成）正在疯狂跑批？
* 看堆积：消息堆积的数量是多少？是几万条还是几百万条？增长的速度是快是慢？
* 看消费：现在的消费速度是多少？处理一条消息的平均耗时是毫秒级还是秒级？

### 第二步：对症下药，分情况讨论

诊断完了，就可以开药方了。情况无非以下几种：

#### 情况一：正常的高峰期，业务可容忍延迟

如果发现确实是业务流量高，或者有定时任务在跑，但你的消费者处理速度也还跟得上，只是消费得慢一点。并且，在你的业务场景下（比如发通知、更新非核心数据），晚几分钟处理完是可以接受的。

**解决方案：**

那就别瞎动了！让它慢慢消费呗，这是MQ正在履行它的神圣职责。你只需要盯着监控，确保堆积量在可接受范围内并正在逐步下降就行。这时候你乱操作，反而可能引入新问题。

#### 情况二：高峰期，业务无法容忍延迟

同样是高峰期，但你的业务场景对延迟很敏感（比如核心交易链路），老板要求必须快速处理掉堆积。

**解决方案：**

临时动态扩容。 这是最直接有效的临时方案。马上加几台消费者实例，或者适当提高处理线程数（如果用的是线程池模型），先把洪峰扛过去。等流量下去了，再缩容，控制成本。这叫“战时紧急状态”，先保障业务。

#### 情况三：业务量平稳，但突然堆积（这才是最吓人的）

这种情况最诡异：业务量屁都没增长，也没什么定时任务，但MQ堆积的曲线图却突然翘头向上。这说明问题大概率出在 **消费者本身**。

这时候，你的排查方向要立刻转向内部：

* **是不是出现慢SQL了？** 这是最常见的原因！你的服务跑得好好的，为什么突然慢了？很可能是随着数据库里的数据量日积月累，之前某个不规范的查询变成了慢SQL，拖慢了整个消息处理流程。
* **是不是缓存失效了？** 比如某个热点Key突然失效，导致大量请求直接穿透到数据库，把数据库打慢，进而拖累消费速度。
* **是不是下游接口超时了？** 你的消费者需要调用另一个服务B的接口，结果服务B挂了或者响应极慢，你的消费者就只能干等着，卡在那里。

“哦，排查到这儿，破案了！原来不是MQ的锅，是我自己的代码有问题。” 这时候，解决方案就非常明确了：

* 解决慢SQL：加索引、优化查询语句、甚至做分库分表。
* 解决缓存问题：检查缓存策略，防止缓存击穿/雪崩。
* 解决下游依赖：联系下游团队，或者自身增加熔断、降级策略，避免被拖死。

#### 终极“保底”大法：异步落库，解耦消费

上面都是“治标”或“治已病”的方案。对于一些特别核心、绝对不能丢、且允许一定延迟的业务，我们可以考虑一种“治本”的架构设计，我称之为 **“先收单，后处理”** 模式。

具体流程是这样的：

1. 快速收单：消费者接到MQ消息后，不做复杂的业务逻辑，只做一件事——以最快速度将消息内容存储到自己的本地数据库（或一个高性能存储里），并记录状态为“待处理”。
2. 立即应答：存库成功后，立刻告诉 MQ：“兄弟，我消费成功了！”（发送ACK）。这样，消息就从MQ中删除了，从根本上避免了MQ 的堆积和因投递失败次数过多导致消息被删除的风险。
3. 异步处理：然后，再启动一个或多个后台线程或定时任务，从容不迫地从本地数据库里捞取“待处理”的消息，慢慢执行真正的业务逻辑。
4. 更新状态：处理成功后，将本地消息状态更新为“已完成”或直接删除。如果处理失败，可以记录失败次数，下次重试。

```
java

// 伪代码：先收单存储，再执行
public void processMessage(Message message) {
    // 1. 先将消息存入数据库（先收单）
    messageDao.save(message);
    
    // 2. 立即返回ACK，告诉MQ已消费
    ack();
    
    // 3. 异步执行业务逻辑
    executor.submit(() -> {
        try {
            // 业务处理
            processBusiness(message);
            // 处理成功，从数据库删除
            messageDao.delete(message.getId());
        } catch (Exception e) {
            // 处理失败，标记状态，等待重试
            messageDao.updateStatus(message.getId(), "FAILED");
        }
    });
}
```

这种方案能有效避免MQ堆积，同时防止因处理失败导致消息被删除。即使处理失败，也能通过定时任务重试，确保消息最终被处理。

### 预防胜于治疗：从源头避免堆积

应对堆积是救火，预防堆积才是治本。**真正的技术能力，不在于你能否解决堆积，而在于你能否在堆积发生前就预防它**。需要建立以下机制：

* 完善的监控告警：设置合理的堆积阈值（如堆积量>1万时告警）
* 弹性消费设计：消费者支持自动扩缩容，根据堆积量动态调整实例数
* 流量控制：在生产端增加限流机制，避免流量突增
* 定期性能优化：每月分析慢SQL、优化关键路径
* 压力测试：模拟高流量场景，验证系统处理能力

## 总结

所以，面对消息堆积，别再只会“加机器”三板斧了。总结一下正确的姿势：

* 冷静分析：先排查，确定问题场景。
* 分类处理：是可接受延迟，还是需临时扩容，或是消费者自身出了BUG？
* 根治优化：解决代码层面的慢查询、缓存、下游依赖等问题。
* 架构升级：对于关键业务，考虑采用“异步落库”的方式，与MQ彻底解耦。

消息堆积不可怕，可怕的是没有思路的胡乱操作。希望下次告警再响起时，你能淡定地端起茶杯，微微一笑：“小样，又来了？看我怎么收拾你。”

你真的会应对消息队列中的消息堆积吗？

最大努力通知型分布式事务原理与实战

可靠消息投递分布式事务原理与实战

分布式系统架构中，数据一致性是一个永恒的话题。相较于强一致的 XA 模式，TCC 模式以其高性能和最终一致性保障，成为互联网分布式事务的经典解决方案。本文将深入剖析TCC事务的原理，并通过 Seata 框架演示其实现过程。

## 为什么需要 TCC？

在微服务架构中，一个业务操作往往需要调用多个服务，这些服务有自己独立的数据库，这就构成了一个分布式事务。传统的 XA 协议基于 **两阶段提交（2PC）** 实现强一致性，但其存在 **同步阻塞、资源锁定时间长、性能低下** 等致命问题，难以应对高并发场景。

TCC（Try-Confirm-Cancel）事务模型应运而生。它是一种 **业务层面** 的分布式事务解决方案，通过 **最终一致性来保障数据一致性**，释放了数据库层的资源锁定，从而获得了更高的性能，非常适合互联网业务。

## TCC 模式深度解析

TCC 的本质是将一个完整的业务逻辑拆分为三个操作，由业务代码本身实现。

### 三个阶段

TCC 模式对应的三个操作就是将分布式事务拆分为三个阶段，每个阶段都有明确的职责

#### Try 阶段（尝试阶段）

**目的**：完成所有业务的检查，并预留必需的资源，也就是不提交事务，仅进行资源预留

**操作**：是一种预备操作，而非最终操作。例如：

* 库存服务：检查库存充足与否，并预扣（冻结）相应数量的库存（将库存数量减去，冻结库存加上）。
* 账户服务：检查账户余额是否充足，并冻结要支付的金额（将余额减去，冻结金额加上）。
* 优惠券服务：检查优惠券是否有效，并将其状态标记为“已锁定”。

**特点**：Try 阶段成功，意味着后续的 Confirm 阶段基本一定会成功。

#### Confirm （确认阶段）

**目的**：真正执行业务，使用Try阶段预留的资源。Confirm操作需要保证幂等性。

**操作**：在Try成功的基础上，执行真正的业务操作。例如：

* 库存服务：将冻结库存扣减（即清零），生成出库记录。
* 账户服务：将冻结金额扣减（即清零），生成支付流水。
* 优惠券服务：将优惠券状态更新为“已使用”。

**执行条件**：只有当所有参与者的Try操作都成功时，事务协调者才会调用Confirm。

#### Cancel （取消阶段）

**目的**：释放Try阶段预留的资源。Cancel操作同样需要保证幂等性。

**操作**：在Try阶段失败或任何参与者执行失败时，用于回滚。例如：

* 库存服务：将预扣的库存释放回可售库存（库存数量加回，冻结库存减去）。
* 账户服务：将冻结的金额解冻（余额加回，冻结金额减去）。
* 优惠券服务：将优惠券状态恢复为“未使用”。

**执行条件**：只要有一个参与者的Try操作失败，事务协调者就会调用Cancel。

提示

TCC 是一种 **侵入式** 的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的入侵性，设计相对复杂，但优点是 TCC 完全不依赖数据库，能够实现跨数据库、跨应用资源管理，对这些不同数据访问通过侵入式的编码方式实现一个原子操作，更好地解决了在各种复杂业务场景下的分布式事务问题。

### TCC 模式的工作流程

![image.png](https://blog.liushigong.cn/static/img/b62d9f8a6e48640224b1ecb8f9b9aa9c.image.webp)

**全局事务开始**：由事务发起方（如订单服务）调用 `@GlobalTransactional` 标记的入口方法

**Try阶段**：各参与服务执行 Try 操作，预留资源

* 所有Try操作成功 → 进入 Confirm 阶段
* 任一Try操作失败 → 进入 Cancel 阶段

**Confirm/Cancel阶段**：

* Confirm：所有服务执行 Confirm 操作，正式提交事务
* Cancel：所有服务执行 Cancel 操作，回滚事务

### TCC 的优缺点

**优点：**

* 高性能：一阶段Try操作直接提交，释放数据库资源，性能远高于XA。
* 最终一致性：基于补偿机制，实现数据的最终一致。
* 灵活性：事务的粒度由业务控制，可以做得非常细。

**缺点：**

* 代码侵入性强：需要业务系统自行实现Try、Confirm、Cancel三个接口，开发量大。
* 业务逻辑复杂：设计“预留资源”的逻辑通常比较反直觉，增加了设计和开发的复杂度。
* 幂等性要求：必须保证Confirm和Cancel操作的幂等性，以应对网络重试等问题。
* 空回滚和防悬挂：需要处理一些特殊异常场景（下文会详解）。

## Seata TCC 模式剖析

Seata 框架将 TCC 模式融入到其全局事务模型中，极大地简化了 TCC 模式的使用复杂度。

### Seata TCC 架构

在Seata TCC模式中，三个角色依然存在：

* **TM (Transaction Manager)**：定义事务边界，通过@GlobalTransactional注解开启全局事务。
* **RM (Resource Manager)**：每一个参与 TCC 事务的微服务都是一个 RM，它们需要实现 TCC 的三个接口。
* **TC (Transaction Coordinator)**：Seata 服务器，负责维护全局事务和分支事务的状态，驱动全局提交或回滚。

### TCC 接口与注解

Seata 通过注解将普通接口标识为 TCC 资源。核心注解是 `@LocalTCC` 和 `@TwoPhaseBusinessAction`。

* `@LocalTCC`：应用于接口上，表明该接口是一个TCC模式的RM。
* `@TwoPhaseBusinessAction(name= "...", commitMethod= "...", rollbackMethod= "...")`：标注在Try方法上，用于将 Try 方法与 Confirm/Cancel 方法关联起来。

  + name：TCC事务的actionName，必须全局唯一。
  + commitMethod：Confirm阶段执行的方法名。
  + rollbackMethod：Cancel阶段执行的方法名。

### 异常场景处理

这是 TCC 模式实现中最需要谨慎处理的部分，seata 框架也是在1.5.1版本解决了此类问题，有兴趣的小伙伴可以阅读下 [阿里 Seata 新版本终于解决了 TCC 模式的幂等、悬挂和空回滚问题](https://seata.apache.org/zh-cn/blog/seata-tcc-fence/)

#### 空回滚 (Empty Rollback)

**场景**：Try 方法未执行（可能因为网络超时），但 Cancel 方法却被 TC 调用了。

**原因**：TM 认为 Try 超时失败，触发全局回滚。但 RM 实际上并未执行 ry，资源未被预留。

**解决方案**：在 Cancel 方法中，需要检查当前事务 ID（XID）对应的业务记录是否存在。如果不存在（即 Try 没执行），则需要执行一次“空回滚”操作（记录一条回滚日志即可），避免释放了未冻结的资源。

#### 防悬挂 (Anti-Suspension)

**场景**：Cancel 方法比 Try 方法先执行（空回滚发生后，Try 请求才到达 RM）。

**原因**：网络拥堵，导致二阶段的 Cancel 指令比一阶段的 Try 指令更早到达 RM。

**解决方案**：在 Try 方法中，需要检查当前XID是否已经执行过空回滚（即检查空回滚日志）。如果已执行过，则拒绝执行 Try 业务逻辑，实现“防悬挂”。

#### 幂等性 (Idempotency)

**场景**：TC 因未收到 RM 的响应，会重复调用 Confirm 或 Cancel 方法。

**解决方案**：在 Confirm 和 Cancel 方法中，需要根据事务状态表或业务数据的状态来判断当前操作是否已经执行过。如果已执行，则直接返回成功。

## 适用场景与最佳实践

**适用场景**

* 金融交易系统：如转账、支付等对一致性要求高的场景
* 库存管理：如电商系统的库存扣减
* 订单处理：涉及多个服务的订单创建流程

**最佳实践**

* Try阶段尽量轻量：Try操作只做资源检查和预留，避免复杂业务逻辑
* Confirm/Cancel操作幂等：确保操作可重复执行而不影响结果
* 事务超时设置：合理设置事务超时时间，避免长时间挂起
* 异常处理：在Try、Confirm、Cancel中妥善处理异常，确保事务状态正确

## 总结

TCC分布式事务模型通过 **业务拆解** 和 **补偿机制**，巧妙地避开了数据库资源锁定的瓶颈，实现了高性能的最终一致性。虽然它带来了 **代码侵入性** 和 **设计复杂性**，但其优越的性能表现使其成为互联网分布式事务解决方案的首选之一。

Seata 通过简洁的 API 和配置，大大降低了 TCC 模式的使用门槛。在实际项目中，建议根据业务特点选择合适的事务模式：对于对一致性要求极高的核心业务，TCC 模式是理想选择；而对于一致性要求相对宽松的场景，AT 模式可能更为合适。