分布式事务梳理
分布式事务目前流行的方案也有很多种，网上能找到大把的技术文章，但看人家的文章总是有各种问题，要么某些地方不好理解，要么某些地方认为不正确，还是按自己的视角来梳理一下。 目前看到的方案，2PC，3PC，TCC，事务消息，本地消息表，等等。 一，2PC 多个数据库在同一个公司，同一个网段可访问到，以及数据库支持2PC，先对多个要提交的事务先发起预提交，多个库确认可以commit了之后，再发起确认commit，当然这个方案存在一些问题，前面说的前提是一些场景上的限制，场景适用后，在发起commit阶段仍然会有可能有不一致的可能性存在，后面会有3PC，同样也是解决了部分问题，无法最终解决一致性问题。 二，3PC 3PC是在2PC的基础之上，在commit又分成了2步，进一步减少数据不一致的可能性。 三，TCC 其实TCC和2PC原理基本一样，只是TCC是不同的资源可能在不同公司，采用不同的服务的方式，多个服务需要支持一个完整的事务，这时候2PC就不适用了，TCC相当于把每个需要事务控制的服务提供确认和取消的操作，这样，在发起事务前先预先锁住资源，待所有资源都确认可以获得，再发起确认操作，中间如有某一个资源预先获取失败，则会取消其它的资源的持有。 在一篇文章又看到解释TCC又分几种类型，通用型，补偿型，异步确保型。通用型也就是刚刚说到的这种，补偿型稍微有点不一样，只提供提交和撤回操作，异步确保型则引入MQ。 对于TCC方案，后面的确认环节同样存在一定的问题，会有不一致的可能性存在，这时候就需要一些超时机制，check机制来尽可能的自动确保事务的一致性，这些机制几乎能解决因网络抖动，服务暂时不可用或者down机后快速恢复等情况引发的问题，对于一些更严重的故障，甚至比如程序出了bug，无法恢复的情况，最终也只能引入人工来修复。 四，事务消息 刚才有提到引入MQ，对于发MQ和本地的操作如何能够保证一致性呢，这个就引出了事务消息的概念，普通的MQ无法保证消息发成功和本地的业务的完全一致性，为了这个目标，在MQ系统中引用2PC的方案，先提交一次消息，然后执行业务，完成之后再次提交一次确认消息，对于没有收到确认的消息，定时轮询回查业务方，或者定期删除。 五，事务消息-本地消息表 有文章提到ebay的一个实现方案，本地消息表来保证本地事...