diff --git a/docs/distributed-system/distributed-transaction.md b/docs/distributed-system/distributed-transaction.md
index c2ea6c3..8f100e4 100644
--- a/docs/distributed-system/distributed-transaction.md
+++ b/docs/distributed-system/distributed-transaction.md
@@ -1,4 +1,5 @@
 ## 面试题
+
 分布式事务了解吗？你们是如何解决分布式事务问题的？
 
 ## 面试官心理分析
@@ -9,15 +10,16 @@
 
 ## 面试题剖析
 
-分布式事务的实现主要有以下 5 种方案：
+分布式事务的实现主要有以下 6 种方案：
 
-* XA 方案
-* TCC 方案
-* 本地消息表
-* 可靠消息最终一致性方案
-* 最大努力通知方案
+- XA 方案
+- TCC 方案
+- SAGA 方案
+- 本地消息表
+- 可靠消息最终一致性方案
+- 最大努力通知方案
 
-### 两阶段提交方案/XA方案
+### 两阶段提交方案/XA 方案
 
 所谓的 XA 方案，即：两阶段提交，有一个**事务管理器**的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。
 
@@ -49,6 +51,37 @@ TCC 的全称是： `Try` 、 `Confirm` 、 `Cancel` 。
 
 ![distributed-transacion-TCC](./images/distributed-transaction-TCC.png)
 
+### Saga 方案
+
+金融核心等业务可能会选择 TCC 方案，以追求强一致性和更高的并发量，而对于更多的金融核心以上的业务系统 往往会选择补偿事务，补偿事务处理在 30 多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。目前业界比较公认的是采用 Saga 作为长事务的解决方案。
+
+#### 基本原理
+
+业务流程中每个参与者都提交本地事务，若某一个参与者失败，则补偿前面已经成功的参与者。下图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，反向执行 T3、T2、T1 的补偿服务 C3、C2、C1，将 T3、T2、T1 已经修改的数据补偿掉。
+
+![distributed-transacion-TCC](./images/distributed-transaction-saga.png)
+
+#### 使用场景
+
+对于一致性要求高、短流程、并发高 的场景，如：金融核心系统，会优先考虑 TCC 方案。而在另外一些场景下，我们并不需要这么强的一致性，只需要保证最终一致性即可。
+
+比如 很多金融核心以上的业务（渠道层、产品层、系统集成层），这些系统的特点是最终一致即可、流程多、流程长、还可能要调用其它公司的服务。这种情况如果选择 TCC 方案开发的话，一来成本高，二来无法要求其它公司的服务也遵循 TCC 模式。同时流程长，事务边界太长，加锁时间长，也会影响并发性能。
+
+所以 Saga 模式的适用场景是：
+
+- 业务流程长、业务流程多；
+- 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
+
+#### 优势
+
+- 一阶段提交本地事务，无锁，高性能；
+- 参与者可异步执行，高吞吐；
+- 补偿服务易于实现，因为一个更新操作的反向操作是比较容易理解的。
+
+#### 缺点
+
+- 不保证事务的隔离性。
+
 ### 本地消息表
 
 本地消息表其实是国外的 ebay 搞出来的这么一套思想。
diff --git a/docs/distributed-system/images/distributed-transaction-saga.png b/docs/distributed-system/images/distributed-transaction-saga.png
new file mode 100644
index 0000000..181d8d7
Binary files /dev/null and b/docs/distributed-system/images/distributed-transaction-saga.png differ