理论
- 最近在看一些分布式方面的书籍. 关于分布式事务这个话题自己也是有一些感受和理解.将他写下来.供自己以后回首的时候,方便重拾记忆.
分布式 中有三个理论 ACID/CAP/BASE ,这几个单词真tm难记.只能用我自己无赖方法试着理解.
-
三个理论从开始到最后是一个由强到柔的过程. 可以在全局上分为两个方向去理解. 一个是 刚. 真刚-数据强一致性! 体现在 追求 操作原子性, 数据一致性,数据持久性,和操作隔离性四个方面.
所以这个理论下的 最佳实践方案 也肯定践行着 它 刚的 性格. -
刚完了之后,就是柔和 . 柔和是建立在 分布式这个环境下的.我目前自己手上7 8 个系统一起搞一条业务线. 感觉想刚也刚不起来.
此时首先要追求的一点 ,也是必须保证的一点. 分区容错性! 这一点必须要保证,没有这一点. 何来分布式一说.... -> 服务都不能保证可用和互相通讯...
保证这一点后,根据业务性质,开始做取舍- 方向一 数据可用性.
分布式 场景下的 事务. 也就是 好几个应用共同干一件事! 无疑是把这个事情的过程拉长了. 以前做事情 啪! 一下搞完了.现在 啪啪啪 好多下,也不一定搞完.
这个过程中,是否允许用户使用数据,是否允许资源可获取,是否要把握整个过程的资源通透性. 这个是根据自己的业务场景和环境来决定. - 方向二 数据一致性
分布式事务 .围绕的根本问题就是数据一致性. 那对数据一致性的最求做到什么程度. 可不可以容忍 过程中的不一致性.也是根据自身的业务场景来决定.
- 方向一 数据可用性.
-
数据可用性 和 数据一致性是两个相向而行的射线. 如何做到两者的取舍和平衡. 其实就是 三个理论中的第二个理论和第三个理论. 第二个理论讲的是 追求数据可用性 方案和追求数据一致性方案. 第三个理论是在最求数据可用性的 基础上. 保证数据一致性. 找到一个业务可接受的平衡点.
模型
分布式事务的模型.这个模型读完感觉好奇怪.感觉他和隔壁的 分布式互斥方案好类似. 都是一个协调者搞事情. 也都带出来一个新问题. 协调者挂了怎么搞. 这个模型,目前我的皮毛知识面理解下来.感觉他在,又好像不在... ...听君一席话,如听一席话....
分为4个部分.
- 协调者(独立部署)
一个事务组成成员的 注册. 事务的 成功与否 .可能还有整个过程的 记录(史官)
- 应用(我可以理解为事务成员吧)
- 资源管理者(我可以理解为寄生虫吧)、
很多年前,经常流行一句话是 你的安卓机开root了吗. 这里这个资源管理者. 应该获取了事务成员每个独立个体的 事务的 提交和回滚的权利. 也就是以前的自动事务提交现在改为手动了.谁说了算呢. 这个寄生虫说了算.
- XA(没理解)
原话 : 资源管理器和事务管理器之间通讯遵循的协议规范,事务管理器通过它来管理和控制资源管理器上的原子事务访问资源.
这个有必要单独一个部分吗.或者是我理解错了. 立个 flag : 等找个时间按照2阶段理论和协调者的概念自己写一个分布式事务中间件.看看会不会遇到这个部分.
方案
两阶段提交
用我自己的话总结起来就是寄生虫式事务处理. 分布式事务中的各个成员之间保留了自己的事务处理.但是执行提交和回滚不归他们管, 统一由我协调者说了算. 我说提交.我的手下就讲成员应用上的事务提交.我说回滚,就把他们的事务全部一个个回滚.
三阶段提交
三阶段提交 用自己的理解起名 : 我预判了你的预判. 比这个三阶段提交好记多了
首先我先预判你成功的样子.再预判你失败的样子. 然后大家一起做事情. 成功了.就是我预判的你成功的预判结果. 失败了. 就用我预判了你失败的预判的结果
实现方式上 要实现三套代码逻辑 1.try 2.comfirm 3.cancel 第一个 就是预判的准备阶段. 第二个阶段就是执行预判的成功结果 .第三个就是执行预判的失败结果.