分布式系统：分布式事务实现

CAP

CAP定理指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。这三个要素最多只能同时实现两点，不可能三者兼顾

1. 一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
2. 用户访问服务器上面的数据，响应时间在可以接受的范围内。
3. 分区容错性：其实就是高可用性，一个节点崩了，并不影响我们其它的节点

为什么只有CP和AP，不能ACP？

出现网络分区时,P：分区容错性，当系统原本设计为CA时，只能说假定不会出现网络分区的情况，可用实现CA。但是网络分区是种错误，无论你怎么设计都有可能出现网络分区问题，这时你还是必须在选择是CP或者CA

分布式事务常见的三种解决思路

• 两阶段提交（2PC）

• 补偿事务（TCC）

• MQ 事务消息提交

问题探讨

两阶段提交（2PC）核心思想

上述图片是2PC第一阶段，直接修改信息，之后如果player两个修改成功。直接提交事务

利用本地事务，对此次事务保持悲观想法，认为该次事务有可能失败，先进行事务操作，不进行事务提交。在收到事务服务器在进行提交

两阶段提交（2PC）1阶段

事务发起者向各个服务发出询问请求，各个服务执行事务操作但不提交事务，等待协调者最终命令。

二阶段提交（2PC） 2阶段

事务发起者收到各个服务器命令commit/abort执行提交事务或者放弃事务。

二阶段的提交存在问题

player每次发起事务，由于不知道服务器当前状况，每次都工会服务器等待提交事务，玩家服务器超时

二阶段的提交存在问题

1. 同步阻塞：每个服务都需要等待其他服务信号都处于阻塞状态，无法进行其它操作
2. 单点问题：如果处于第二阶段发生网络波动，所有服务就GG，一直阻塞(加入超时)
3. 加入超时还可能发生的事情：数据不一致如果一些服务commit了另外一些服务超时回滚了 GG这里发生了数据不一致，事务没起到作用

2PC优化3PC

特点：每次需要提交事务前，先询问服务器在不在线，之后在进行事务操作。在提交事务时加入超时机制

这能避免大部分服务器死机，网络波阻塞问题及网络问题。这不是最优解，但是比较通用。可以避免90%的问题网络问题。在极端情况下
还是会发生数据不一致问题

3PC的问题

补偿事务（TCC）

TCC核心思想 是：不依赖于本地事务,针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作在代码应用层解决。

TCC的优点及缺点

• 对于逻辑可控，将不稳定因素在应用层解决，做好了应付代码发生错误问题的。相对来说 逻辑毕竟简单
• 缺点：缺点也较为明显，针对各种情况去做补偿操作，使得数据达到一致性的目的，导致需要很多代码
  委会很少发生的事情

引入MQ事务实现

RocetMQ实现事务

RocketMQ 4.3发布，支持分布式事务RocketMQ采用了2PC的方案来提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息

正常执行 1->2->4->6/7
发生网络波动时：1-> 2 -> 5 -> 6/7
半消息：准备好的消息，发生给server，对消费者不可见

生产者收到 半消息成功，返回commit或者 rollback，如果这时发生网络问题，MqServer会回查
MqProducer，得到消息状态。之后选择comit或者rollback.所有这里MQ Producer得实现监听接口

RocketMq Example

上图 RocketMq，将生产者监加入生产者。这里让我们看下监听

执行本地事务之后会将对应的id的事务设置为对应的状态，这里通过对应的状态，检查时返回对应的值

RocketMq订阅

1. MqServer，收到commit之后，会将之前的事务对消费者可见，消费者订阅对应的Topic。进行消费实现事务
2. RockeMq:保证每个消费者至少消费一次 ，采用的时先消费，消费成功后在提交。（重复消费问题）
   消费成功后，如果这时服务器异常重启，如果没有提交会产生重复消费问题。这个问题需要
   在业务方解决