分布式事务消息如何保证一致性？对比主流方案优缺点

付钱时钱被扣，可是迟迟未能到帐，这般令人心烦之事的背后，是分布式系统怎样确保数据最终达成一致的复杂技术难题，。

分布式事务的基本难题

在由多个独立服务所构成的系统当中，类似银行转账这般的操作，需要同时去更新两个不一样数据库里的数据。有一个服务专门负责从用户A的账户进行扣款，还有另一个服务专门负责向用户B的账户加以加款。使其确保这两个操作要么全都成功，要么全都失败，这是核心的难题所在。要是只成功了一半，比如说钱已经被扣除了但是却并未到账，这样就会引发用户去投诉以及资金出现错乱的情况。传统的单数据库事务在这个地方失效了，原因是操作涉及跨越了不同的网络服务以及数据存储节点。

两阶段提交协议的尝试

早先有一种解决办法是引进两阶段提交协议，，它引入了一个协调者角色，在第一阶段向所有参与者（像是扣款服务以及加款服务）询问可不可以提交，在收到全部是同意的情况后，在第二阶段才正式地提交所有操作这种机制能够提供强一致性，不过存在明显的缺陷，整个流程是同步阻塞的，一旦有参与者响应慢或者出现网络延迟，所有相关资源全都会被锁定，致使系统吞吐量急剧地下降，在高并发场景下几乎是不可用的。

最终一致性的现实选择

牺牲强一致性、保证最终一致性是为满足互联网应用对高可用要求的主流选择，系统不会要求多个数据副本在事务完成瞬间马上一致，而是承诺经一段时间异步同步后，数据会达到一致状态，只要这段时间在用户可接受范围内（像转账在2分钟内到账），业务便可正常运行，这本质是以短暂的数据延迟，获取系统整体处理能力与可用性的显著提升。

本地消息表的补偿机制

实现最终一致性的常见模式里有一种是本地消息表，就拿论坛登录奖励积分来说 ，用户服务跟积分服务二者是分离的 。待用户登录成功之后 ，在本地事务之中去完成用户状态更新 ，并且与此同时还要把带有“发放积分”内容的消息插入到一张专用的数据表里边 。接着 ，一个单独存在的进程会用异步方式读取那张表格 ，且调用积分服务实行加积分操作 。要是调用出现失败情况 ，进程会依照策略进行重试 ，直至成功才停止 。这种做法把分布式事务拆分成可靠的本地操作以及异步重试 。

基于可靠消息队列的解耦

又有一种被广泛运用的模式，它依赖于支持事务的消息队列，就像RocketMQ那样。业务服务在做完本地操作，如同进行扣款操作之后，会朝着消息队列发送一条事务消息。消息队列会跟发送方去确认本地操作是不是真的完成了，然后才决定把消息投递给消费方，比如加款服务。要是消息投递失败了，队列就会进行重试。借助这种方式，把服务间的直接调用解耦成了通过消息中介的间接协作，进而提升了系统的鲁棒性以及可扩展性。

设计与监控的注意事项

无论选用哪一种方案，完善的设计以及监控绝对是不可缺少的。业务代码当中要记录详尽的操作日志，从而方便在出现数据不一致的状况时去进行核对以及人工修复。针对关键业务，还需要设置监控告警，当重试次数出现异常或者延迟过长的时候能够及时通知开发人员。同时，一定要认识到不存在任何一种方案能够完美应对所有场景，技术选型得结合业务对于一致性、性能以及复杂度的实际要求来进行权衡。

构建高可用分布式系统之际，你是更偏向于借助牺牲强一致性去交换性能呢，还是觉得于某些核心业务里非得不惜一切代价确保数据实时准确呢？