去分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。为了实现分布式事务，需要使用下面将介绍的两阶段提交协议。

  阶段一：开始向事务涉及到的全部资源发送提交前信息。此时，事务涉及到的资源还有最后一次机会来异常结束事务。如果任意一个资源决定异常结束事务，则整个事务取消，不会进行资源的更新。否则，事务将正常执行，除非发生灾难性的失败。为了防止会发生灾难性的失败，所有资源的更新都会写入到日志中。这些日志是永久性的，因此，这些日志会幸免遇难并且在失败之后可以重新对所有资源进行更新。 

阶段二：只在阶段一没有异常结束的时候才会发生。此时，所有能被定位和单独控制的资源管理器都将开始执行真正的数据更新。

    在分布式事务两阶段提交协议中，有一个主事务管理器负责充当分布式事务协调器的角色。事务协调器负责整个事务并使之与网络中的其他事务管理器协同工作。

  事实上，有所得必有所失，分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。

1、可用性下降：从上面的二阶段提交协议可以看出，只有在参与分布式事务的各个数据库实例都能够正常工作的前提下，分布式事务才能够顺利完成，只要有一个工作不正常，整个事务就不能完成。这样，系统的可用性就相当于参加分布式事务的各实例的可用性之积，实例越多，可用性下降越明显。

2、性能和可伸缩性：首先是事务的总持续时间通常是各实例操作时间之和，因为一个事务中的各个操作通常是顺序执行的，这样事务的响应时间就会增加很多；其次是一般Web应用的事务都不大，单机操作时间也就几毫秒甚至不到1毫秒，一但涉及到分布式事务，提交时节点间的网络通信往返过程也为毫秒级别，对事务响应时间的影响也不可忽视。由于事务持续时间延长，事务对相关资源的锁定时间也相应增加，从而可能严重增加了并发冲突，影响到系统吞吐率和可伸缩性。

    在高并发的系统中使用分布式事务显然会遇到性能瓶颈，比如一个秒杀系统，分布式事物的使用无疑将大大降低系统的反应速度。为了解决这个问题，我们引入最终一致性（Eventually Consistent），即容许一段时间的不一致，不一致的时间窗口根据不同业务确定。

    分布式系统中，去除分布式事务的一个显而易见的方法是通过某种方式去异步的执行各个节点的操作，最终保证各个节点的一致性。这里介绍一种使用操作队列和消息状态来取代分布式事物的方案。

    首先我们假设有A、B两个分布式节点，我们需要操作完A的基础上去操作B，两个操作本来是要分布式事务保证的，但是我们允许A、B存在短时间的不一致性。

 

    我们在A节点加一个操作队列，存储对B节点的操作；在B节点增加一个结果表，存储操作运行的结果。如下图

 

 

    操作完A节点后，将操作B节点的操作加入到操作队列中即可完成本次调用，由于没有去操作分布式的B节点，响应速度提高很多。操作队列和A节点存储同一个节点，可以通过本地事务的方法保证操作的原子性。之后由另外的线程去从操作队列中取出操作，然后检查B节点的结果表判断操作是否已经成功，没有成功则去执行操作，更新B节点数据，同时根据执行情况在结果表中写入结果，如果结果是成功，需要返回A节点删除操作队列中对应的操作。由于写入结果和删除操作属于分布式操作，我们不使用事务，不保证操作一定成功，即使删除操作失败了也没关系，下次操作来了，判断结果已经成功就不会再执行操作，而是直接返回A删除操作，因此对B节点数据不会进行重复操作。

      虽然由于没有分布式事务的强一致性保证，使用上述方案在系统将短时间内处于不一致状态。但基于操作队列和消息表，最终可以将系统恢复到一致。