爱威尔-分布式事务漫谈

分布式事务这个问题对于分布式系统来说是一个绕不开的话题。互联网大型系统的发展在过去几年里由世界上那么几个巨头才玩得起，在现在变成了人人都需要，公司用户上百万，数据有五六十个G，不再去做主从单一的系统架构恐怕是撑不了多久，我们也不说数据几百G甚至上T级，数据库有五十G的数据你就着急了。国内的公司虽然不是每个都是大公司，但是做得好的几年下来数据就可以有这样的规模，有的项目一开始就知道未来的市场。 
   
 回到我们的话题，然而在分布式事务这方面可以说是：封闭的封闭，变通的变通，理论的理论，关系型数据库没有一个玩起来的，开源的就更不用提了。一提到分布式事务那都是头疼的事，想想怎么规避，怎么妥协，现在市面上的技术比如可靠消息，最大努力，tcc，两阶段提交等等，技术实现都不简单，现状就是如此，哦对了值得一提的是tidb，有人说这个分布式数据库要火，我也安装试了一下，还没有深入测试，据说已经由公司在用，如果完善好他解决的可不是单单分布式事务这一个问题，我们现在还在做分库分表，还需要中间件支持，这其中的复杂情况也好不到哪里去。 
   
 之所以提tidb因为他封装了太多我们头疼的问题，而交给我们的就像操作一个数据库一样，我们现在在数据库层所做的努力都不存在了，好了不说他了，我们还是回到让人头疼的各种妥协的努力上面来。先说可靠消息最终一致，可靠消息最终一致这个方案用途广但是通用性差，想做出来一个产品用基本不可能，业务关联性太强，灵活性也很大，实现方法也很多。它的一大特点就是由可靠的持久化消息然后通过幂等查询来实现最终数据完整，还要有定时任务加入，定时任务基本就是校验数据的，来判断数据是否完整，一旦判断数据完整那持久化消息也就没用的，是删除是保留那就看需求了。 
  <img src="80/20170210093733_507.png" alt=""> 
 这个东西还不好描述，但是基本原则就是查询，判断，处理，查询，判断，处理来回循环直到判断是完整的数据结束，结束的标志可以是持久化消息被删除或者标记结束，总之就是之前说的定时任务不断地去巡查就行了。 
   
 最大努力通知也可以用定时任务也可以不用定时任务，这个不能保证数据完整性但是也做了一定的付出，说实话对于一个相对完整的项目来说基本也可以做到对分布式事务的处理，所以他的用途也就被限制了，对于要求不太高的可以使用，也是最容易实现的方案。 
   
 关于TCC的分布式事务实现概念我就不说了（<a href="https://github.com/changmingxie/tcc-transaction">https://github.com/changmingxie/tcc-transaction</a>） 
 记住tcc也是需要持久化的，我还没有深入研究，所以不敢妄下结论。但是它可以做成通用的东西就这点来说还是很不错的，性能方面也是有很多办法的，有时候总是感觉时间太少可回头想想其实不是那么回事。就目前的成熟架构来说分布式事务还是相对比较头疼的一件事情，我上面提到的tidb是非常有前景的，我想将来只要是分布式数据库都会自带事务这块功能，说实话这个也只有google能做出来这事情（哈哈哈）