分布式事务

事务

数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。

思考一个问题？为什么要引入事务，事务帮助我们解决了什么问题？

事务的产生，其实是为了当应用程序访问数据库的时候，事务能够简化我们的编程模型，不需要我们去考虑各种各样的潜在错误和并发问题。可以想一下当我们使用事务时，要么提交，要么回滚，我们不会去考虑网络异常了，服务器宕机了，同时更改一个数据怎么办对吧?因此事务本质上是为了应用层服务的，而不是伴随着数据库系统天生就有的。

事务的ACID属性

原子性：记录之前的版本，允许回滚
一致性：事务开始和结束之间的中间状态不会被其他事务看到
隔离性：适当的破坏一致性来提升性能与并行度 例如：最终一致~=读未提交。
持久性：每一次的事务提交后就会保证不会丢失

分布式事务

分布式事务是基于分布式系统环境的，即不再是单体数据库，而是涉及到多个数据库实例。

CAP定律

在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

BASE理论

BA：Basic Available 基本可用
整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是：“一定时间”可以适当延长。当举行大促时，响应时间可以适当延长，给部分用户返回一个降级页面
给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
S：Soft State：柔性状态
同一数据的不同副本的状态，可以不需要实时一致。
E：Eventual Consisstency：最终一致性
同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。

分布式事务的解决方案

分布式事务的解决方案有如下几种：
全局消息
基于可靠消息服务的分布式事务
TCC
最大努力通知
下一篇文章会详细介绍这些解决方案

相关文章：http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
https://docs.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://zhuanlan.zhihu.com/p/25933039
https://www.zhihu.com/question/31346392
https://www.zhihu.com/question/31346392/answer/362597203
https://juejin.im/post/5aa3c7736fb9a028bb189bca