大数据分布式事务的深入理解？

        在一个大数据系统内部分布式事务无处不在，但凡一个任务分布到多台机器上执行就会涉及到分布式事务的场景，分布式事务一直以来都是分布式系统比较难以解决的问题。

        事务的理解，比如你要将账户A转1块钱到账户B中，那么这个行为在执行时会被拆分成两个步骤，第一步是将A账户扣掉1块钱，第二步就是将B账户加上1块钱；但是这两个步骤的特点是：要么都执行成功，要么都执行失败，不能存在一个成功一个失败的情况。我们把这种多个步骤要么同时执行成功，要么同时执行失败，不允许出现中间状态的操作就叫做事务。

        本地事务的理解，拿上面的转账例子来说，如果刚好A账户和B账户在同一家银行的同一个数据库里，那么他就满足了一个本地事务的基本条件；也就是说我要执行这两个账户的加减操作只需要在一个程序中就能完成，而且这两个操作彼此之间的顺序和结果是可知的，那么我们在程序内部就可以很容易实现这个事务操作；

        但是如果A账户跟B账户分别在两家不同银行的不同数据库中就没有办法做到像刚才那样在同一个程序里同时去操作A账户和B账户了，我们只能先在A账户对应的银行进行第一步操作，然后再在B账户对应的银行里进行第二步操作，但还会有个问题需要注意那就是操作A账户跟操作B账户这两个操作彼此之间的结果和顺序是不可见的，而这就是分布式事务的场景；此时就只能找一个中间人来帮忙协调这个事情，而这个中间人就是银联，于是我们只需要把转账这个行为告诉银联，然后银联来具体负责向A银行账户扣钱再去B银行的账户加钱；但是这个过程其实相比于刚才的本地事务要复杂的多，因为涉及到了三方的沟通，银行A、银行B、银联，这里面一旦有某一环节处理不好就容易导致A、B账户金额的不一致；那么为了保证分布式事务的可靠性就出现了两阶段提交和三阶段提交的实现方案。

        两阶段提交就是把这个多方沟通协调的过程根据沟通顺序划分为两个阶段；提交就是把写在内存中的数据再次写入到磁盘中；回滚是把在内存中修改的数据进行撤销。A账户跨行向B账户转账，第一阶段为银联收到转账申请后先向A账户所在银行发起扣钱操作，A只执行不提交也就是只在内存中对金额进行扣减但是不写入到磁盘中然后把执行成功的消息告诉银联，接着银联再向B的所在的银行发起加钱操作也只是在内存中对账户金额进行增加并不写入磁盘，然后再把执行成功的消息也告诉银联，第一阶段也可称为投票阶段，如果A、B操作都成功则投票成功，否则为失败。然后是分布式事务的第二个阶段