事务对性能影响_保证数据一致性同时还能提高性能吗？（分布式事务系列-4）...

之前我们研究了TCC型事务，它确实能保证我们分布式环境下的数据一致性，但是放眼整个系统架构有没有发现，TCC最终会成为性能瓶颈，因为对于高并发的系统来说，他的处理速度太慢了，先看看我们用TCC事务的流程：首先我们需要创建一个事务发起者，然后带着事务上下文分别去请求其他多个远程服务，接着等他们全部都处理完后给我们响应成功失败，然后发起者再去执行本地和多个远程服务的confirm或cancel方法。

在整个流程中我们发现影响性能的环节包括但不限于，1、两次同时请求多个远程服务；2、同步等待远程响应。严重影响了系统性能，我们能否设计一种解决方案，即保证数据一致性又能提高性能？

可靠消息最终一致性方案

上面我们也提到了，这是一种“方案”而不是“技术”，也就是说，我们通过架构设计手段来解决事务问题，但是(重点来了)，这个方案并不适用于所有业务场景，所以通常情况下，一个分布式系统中的事务既有TCC又包含可靠消息最终一致性方案，结合这两者，我们才能鱼和熊掌同时兼得，降低分布式事务给系统带来负面的性能影响。

分析

大家不要紧张，这次我们就不给大家研究干巴巴的源码了，因为也没有源码可研究，这次分析的是这套解决方案应该怎么玩儿呢？

首先先说这套方案适用的条件，一般情况下，可靠消息最终一致性方案可以在“不太强”的事务场景中，也就是说系统中的一些数据可以*晚一点*修改或者增加。

关键词：“不太强”，“晚一点”

具体的场景

消费送积分这个事情，超市买100元洗发水送100积分，那这个100积分一般来说没有必要用TCC事务同步给用户增加，事务需求“不太强”，我们可以“晚一点”给用户加上，这样不会影响用户体验。

这个场景下，我们就用可靠消息最终一致性方案来完美解决，也就是不用TCC我们也肯定能给用户增加100积分。那究竟怎么做呢？老规矩先看图。

针对我们上面的场景，图中的三个关键对象是

• 上游服务A：消费系统
• 可靠消息服务
• 下游服务B：积分服务

两条路线进行分析

第一条、正常情况关键的流程步骤

1. 我们消费系统(上游服务)先请求远程可靠消息服务创建一个pre消息，消息内容是给张三增加100积分，消息状态为待发送，看好了，此时这个消息还没有发送给积分服务哦！！注意。
2. ***创建成功后***消费系统账户增加100元执行本地事务，保存到数据库。
3. 通知可靠消息服务，刚才那条消息可以发送了。
4. 可靠消息服务将消息发送至积分服务(下游)。
5. 积分服务收到消息，为张三增加100积分。

走完这些步骤，我们的消费系统肯定增加了100元，积分系统肯定增加了100积分。在关键的流程步骤中，第1、2条尤为重要，一定是第1条成功后才执行第2条。这一步的目的是为了保证我们的pre消息一定是在可靠消息服务中创建成功了。之后我们才能执行消费系统本地增加金额的事务操作。这里的事务都是本地的，没有分布式。

事情往往是不如意的，尤其是在分布式系统中，网络随随便便抖动一下，我们的上下游服务衔接就会出现问题，我们需要一套异常处理机制来保证整个链路是可靠的。

第二条、异常情况关键的流程步骤

• 异常1：:我们的第1步创建pre消息失败了，那此时我们直接就报异常说消费系统失败，请重试，没破坏事务一致性
• 异常2：第2步增加100元本地事务失败，进行rollback，那此时我们直接就报异常说消费系统失败，请重试，没破坏事务一致性，但是我们远程的消息服务已经保存了一条待发送的消息，这个就靠那个定时器去做清理了。
• 异常3：通知可靠消息服务将pre消息发送，失败了，此时消费系统以及增加了100元怎么办？别慌同学，我们依然靠定时器去做处理，定时器扫描发现待发送的消息一直没有收到消费系统的确认，他会主动拿这条消息请求消费系统问问人家那个100块增加成功了没有，如果消费系统返回说增加成功了，那么定时器就将消息状态改为发送中，否则就删除消息。
• 异常4：可靠消息服务发送至积分服务的时候，失败了，此时靠另一个定时器去处理，没别的，就是可劲儿往下游积分服务不断重发消息，直到积分服务本地事务100积分成功，然后调用可靠消息的接口说，大哥，你别发了，我已经收到了。

至此，我们的可靠消息方案就搞定了，就是这么diao。

结语

我们通过一个消息服务+两个定时器，解决了分布式系统中上下游服务事务一致性的问题的同时提高了系统性能，两个服务完全解耦，整个事务流程异步执行。

目前市面上有也有很多本身支持事务消息的MQ，比如Rocket MQ ， Rabbit MQ ， Kafka MQ ，各位同学也可以将我们可靠消息架构中的消息服务替换为以上这些MQ来设计自己的架构，方案各有利弊，我们需要找到适合自身业务的方案来解决实际问题。