前面我们讲了分布式事务的2PC、3PC , TCC 的原理。这些事务其实都在尽力的模拟数据库的事务，我们可以简单的认为他们是一个同步行的事务。特别是 2PC,3PC 他们完全利用数据库的事务能力，在一阶段开始事务后不进提交会严重影响应用程序的并发性能。TCC 一阶段虽然不会阻塞数据库，但是它同样是 ...

最终一致性，从其名字看，已经放弃了强一致性，如果出现异常情况，很有可能会产生主业务已提交，边缘业务最终也没能一致的情况。如网络持续不通，一段时间重试后，任务不得不放弃 因此最终一致性还有一层隐含信息->做好最终不一致的备案，否则可能造成不可预期的问题。 目前做法 和事务型数据库一同提交 ...

在分布式时代，分库分表是很常见的，微服务系统中，各个系统通常使用独立的数据库，所以，事务很难靠数据库本身保证，只能靠业务系统来解决。 例如支付宝中的余额宝、花呗，具体不清楚，但猜测应该就是2个服务，不是同一个数据库，我们还花呗的时候通常都是从余额宝中扣除的，这就是分布式事务，一个系统中扣减钱 ...

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下 ...

中文说明文章,该地址如下:地址,文章由浅入深的讲述了分布式事务在微服务场景下的重要性,以及Saga对分布 ...

一、强一致性事务的瓶颈 　　在《分布式强一致性事务》一文中介绍了分布式事务的常用协议2PC二阶段提交，虽然2PC能在很大程度上实现分布式事务中各节点的ACID，但也存在同步阻塞问题，协调者单点故障，协调者因网络原因导致的通知不周或收不全参与者回复导致的异常等问题。 　　同时，即使能稳定的使用 ...

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构 ...

前言 对于分布式事务，常用的解决方案根据一致性的程度可以进行如下划分： 强一致性(2PC、3PC)：数据库层面的实现，通过锁定资源，牺牲可用性，保证数据的强一致性，效率相对比较低。 弱一致性(TCC)：业务层面的实现，通过预留或锁定部分资源，最后通过确认或取消操作完成事务的处理 ...