Merge remote-tracking branch 'origin/main'

isno · Jan 11, 2024 · 32ef1d0 · 32ef1d0
2 parents ec584ab + 08f6316
commit 32ef1d0
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/distributed-transaction/BASE.md b/distributed-transaction/BASE.md
@@ -16,7 +16,7 @@ Dan Pritchett 在论文中的提出的实现最终一致性技术手段非常有
 	<img src="../assets/BASE.svg" width = "600"  align=center />
 </div>
 
-- 用户向商店发送一个交易请求，譬如购买一直价值 ￥100 的钢笔。
+- 用户向商店发送一个交易请求，譬如购买一支价值 ￥100 的钢笔。
 - 支付服务创建一个本地的扣款事务，如果扣款成功，则在自己的数据库内建立一张消息表，表内如下结构：事务ID，扣款￥100（状态：已完成），仓库出库（状态：待进行），赠送积分(状态：待进行)。
 - 在系统内建立一个消息服务，定时轮询消息表，将状态是”进行中“的消息同时发送到库存和积分服务节点中。这个时候会产生以下几种情况：
 	- 仓库服务和积分服务都顺利完成了出库和加分的工作，向支付服务返回执行结果，支付服务把消息改为”已完成“。整个事务顺利完成，最终实现一致性。

diff --git a/distributed-transaction/TCC.md b/distributed-transaction/TCC.md
@@ -16,7 +16,7 @@ TCC 是一种对业务侵入性较强的事务方案，要求业务处理过程
 	<img src="../assets/TCC.svg" width = "450"  align=center />
 </div>
 
-1. 用户向商店发送一个交易请求，譬如购买一直价值 ￥100 的钢笔。
+1. 用户向商店发送一个交易请求，譬如购买一支价值 ￥100 的钢笔。
 2. 创建事务，生成事务 ID，记录在活动日志中，进入 Try 阶段。
 	- 支付服务：检查业务可行性，若可行，将用户的 100 元设置为冻结状态，通知下一步进行 Confirm 阶段；若不可行，通知下一步进入 Cancel 阶段。
 	- 仓库服务：检查业务可行性，若可行，将仓库该商品的其中一条库存设置为冻结状态，通知下一步进行 Confirm 阶段；若不可行，通知下一步进入 Cancel 阶段。