一个分布式事务解决方案

分布式系统中,只要涉及到跨服务调用并且服务各自用自己的数据源,就会存在数据不一致问题.通常来说要保证强一致性代价太大，绝大部分场景也不需要，根据BASE理论，我们保证最终一致性就好了，下面设计的方案就是一个保证最终一致性的方案.

架构及原理

 

实现最终一致性本质上是通过重试确保的，因此业务一定要保证逻辑幂等性，之所以选择 redis 和 mq 是出于性能考虑。

正常通知

A1->A2->A3->B1->C2->C4->B2->D1->D2

总的讲是确保你能通知到对方,对方处理成功后将消息删除才算完成整个事务.其中任何一个环节出问题都有办法保证你的数据一致性.

正常通知并回调

A1->A2->A3->B1->C2->C4->B2->D1->D3->B3->C3->C6->B4->A4

总的讲是确保你能通知到对方,对方处理成功后发送回调消息,再确保回调消息你能收到,你收到处理成功后将消息删除才算完成整个事务.其中任何一个环节出问题都有办法保证你的数据一致性.

预发送失败

如果预发送失败,直接抛运行时异常,本地事务不会被执行.

本地事务执行异常

如果预发送成功,但本地事务执行异常,则直接删除预发送的信息.

网络或服务异常导致"确认超时“

可靠消息服务会定时去redis查询,发现”超时确认”的消息就会向mq发送”查询消息“,mq推送给调用方处理,如果调用方告知本地事务为被执行则删除redis中的这条消息,如果告知已经执行成功则发送确认消息.

网络或服务异常导致“处理超时”

可靠消息服务会定时去redis查询,发现”超时处理”的消息就会再次向mq发送”请求消息“,mq推送给被调方处理.

网络或服务异常导致“回调超时”

可靠消息服务会定时去redis查询,发现”超时处理”的消息就会再次向mq发送”请求消息“,mq推送给被调方处理.

“确认超时”或“处理超时”或“回调超时”重试次数达到限制

如果“确认超时”或“处理超时”或“回调超时”重试次数达到限制,“可靠消息服务”会触发告警,另外通过后台管理界面可以查询到并且可以执行重发等操作.