(资料图片)

理论

• 最近在看一些分布式方面的书籍. 关于分布式事务这个话题自己也是有一些感受和理解.将他写下来.供自己以后回首的时候,方便重拾记忆.

分布式 中有三个理论 ACID/CAP/BASE ,这几个单词真tm难记.只能用我自己无赖方法试着理解.

• 三个理论从开始到最后是一个由强到柔的过程. 可以在全局上分为两个方向去理解. 一个是 刚. 真刚-数据强一致性! 体现在 追求 操作原子性, 数据一致性,数据持久性,和操作隔离性四个方面.所以这个理论下的 最佳实践方案 也肯定践行着 它 刚的 性格.

• 刚完了之后,就是柔和 . 柔和是建立在 分布式这个环境下的.我目前自己手上7 8 个系统一起搞一条业务线. 感觉想刚也刚不起来.此时首先要追求的一点 ,也是必须保证的一点. 分区容错性! 这一点必须要保证,没有这一点. 何来分布式一说.... -> 服务都不能保证可用和互相通讯...保证这一点后,根据业务性质,开始做取舍

  1. 方向一 数据可用性.分布式 场景下的 事务. 也就是 好几个应用共同干一件事! 无疑是把这个事情的过程拉长了. 以前做事情 啪! 一下搞完了.现在 啪啪啪 好多下,也不一定搞完.这个过程中,是否允许用户使用数据,是否允许资源可获取,是否要把握整个过程的资源通透性. 这个是根据自己的业务场景和环境来决定.
  2. 方向二 数据一致性分布式事务 .围绕的根本问题就是数据一致性. 那对数据一致性的最求做到什么程度. 可不可以容忍 过程中的不一致性.也是根据自身的业务场景来决定.

• 数据可用性 和 数据一致性是两个相向而行的射线. 如何做到两者的取舍和平衡. 其实就是 三个理论中的第二个理论和第三个理论. 第二个理论讲的是 追求数据可用性 方案和追求数据一致性方案. 第三个理论是在最求数据可用性的 基础上. 保证数据一致性. 找到一个业务可接受的平衡点.

模型

分布式事务的模型.这个模型读完感觉好奇怪.感觉他和隔壁的 分布式互斥方案好类似. 都是一个协调者搞事情. 也都带出来一个新问题. 协调者挂了怎么搞. 这个模型,目前我的皮毛知识面理解下来.感觉他在,又好像不在... ...听君一席话,如听一席话....分为4个部分.

• 协调者(独立部署)

一个事务组成成员的 注册. 事务的 成功与否 .可能还有整个过程的 记录(史官)

• 应用(我可以理解为事务成员吧)
• 资源管理者(我可以理解为寄生虫吧)、

很多年前,经常流行一句话是 你的安卓机开root了吗. 这里这个资源管理者. 应该获取了事务成员每个独立个体的 事务的 提交和回滚的权利. 也就是以前的自动事务提交现在改为手动了.谁说了算呢. 这个寄生虫说了算.

• XA(没理解)

原话 : 资源管理器和事务管理器之间通讯遵循的协议规范,事务管理器通过它来管理和控制资源管理器上的原子事务访问资源.这个有必要单独一个部分吗.或者是我理解错了. 立个 flag : 等找个时间按照2阶段理论和协调者的概念自己写一个分布式事务中间件.看看会不会遇到这个部分.

方案

两阶段提交

用我自己的话总结起来就是寄生虫式事务处理. 分布式事务中的各个成员之间保留了自己的事务处理.但是执行提交和回滚不归他们管, 统一由我协调者说了算. 我说提交.我的手下就讲成员应用上的事务提交.我说回滚,就把他们的事务全部一个个回滚.

三阶段提交

三阶段提交 用自己的理解起名 : 我预判了你的预判. 比这个三阶段提交好记多了首先我先预判你成功的样子.再预判你失败的样子. 然后大家一起做事情. 成功了.就是我预判的你成功的预判结果. 失败了. 就用我预判了你失败的预判的结果实现方式上 要实现三套代码逻辑 1.try 2.comfirm 3.cancel 第一个 就是预判的准备阶段. 第二个阶段就是执行预判的成功结果 .第三个就是执行预判的失败结果.

总结 : 分布式事务我目前的工作中还没有实战接触到,按照脑海中的实现思路来讲. 三阶段提交 的方式 和两阶段比较起来 更像是 把事务的过程拉长了. 在拉长的过程中. 每个步骤都是可见的 .可以读的,当然在最后的最后.它还是保证了数据的最终一致性. 而反观二阶段提交,比较纯粹. 思路更简洁,要嘛全部成功.要嘛全部是失败,而且可以站在 目前代码中普遍的 spring事务管理的肩膀上. 稍微改造一下就可以实现.当然 缺点就是对于过程的可控性和灵活性就差了很多. 两种方案都对代码有着不可避免的入侵. 二阶段入侵要比三阶段少.2022年12月28号 20点48.下班打卡.