Camel in Action事务与幂等性完全教程XA分布式事务、补偿机制防重复消息实战【免费下载链接】camelinaction2:camel: This project hosts the source code for the examples of the Camel in Action 2nd ed book :closed_book: written by Claus Ibsen and Jonathan Anstey.项目地址: https://gitcode.com/gh_mirrors/ca/camelinaction2本项目是《Camel in Action》第二版的官方示例源码由 Camel 创始人 Claus Ibsen 与 Jonathan Anstey 编写。本文带你快速掌握Apache Camel 事务的完整体系从丢失消息的经典故事到XA 分布式事务两阶段提交实战、补偿机制再到用幂等性消费者根治重复消息问题。为什么消息系统需要事务很多新手的第一反应是消息队列已经很可靠了还需要事务吗chapter12/riderautoparts-partner模块给出了教科书式的反面案例——丢失消息的故事某汽车零件公司用 JMS 队列接收合作伙伴的请求消费端在先确认消息、再写数据库的流程中崩溃消息永远丢失了。罪魁祸首是autoAcknowledge确认模式消息还没处理完就被确认掉了。正确做法是客户端确认Client Acknowledge处理成功后再手动确认。相关示例见 ClientAckBean.java可用以下命令验证cd chapter12/riderautoparts-partner mvn test -DtestRiderAutoPartsPartnerClientAcknowledgeModeTest本地事务 vs XA 全局事务一张表看懂 这是选型时最关键的一步对比项本地事务LocalXA 全局事务2PC适用场景单一资源一个队列或一个数据库跨资源消息队列 数据库一致性保证资源内部所有资源原子提交/回滚性能高较低协调开销对应示例tx-database/xa/XA 即两阶段提交2-Phase Commit先让所有参与者准备全部就绪后统一提交任何一环失败则整体回滚。XA 分布式事务实战提交与回滚的完整流程chapter12/xa是本章的核心实战模块演示消息队列与数据库如何在一个 XA 事务中保持一致✅提交场景XACommitTest从 ActiveMQ 消费消息并写入数据库事务成功提交✅回滚场景XARollbackBeforeDbTest/XARollbackAfterDbTest分别在写库前、后抛出异常验证数据库回滚、消息进入DLQ死信队列而不会丢失以 SpringXARollbackAfterDbTest.java 为例它模拟消息已入队、数据库已写入、随后处理失败的极端情况——最终数据库中 0 行记录、消息安全落在ActiveMQ.DLQ这正是生产环境最需要的保证。运行方式cd chapter12/xa mvn test -DtestSpringXACommitTest事务传播机制REQUIRES_NEW 实现部分回滚现实中最棘手的问题一个步骤失败难道前面成功的全都要回滚chapter12/propagation演示了事务传播策略Propagation。比如订单主流程与审计日志分别使用不同传播级别订单回滚时审计日志通过REQUIRES_NEW独立提交保留故障现场。核心 Bean AuditLogService.java 会把每条订单连同JMSRedelivered是否重投标志写入审计表是排障的黄金数据。UnitOfWork 工作单元没有事务时的补偿机制 ️并非所有组件都支持事务。Camel 的UnitOfWork工作单元是它的补偿方案chapter12/uow模块演示了三种关键能力同步回调Synchronization监听事务结束事件onCompletion 模式只在全部路由执行成功后才确认消息——失败则不确认消息会被重投而不是丢失BeforeConsumer 模式消费前就标记防止重复处理该模块还附有一个完整的 REST 订单服务OrderRoute.java可用curl -i http://localhost:8080/service/order/123体验返回头中生成的防重复 token。幂等性消费者防重复消息的终极手段 消息重投、负载均衡重试、网络抖动……重复消息是分布式系统的家常便饭。chapter12/idempotent用Idempotent Consumer幂等性消费者EIP优雅解决它。看 IdempotentTest.java 的路由设计from(seda:inbox) .idempotentConsumer(header(orderId), repo) .to(mock:order) .end();路由中用idempotentConsumer以orderId消息头作为唯一键配合仓库对象repo记录已处理的消息。测试一次性发送 5 条订单消息其中 2 条重复最终只有3 条唯一订单被处理——重复消息被自动过滤且断言保证了零重复。开箱即用的幂等仓库实现Camel 自带多种 IdempotentRepository 实现按需选择MemoryIdempotentRepository内存实现示例默认使用重启即失效InfinispanIdempotentRepository基于 Infinispan 缓存适合集群共享JCache / JPA标准化缓存或持久化到数据库重启后依然生效下图展示了 Infinispan 控制台中的缓存视图幂等键数据即存储于此快速上手三步跑通全部示例1️⃣ 克隆项目git clone https://gitcode.com/gh_mirrors/ca/camelinaction22️⃣ 进入第 12 章目录cd camelinaction2/chapter123️⃣ 按需运行各模块测试每个子模块都有独立 README.md 说明cd xa mvn test cd idempotent mvn test总结如何为你的场景选型✅你的场景推荐方案参考模块单资源仅数据库或仅队列本地事务tx-database队列 数据库强一致XA 全局事务xa部分步骤需保留审计场景事务传播 REQUIRES_NEWpropagation组件不支持事务UnitOfWork onCompletionuow消息可能重复投递幂等性消费者idempotent消息丢失排查客户端确认模式riderautoparts-partner一句话记忆XA 管一致性UnitOfWork 管补偿幂等性管不重复——三者组合就是生产级消息系统的可靠性基石。【免费下载链接】camelinaction2:camel: This project hosts the source code for the examples of the Camel in Action 2nd ed book :closed_book: written by Claus Ibsen and Jonathan Anstey.项目地址: https://gitcode.com/gh_mirrors/ca/camelinaction2创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Camel in Action事务与幂等性完全教程XA分布式事务、补偿机制防重复消息实战【免费下载链接】camelinaction2:camel: This project hosts the source code for the examples of the Camel in Action 2nd ed book :closed_book: written by Claus Ibsen and Jonathan Anstey.项目地址: https://gitcode.com/gh_mirrors/ca/camelinaction2本项目是《Camel in Action》第二版的官方示例源码由 Camel 创始人 Claus Ibsen 与 Jonathan Anstey 编写。本文带你快速掌握Apache Camel 事务的完整体系从丢失消息的经典故事到XA 分布式事务两阶段提交实战、补偿机制再到用幂等性消费者根治重复消息问题。为什么消息系统需要事务很多新手的第一反应是消息队列已经很可靠了还需要事务吗chapter12/riderautoparts-partner模块给出了教科书式的反面案例——丢失消息的故事某汽车零件公司用 JMS 队列接收合作伙伴的请求消费端在先确认消息、再写数据库的流程中崩溃消息永远丢失了。罪魁祸首是autoAcknowledge确认模式消息还没处理完就被确认掉了。正确做法是客户端确认Client Acknowledge处理成功后再手动确认。相关示例见 ClientAckBean.java可用以下命令验证cd chapter12/riderautoparts-partner mvn test -DtestRiderAutoPartsPartnerClientAcknowledgeModeTest本地事务 vs XA 全局事务一张表看懂 这是选型时最关键的一步对比项本地事务LocalXA 全局事务2PC适用场景单一资源一个队列或一个数据库跨资源消息队列 数据库一致性保证资源内部所有资源原子提交/回滚性能高较低协调开销对应示例tx-database/xa/XA 即两阶段提交2-Phase Commit先让所有参与者准备全部就绪后统一提交任何一环失败则整体回滚。XA 分布式事务实战提交与回滚的完整流程chapter12/xa是本章的核心实战模块演示消息队列与数据库如何在一个 XA 事务中保持一致✅提交场景XACommitTest从 ActiveMQ 消费消息并写入数据库事务成功提交✅回滚场景XARollbackBeforeDbTest/XARollbackAfterDbTest分别在写库前、后抛出异常验证数据库回滚、消息进入DLQ死信队列而不会丢失以 SpringXARollbackAfterDbTest.java 为例它模拟消息已入队、数据库已写入、随后处理失败的极端情况——最终数据库中 0 行记录、消息安全落在ActiveMQ.DLQ这正是生产环境最需要的保证。运行方式cd chapter12/xa mvn test -DtestSpringXACommitTest事务传播机制REQUIRES_NEW 实现部分回滚现实中最棘手的问题一个步骤失败难道前面成功的全都要回滚chapter12/propagation演示了事务传播策略Propagation。比如订单主流程与审计日志分别使用不同传播级别订单回滚时审计日志通过REQUIRES_NEW独立提交保留故障现场。核心 Bean AuditLogService.java 会把每条订单连同JMSRedelivered是否重投标志写入审计表是排障的黄金数据。UnitOfWork 工作单元没有事务时的补偿机制 ️并非所有组件都支持事务。Camel 的UnitOfWork工作单元是它的补偿方案chapter12/uow模块演示了三种关键能力同步回调Synchronization监听事务结束事件onCompletion 模式只在全部路由执行成功后才确认消息——失败则不确认消息会被重投而不是丢失BeforeConsumer 模式消费前就标记防止重复处理该模块还附有一个完整的 REST 订单服务OrderRoute.java可用curl -i http://localhost:8080/service/order/123体验返回头中生成的防重复 token。幂等性消费者防重复消息的终极手段 消息重投、负载均衡重试、网络抖动……重复消息是分布式系统的家常便饭。chapter12/idempotent用Idempotent Consumer幂等性消费者EIP优雅解决它。看 IdempotentTest.java 的路由设计from(seda:inbox) .idempotentConsumer(header(orderId), repo) .to(mock:order) .end();路由中用idempotentConsumer以orderId消息头作为唯一键配合仓库对象repo记录已处理的消息。测试一次性发送 5 条订单消息其中 2 条重复最终只有3 条唯一订单被处理——重复消息被自动过滤且断言保证了零重复。开箱即用的幂等仓库实现Camel 自带多种 IdempotentRepository 实现按需选择MemoryIdempotentRepository内存实现示例默认使用重启即失效InfinispanIdempotentRepository基于 Infinispan 缓存适合集群共享JCache / JPA标准化缓存或持久化到数据库重启后依然生效下图展示了 Infinispan 控制台中的缓存视图幂等键数据即存储于此快速上手三步跑通全部示例1️⃣ 克隆项目git clone https://gitcode.com/gh_mirrors/ca/camelinaction22️⃣ 进入第 12 章目录cd camelinaction2/chapter123️⃣ 按需运行各模块测试每个子模块都有独立 README.md 说明cd xa mvn test cd idempotent mvn test总结如何为你的场景选型✅你的场景推荐方案参考模块单资源仅数据库或仅队列本地事务tx-database队列 数据库强一致XA 全局事务xa部分步骤需保留审计场景事务传播 REQUIRES_NEWpropagation组件不支持事务UnitOfWork onCompletionuow消息可能重复投递幂等性消费者idempotent消息丢失排查客户端确认模式riderautoparts-partner一句话记忆XA 管一致性UnitOfWork 管补偿幂等性管不重复——三者组合就是生产级消息系统的可靠性基石。【免费下载链接】camelinaction2:camel: This project hosts the source code for the examples of the Camel in Action 2nd ed book :closed_book: written by Claus Ibsen and Jonathan Anstey.项目地址: https://gitcode.com/gh_mirrors/ca/camelinaction2创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
