聂同学

一个程序员和架构师的实践与思考

分布式事务,也谈

近来有挺多文章谈“分布式事务”。 这些文章主要是从实现模式角度来谈的。比如常见的模式有哪些,哪些个模式适合哪种场景,有什么优点缺点,根据什么选择等等。 比如附图的这个红绿灯图,是其中的优秀代表。很有指导作用。

这个“也谈”1不重复这些,从其他角度谈一些认识。

“分布式事务”到底是什么2

  1. “分布式事务”本质上是对一个过程进行管理。
  2. 这个过程由一些操作构成,特别是由一些有状况3的操作构成。
  3. 管理者的职责是可控地调用这些操作。特别是当某些操作出现状况时,做出决策和处置。

为了完成管理的职责,管理者必须清楚所有操作的两方面特性:一方面,操作的状况如何获知(包括是否需要获知)。另一方面,在特定状况下,可以对操作进行何种处置。比如 -

  • 成功/失败 - 一般操作有这两种基本状况。但并不一定限于此两种。
  • 超时 - 常见操作状况的一种,一般等于是状况未知。
  • 回查 - 回查是获取操作状况的手段,即向操作提供者查询某笔操作是否成功。是否可回查,是操作的特性。
  • 重试 - 处置的一种,即再次尝试。是否可重试,是操作的特性。
  • 幂等 - 操作的特性,是可重试中的一种情况。
  • 补偿 - 处置的一种,是对操作进行撤销的一种办法。
  • ……

根据操作的特性,当某些操作出现状况时,管理者可以决策和处置所有操作。决策和处置的规则,是管理者的核心知识,比如体现为决策表格 -

操作A状况 操作B状况 处置策略
成功 失败 操作A撤销
未知 (未尝试) 重试操作A
成功 未知 回查操作B
成功 繁忙 等待时间t后重试B
成功 已排队 等待时间t后回查B
…… …… ……

所有常见的实现模式(比如附图的原文所列举的),都是对上述要点的实现,从不同的方面做了特殊化。-

  1. Saga模式 - 比较一般的模型。但仍然有一些特殊要求。比如操作都有反操作。
  2. 补偿模式 - 特殊而简化的模型,一般用于处理按顺序执行的系列操作,一旦某个操作失败,对已经成功的操作全部进行补偿。
  3. TCC模式 - 特殊模型,可以做到在事务过程中外界对操作不可见,也就是做到“隔离性”,但这个特性并不是由操作的管理者带来的,而是由操作的提供者带来的。通过将一个普通的业务操作分拆为相关联的两个,操作提供者实现了操作对外部的不可见。两个操作之间需要一个状态的维护。
  4. 可靠事件模式 - 特殊模型,该模式重点不在管理,而在管理者调用操作的途径。这个途径的特点是底层机制决定了管理者可以假定操作总会成功(或者说就当它都成功了)。所以对过程的管理就可以比较简单了。管理者不再需要处理操作状况的可知、操作的重试、撤销等问题。
  5. 两段、三段提交模式 - 不谈了。

下一篇,谈一谈实现模型)

原文:分布式事务:不过是在一致性、吞吐量和复杂度之间,做一个选择


  1. 强行音译为Yet Another,嗯,听起来还蛮像的。😂

  2. 貌似通篇也适合“不分布”式事务。

  3. “状况”,我自己选择的词汇,区别于“结果”,比如1+1的操作,2(或者3)是“结果”,做完了或者没做完或者不愿意做是“状况”。

分布式, 架构, 设计

分享 -