fix: update distributed-transaction.md

docs/distributed-system/distributed-transaction.md

 ## 面试题
+
 分布式事务了解吗？你们是如何解决分布式事务问题的？
 
 ## 面试官心理分析
@@ -11,14 +12,14 @@
 
 分布式事务的实现主要有以下 6 种方案：
 
-* XA 方案
-* TCC 方案
-* SAGA 方案
-* 本地消息表
-* 可靠消息最终一致性方案
-* 最大努力通知方案
+- XA 方案
+- TCC 方案
+- SAGA 方案
+- 本地消息表
+- 可靠消息最终一致性方案
+- 最大努力通知方案
 
-### 两阶段提交方案/XA方案
+### 两阶段提交方案/XA 方案
 
 所谓的 XA 方案，即：两阶段提交，有一个**事务管理器**的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
 
@@ -36,9 +37,9 @@
 
 TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 
-* Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行**锁定或者预留**。
-* Confirm 阶段：这个阶段说的是在各个服务中**执行实际的操作**。
-* Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要**进行补偿**，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
+- Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行**锁定或者预留**。
+- Confirm 阶段：这个阶段说的是在各个服务中**执行实际的操作**。
+- Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要**进行补偿**，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）
 
 这种方案说实话几乎很少人使用，我们用的也比较少，但是也有使用的场景。因为这个**事务回滚**实际上是**严重依赖于你自己写代码来回滚和补偿**了，会造成补偿代码巨大，非常之恶心。
 
@@ -50,15 +51,21 @@ TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 
 ![distributed-transacion-TCC](./images/distributed-transaction-TCC.png)
 
-### Saga方案
-金融核心等业务 可能会选择TCC方案，以追求强一致性和更高的并发量，而对于更多的金融核心以上的业务系统 往往会选择补偿事务，补偿事务处理在30多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较公认的是采用 Saga 作为长事务的解决方案。
+### Saga 方案
+
+金融核心等业务可能会选择 TCC 方案，以追求强一致性和更高的并发量，而对于更多的金融核心以上的业务系统 往往会选择补偿事务，补偿事务处理在 30 多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较公认的是采用 Saga 作为长事务的解决方案。
+
 #### 基本原理
-业务流程中每个参与者都提交本地事务，若某一个参与者失败，则补偿前面已经成功的参与者。下图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，反向执行T3、T2、T1 的补偿服务C3、C2、C1，将T3、T2、T1 已经修改的数据补偿掉。
+
+业务流程中每个参与者都提交本地事务，若某一个参与者失败，则补偿前面已经成功的参与者。下图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，反向执行 T3、T2、T1 的补偿服务 C3、C2、C1，将 T3、T2、T1 已经修改的数据补偿掉。
+
 ![distributed-transacion-TCC](./images/distributed-transaction-saga.png)
+
 #### 使用场景
-对于一致性要求高、短流程、并发高 的场景，如：金融核心系统，会优先考虑 TCC方案。而在另外一些场景下，我们并不需要这么强的一致性，只需要保证最终一致性即可。
 
-比如 很多金融核心以上的业务（渠道层、产品层、系统集成层），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务。这种情况如果选择TCC方案开发的话，一来成本高，二来无法要求其它公司的服务也遵循 TCC 模式。同时流程长，事务边界太长，加锁时间长，也会影响并发性能。
+对于一致性要求高、短流程、并发高 的场景，如：金融核心系统，会优先考虑 TCC 方案。而在另外一些场景下，我们并不需要这么强的一致性，只需要保证最终一致性即可。
+
+比如 很多金融核心以上的业务（渠道层、产品层、系统集成层），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务。这种情况如果选择 TCC 方案开发的话，一来成本高，二来无法要求其它公司的服务也遵循 TCC 模式。同时流程长，事务边界太长，加锁时间长，也会影响并发性能。
 
 所以 Saga 模式的适用场景是：
 
@@ -66,10 +73,13 @@ TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 - 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
 
 #### 优势
+
 - 一阶段提交本地事务，无锁，高性能；
 - 参与者可异步执行，高吞吐；
 - 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的。
+
 #### 缺点
+
 - 不保证事务的隔离性。
 
 ### 本地消息表