【分布式事务】互联网分布式事务解决方案

1. 什么是分布式事务？

一次操作会分布到不同的服务器上的不同应用，例如用户购买商品，会涉及到商品系统，订单系统，此时要保证商品较少，同时把这些商品添加到订单服务系统中，这两部操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2.分布式事务产生的原因:

2.1数据库分库分表
随着业务数据量的增加，需要把以前的一个库的数据分成两个库或者把一个表的数据分成两个表，如果一个操作既需要操作01库，又需要操作02库，需要保证数据的一致性，就需要用到分布式事务

2.2应用SOA化
随着系统业务的增多，项目进行服务化，把一个项目拆分成不同的服务。例如用户购买商品，会涉及到商品系统，订单系统，此时要保证商品较少，同时把这些商品添加到订单服务系统中，这两部操作要么全部成功，要么全部失败，这时就需要保证数据的一致性。

3.事务的ACID特性

事务要求：ACID
原子性：要么全部成功，要么全部失败
一致性：事务完成时，必须使所有的数据都保持一致
隔离性（通过锁实现）：并发事务所作的修改必须和其他事务所作的修改是隔离的
持久性：事务完成之后，对系统的影响是永久的

4.分布式系统的特性

我们肯定都听过“CAP理论”，指的是分布式系统的一致性，可用性，和分区容错性。
C(Consistency):在分布式系统中的所有数据备份，在同一时刻是否同样的值
A( Availability):在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求
P(Partition tolerance):系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡
在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可.

5.常见的分布式事务解决方案

5.1 2PC

2pc是非常经典的强一致性、中心化的原子提交协议。中心化是指协议中有两类节点：一个中心化协调者节点（coordinator）和N个参与者节点（participant、cohort）

二阶段提交协议主要分为来个阶段：准备阶段和提交阶段。

第一个阶段：首先协调者会询问参与者是否能执行事务提交操作。如果两个参与者能够执行事务的提交，先执行事务操作，然后返回YES，如果没有成功执行事务操作，就返回NO。

第二个阶段：当协调者接收到所有的参与者的反馈之后，开始进入事务提交阶段。如果所有参与者都返回YES，那就发送COMMIT请求，如果有一个人返回NO，那就返送roolback请求。

5.2 3PC

三阶段提交协议（3pc Three-phase_commit_protocol）主要是为了解决两阶段提交协议的阻塞问题，从原来的两个阶段扩展为三个阶段，并且增加了超时机制。

3PC只是解决了在异常情况下2PC的阻塞问题，但导致一次提交要传递6条消息，延时很大

5.3 TCC

其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。

5.4 eBay模式消息最终一致性

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

感谢您的阅读~