介绍Rabbitmg用于解决分布式事务必须掌握的5个核心概念
一款分布式消息中间件,基于erlang语言开发, 具备语言级别的高并发处理能力。和Spring框架是同一家公司。 支持持久化、高可用
分布式事务是一个业务问题,不能脱离具体的场景。
● 基于数据库XA/ JTA协议的方式 需要数据库厂商支持; JAVA组件有atomikos等 ● 异步校对数据的方式 支付宝、微信支付主动查询支付状态、对账单的形式; ● 基于可靠消息(MQ)的解决方案 异步场景;通用性较强;拓展性较高 ● TCC编程式解决方案 严选、阿里、蚂蚁金服自己封装的DTX
本文目标:针对所有人群,学会基于可靠消息来解决分布式事务问题。 分布式事务的解决方案,业务针对性很强,重要的是思路,而不是照搬
误以为这样的接口调用写法,就不会有分布式事务问题
上述两种情况,都会导致数据不一致的问题
通过MQ解决分布式事务的5个步骤, 以及分布式事务处理中要注意的地方
外卖下订单后,可以慢慢等待运单中心数据生成,并非强制要求同时性
最终使多方数据达到一致。
➢ 为了确保数据一定成功发送到MQ。 ➢ 在同一事务中,增加一个记录表的操作, 记录每一条发往MQ的数据以及它的发送状态
于是我们在订单系统中增加一个本地信息表
于是在代码实践中,不再通过HTTP接口调用运单系统接口,而是使用MQ
生成订单时,也保存本地信息表
-确保在SB中开启Confirm机制
兜底方案:定时检查消息表,超时没发送成功,再次重发
于是需要以下特性:
➢ 幂等性 防止重复消息数据的处理,一次用户操作,只对应一次数据处理
➢ 开启手动ACK模式
由消费者控制消息的重发/清除/丢弃
消费者处理失败,需要MQ再次重发给消费者。 出现异常一般会重试几次,由消费者自身记录重试次数,并进行次数控制(不会永远重试!)
消费者处理失败,直接丢弃或者转移到死信队列(DLQ) 重试次数过多、消息内容格式错误等情况,通过线上预警机制通知运维人员
口优点
口缺点
尽量避免分布式事务; 尽量将非核心事务做成异步;
CAP理论 BASE理论 2PC协议 3PC协议 Paxos算法. Raft一致性协议
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。