干劈分布式事务的多重实现方式（理论层数）

Posted 2021-03-06 cxygg

 

2pc 认为 事务的全局提交不会出问题。
2 段式提交的原理是一 资源管理器 管理着一群长事务。
1 资源管理器告诉每事务管理器都做数据修改以后，不提交单前事务，并且告诉 rm 我完成了，可以提交了
2 如果 有一个事务 失败，那么 大家因为都还没提交，好吧，失败事务通知 rm ，让大家一起回滚
3 如果大家都 走到 处理完逻辑，走到 提交这里，rm 收到 全部的 事务都可以提交了， 那么 rm 所有数据库事务提交。
4 这里有一个明显的问题，批量通知 事务提交的 会不会出被中断( 数据库到了提交这一步，没有逻辑执行我们认为他不会抛出异常，但是可能rm 死了，部分rm 没通知)
5 所以 rm 必须搞可用，死了一个 rm 还有 别的rm 来通知。
6 rm 高可用了，数据库死了怎么办，这个就需要 数据库的支持了，2pc 不是所有数据库都支持，数据库大有 一个事务日志，写硬盘上的，等他起来以后，rm 通过这个 事务日志，重新提交这个事务就可以了。

缺点很明显，事务时间长，锁定力度大，并且需要最后的一步提交需要数据库的支持。

tcc try 的时候 预处理资源，并且这个预留资源的操作在 try 结束时会提交事务的。

1 如果部分try 成功，那么后面的 try 也就别做了，失败的try 回滚，前面成功的try 执行 cancel（ cancel 使用用来取消 cry 的 资源锁定的 ），并且 cancel 要是幂等的。
2 如果所有的 try 都成功了，那么就 comfirm， comfirm 因为 try 里面预留了资源，所以主观理论 的认为 comfirm 不会失败（编码问题不算），comfirm 也要实现幂等。
3 如果程序正常执行那么，肯定数据就会一致性了，那么 为啥 comfirm cancel 需要幂等呢？
4 如果 部分try 失败，当前try 回滚（单前的 try 还没提交，可以回滚），前面的try 已经提交了，会调用 cancel 来取消 这是一个不同节点批处理，只有全部成功才成功，
如果失败了一个或者以上（比如 RM 调用 部分 cancel 以后挂了 ，或者 部分cancel 代码问题异常）。那么 这个分布式事务的状态就不是完成。 然后 资源管理器 活了，或者 过一会再调用 这个事务 失败的cancel。
这里有些人就有疑问了，rm 应该知道哪些失败了呀，只调用它们不就完了吗?这就说到另一个网络问题，网络通讯，收到 处理成功我们认为他一定处理成功了，如果没收到成功，它 可能也已经做了（ 处理方做了,响应你时候失败了,或者说响应超时）
所以，失败了可能已经做过一次，只有成功的才是成功。
5 上面的 cancel 过程。rm 管理的 分布式事务状态取消，那么这个理论上可以回到最初的 数据状态。

6 在说 comfirm 的时候。同理 有一群 需要 批量 的 comfirm ，这个也会失败呀，处理办法和cancel 一样。 失败了这个分布式事务就不是完成状态。如果失败的 comfirm 就要重新再调用一次。
即便寄到哪些节点失败，网络通讯也会有重复调用问题，所以需要幂等。保证每一个comfirm 都成功了，也保证即便 网络原因 认为失败调用了多次，也是数据一致的。

综上 tcc事务 ，try，comfirm ,cancel 都是独立的小事务，并且也可以保证 数据的一致性。不需要数据库的特殊支持，有事务就行。

通过 消息来实现 （本地消息，或者独立消息）备注这个消费服务器，可用用基于 消息队列(MQ) 来实现，也可以不用，这里的 消息服务器是处理 分布式事务消息的，不是指的 MQ。


1 本地有一个消息表，和本地事务处于 同一事务中。处理调用别的服务的时候，吧这个消息和本地事务一起持久化到本地数据库。（ 本地事务数据处理 和消息 是同一个事务，强一致性）
2 事务提交的时候，把个消息发送出去，并且消息 标记成已发送，未完成。
3 消费服务器 标记 收到这个消息，正常响应 A 以后，A 标记这个消息 一成功发送。这样A 就可以不管了，也可以保留一个 B 消费完成的状态。
4 消息服务器，可能 多次收到这条消息，所以消息要有唯一Id，消息服务器这边只保留这个消息一份。
5消息 服务器收到消息，让B 去消费这个消息，如果 B功消费了这个消息，那么标记这个消息完成，可能需要回复A，也可以不回复。B如果处理失败，消息服务器应该重发。
6 因为 B 的消息可能重复 ，那么B这里一定要是幂等的。
7 面 大致的流程，我们看看看 消息发出 以后的一些控制，A 在事务提交的时候 发出这个消息，发送消息这个 方法可以发送失败，但是必须不能影响 主事务的回滚（ 网络环境发送失败，不一定真的没发出去）


明显，这个种效率比较高，不依赖任何 资源管理器，都是依赖的本地事务，和分布式锁。 编码不用写 3 边，但是 他不能同时回滚，只能保证最终一致性。不求同年同月生，但求同年同月死。












分布式事务框架类似tx-lcn

 

 

更加高级的 分布式框架比如阿里正在开发的 那啥.........