diff --git a/notes/pics/rocketmq-transaction.png b/notes/pics/rocketmq-transaction.png
new file mode 100644
index 00000000..431ac11f
Binary files /dev/null and b/notes/pics/rocketmq-transaction.png differ
diff --git a/notes/pics/saga.png b/notes/pics/saga.png
new file mode 100644
index 00000000..9232b074
Binary files /dev/null and b/notes/pics/saga.png differ
diff --git a/notes/分布式.md b/notes/分布式.md
index 7cd66180..7b3373fc 100644
--- a/notes/分布式.md
+++ b/notes/分布式.md
@@ -210,6 +210,8 @@ TCC（Try-Confirm-Cancel）是在业务层面实现的两阶段提交，每个
Saga 将一个分布式事务拆分为多个本地事务，每个本地事务直接提交，并且都有一个对应的补偿操作。依次执行各个本地事务，如果某一个失败，就逆序执行前面已经提交的本地事务的补偿操作。
+
+
Saga 没有预留资源的 Try 阶段，中间状态对其它事务可见，因此没有隔离性。它适合流程长、无法长时间锁定资源的业务，正向操作和补偿操作同样需要实现幂等。
### 本地消息表
@@ -226,6 +228,8 @@ Saga 没有预留资源的 Try 阶段，中间状态对其它事务可见，因
RocketMQ 的事务消息把本地消息表的工作交给了消息队列：生产者先发送一条对消费者不可见的半消息，再执行本地事务，然后根据执行结果通知 Broker 提交或者回滚这条消息。如果 Broker 长时间没有收到通知，会主动回查生产者的本地事务状态。
+
+
## 三、CAP
分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition Tolerance）。常见的“三选二”说法有误导性，因为网络分区是无法避免的故障，不是可以选择的选项。
