分布式数据库中的单事物

一般我们使用数据库时，为了保证整体数据的一致性，会通过事物来包装处理，即通过数据库本身的功能保证了一致性。但是当单机数据库的存储和性能无法满足时，大多会通过扩机器组成分布式数据库的方式来解决，那么问题了，多个数据库上的数据如何保持一致性呢，比如一个请求可能会同时写两个库，其中一个数据库的事物提交成功，另一个库提交失败，此时就出现了不一致的问题。为了解决这个问题，市场上已经有了很多分布式事务中间件，这是一种数据库层面的解决方案，今天我们通过业务上的处理来达成分布式数据库间的一致性。
    金融业务对数据一致性要求非常高，我们就以金融场景为例
    
    一个用户（001）向另一个用户（002）转账1块钱，交易单据为BILL1000。
   这里出现了三个主体：两个用户、一个交易单据，总结一下就是两类主体：**用户**、**业务单据**，其他所有数据都是这两类主体的扩展数据，操作数据库：

  
    现在为了支持更多的存储、更高的性能，使用了10个单机数据库（DB00、DB01、...DB009）,所有数据根据所属主体字段值的个位数HASH至某个单库:

    因为是三个单库，必然存在3个数据库事物，在事物提交阶段极可能出现部分事物提交成功、部分事物提交失败的情况，这就发生了数据不一致的情况。
    常用的一种事物间一致性保证方案是：TCC

•  T: Try，尝试处理，锁定相关资源，业务检测失败或锁定资源失败时可返回错误
•  C：Confirm，确认操作，正式执行资源的消耗，必须成功
•  C：Cancel，取消操作，解锁在T阶段锁定的资源

    具体到当前的金融场景就是，以交易单据数据所在事物作为主事物，其他用户类事物作为子事物：

    但是会有两种特殊情况
 - 子事物已经Try成功，交易事物提交失败了
 - 交易事物提交成功，子事物Confirm失败了
这两种情况就要通过补单来处理了，保证最终事物的一致性

转载于:https://www.cnblogs.com/tianrks/p/10519782.html