事务对性能影响_不是事务的事务！（分布式事务系列-完结篇）

虽然我们都把最大努力通知型作为分布式事务的一种，但是各位同学心里要明白，这个完完全全和事务没有任何关系，为了确保我们这个分布式事务系列的完整性，我有必要用这篇最大努力通知型来做整个系列的收尾。

到现在，我们已经知道了TCC 和 最终一致性事务是怎么玩儿的，那么作为一个成为架构师的你，一定要学会思考思考思考，当进行功能或系统设计的时候，通过彻底的需求分析，将技术和需求进行完美结合，才是我们架构师做的事情。

适用的场景

究竟一个系统中，哪里用“强”事务的TCC，哪里需要用“弱”事务的可靠消息最终一致性，我们都要做到心里有数，经过仔细的系统分析后，我们可以找出来一些需要相对可靠但不影响系统整体的事务需求，最大努力通知型事务就是用来解决此类需求的。为什么一定要分析出各种适用的事务呢？因为我们要在尽可能满足业务需求和场景的情况下，提高系统性能啊！大家记住，越强的事务，性能损耗越大，很可能一个能承受百万并发的系统，因为加了TCC而降到1w并发甚至更低。

比如：通知型短信发送，当你用TCC保证了给手机号充值的资金转账，用可靠消息最终一致性保证了积分在一定时间内加到账户上后，最后一步是要通过短信通知你“充值成功啦”，

这最后一步，我们就可以用最大努力通知型事务来尽最大努力保证这个通知消息能发给你，并不能保证这个通知短信一定会发送成功，但是，这并不影响我们整个系统。

方案分析

大家明白我们的用心良苦后，我们就来分析一下这种类型的事务，没有源码分析，也是和可靠消息一样都是属于解决方案型。

上游服务A在没有事务保障的情况下，想要尽可能成功调用下游，就可以通过我们设计的最大努力通知方案来解决，最大努力通知的关键组件有两个

• MQ
• 重试组件(定时器)

MQ是为了让我们的上下游服务解耦，上游服务发到MQ后就结束了，这不就提高性能了吗？

重试组件就是我们的“事务”保障，它可以替上游服务完成下游服务的调用，并且在失败后会一直重试，直到调用下游成功，或者我们主动放弃。

最大努力通知事务服务需要自己定义好协议，也就是消息格式，大家可以参考本文的格式做一些适用于自己企业的调整。

1. 消息内容：上游发送给下游服务的上下文
2. 最大重试次数：调用下游多少次后，放弃调用
3. 最后重试时间：定时器的重试机制需要参考这个时间进行有规律的重试
4. 重试方案：预留，暂时没用。
5. 重试间隔：比如 1秒，3秒，5秒，10秒，30秒，1分钟，3分钟，10分钟...自己根据业务来设计间隔规律
6. 重试次数：重试机制需要根据此值来进行重试调用
7. 状态：

• 未处理(还没调用下游)
• 成功(调用下游服务成功，定时清理即可)
• 失败(调用下游失败)
• Dead(超过重试次数后依然失败，这个状态根据具体业务情况来进行处理，有的业务可以直接将Dead删除，有的需要将Dead单独通过手工处理)

相信之前自己研究可靠消息最终一致性的同学，学习最大努力通知型事务易如反掌。

结语：

至此，咱们的分布式系列全部完成，想必各位同学对分布式事务应该有一个比较全面的了解了，今后大家在系统设计的时候，遇到涉及分布式事务问题，就可以从多个角度进行系统性的分析，什么情况用什么事务，什么事务合理，把咱们学到的整块分布式事务技术全部综合运用的实际的case上，这才能成为大家自己的能力。