关于分布式事务

在长期的学习中，突然发现对于很对技术学习中，如果忽略了技术产生的背景而直接进入技术的学习，到最后会突然惊醒我到底学了个啥。对于分布式事务，零零碎碎学了很多东西之后，才发现内容串不起来，导致的后果就是当出现问题的时候，不能从大脑中迅速构建出解决方案，因此借此特殊的机会，把分布式事务重新系统地总结一番。

什么是事务

就我个人的理解，事务就是我当前要做的一件事情，比如我要将网页提交给服务器的数据写到数据库，而只有当我成功写入数据库后，这个事情才算是结束了，也就是这个事务完成了。

事务的基本特性

• 原子性
• 一致性
• 隔离性
• 持久性

原子性

在微观科学某个发展阶段，认为原子是最小的粒子，无法再进行拆分由什么组成，因此原子性也就是表示这个事务是一个最小的单元，事务只有失败和成功两种可能性，不存在部分成功和部分失败。

虽然这个事务操作可能会分为几步，但是将这些所有操作都划分为一个事务。

一致性

理解一致性可以借助能量守恒定律——能量不会凭空消失或凭空出现，只会从一种状态转变为另一种状态。例如银行的转账，五路怎么转，转出方总金额+转入方总金额总是不变的，不可能存在转来转去之后，总金额变多了或者变少了。

隔离性

不同事务的执行是相互隔离的，比如张三转账给李四、李四转账给张三。这两个事务不受影响，而是转账完成后，张三的账户余额变动了两次，李四的账户也变动了两次，最终结果符合预期。

持久性

事务执行完毕后，数据就不会再变动了，不会出现转账完成之后，李四转出的的钱又退回了。如果在转账还未完成是钱退回，那一定是事务没执行成功。

这就是单机下的事务。随着使用系统的人数增多，系统无法快速完成用户的需求，因此产生了分布式。如电商系统将整个系统拆分为订单系统，支付系统，个人信息系统等，每个系统由自己的数据库进行数据管理。这时候上述的事务就不能管理所有系统的，因为不同数据库的事务是不具有互相感知能力的，这时引入分布式事务。

分布式事务

分布式事务用来保证多个系统之间的数据一致，如用户下单并支付后，库存系统的库存必定会产生扣减，否则库存系统就失效了。

既然单机事务是因为系统的无感知导致无法使用于分布式系统，那么解决分布式事务就必须解决这个无感知的问题。引入第三方协调者，将这几个系统集中起来，通过协调者让几个系统能够在事务上进行通信。此时各个系统的事务执行提交还是回滚完全由这个协调者来决定。

强一致性原则（X/OpenDTP事务模型）

我们将各个系统称为ResourceManager（简称RM），将协调者称为TransactionManager（简称TM）。TM负责管理事务，RM负责管理资源。当RM需要做事务性操作的时候，先到TM处注册事务，告知TM需要做事务管理。

TM必须等待所有RM都执行事务成功后，才会给RM下达提交的指令，结果所有RM都能成功写入数据。实际上这就是一个2PC（2阶段提交的方式）。例如Zookeeper中的Leader选举也是基于2PC来实现的，但是Zookeeper中并没有生搬硬套2PC，而是采用了Raft算法，只要过半执行投片投票就会做决策。目前可以用来作为TM的组间包含atomikos、seta等。

2PC虽然能解决事务的一致性问题，但是他本身也具一定的缺陷，如果在途中②③④的步骤中出现了网络问题或者TM宕机、RM宕机等导致提交事务的通知没有成功被RM接收，事务就会回滚。但是性能和安全从来都是权衡利弊后的取舍问题。即CAP/BASE理论。

CAP/BASE

CAP：
C：Consistency——强一致性
A：Avaliablity——可用性
P：Partition Rolerance——分区容错性

P是必须要保证的，当系统内部分应用出现故障，我们仍需保障系统的可用，而不是一个应用挂掉，整个系统都变得不可用。A和C就是根据场景进行取舍的两个方面。

BASE理论：
BA：Basically Available——类似于服务降级，当服务器压力大的时候，部分低优先级的应用可能会变为不可用，如双十一的时候个人中心无法使用等。或者当进行数据库分片的时候，某些节点宕机，只会影响该节点的数据，气气他节点依然可以进行正常运行。
S：Soft State——柔性状态，允许分布式系统中不同节点的数据有一定不一致，这个延迟的时间，系统可能在做数据同步，或者处于短暂的数据处理。
E：Eventual Consistency——保证数据最终是一致的，中间过程可能数据不一致，但是最终的结果符合预期，比如支付系统中，实际划账和提示支付成功并不是实时完成的，但是最终一定是执行成功的。

分布式事务的解决方案

最终一致性解决方案

放弃部分强一致性，保证最终一致性。采用消息队列来异步完成指定的操作，上述的支付系统中，部分业务就是采用这种方法来实现。

将支付请求发送到MQ（消息队列）后，消息队列配置一个消费者去完成银行划账，通过MQ完成解耦，支付任务能够快速返回，实际划账由消费者去完成，而且保证最终一定完成。保证最终完成的手段很多，比如消息重发，衰减重试，人工干预等，Dubbo的Failover就是一种重试，默认会重试两次。但是这些手段带来的幂等性问题需要合理解决。

幂等性：当重复调用划账请求，最终只能有一次执行成功。

幂等性实现

• 状态机
  

• token机制：将请求携带一个token，判断请求是否是重复的

• 数据库的唯一约束：利用数据库的唯一键

• Redis的setNX
  数据操作成功后会留下一个独一无二器不能重复设置的值，记录该条操作已经完成，后续的操作会先判断当前是否已经处理过，仅在操作没有处理过的时候才会进行处理。同时很多系统还会配备人工对账的保障措施。