diff --git a/distributed-transaction/BASE.md b/distributed-transaction/BASE.md
index 887fe464..deb0a8f7 100644
--- a/distributed-transaction/BASE.md
+++ b/distributed-transaction/BASE.md
@@ -16,7 +16,7 @@ Dan Pritchett 在论文中的提出的实现最终一致性技术手段非常有
-- 用户向商店发送一个交易请求，譬如购买一直价值 ￥100 的钢笔。
+- 用户向商店发送一个交易请求，譬如购买一支价值 ￥100 的钢笔。
- 支付服务创建一个本地的扣款事务，如果扣款成功，则在自己的数据库内建立一张消息表，表内如下结构：事务ID，扣款￥100（状态：已完成），仓库出库（状态：待进行），赠送积分(状态：待进行)。
- 在系统内建立一个消息服务，定时轮询消息表，将状态是”进行中“的消息同时发送到库存和积分服务节点中。这个时候会产生以下几种情况：
- 仓库服务和积分服务都顺利完成了出库和加分的工作，向支付服务返回执行结果，支付服务把消息改为”已完成“。整个事务顺利完成，最终实现一致性。
diff --git a/distributed-transaction/TCC.md b/distributed-transaction/TCC.md
index b30d84f5..8cfe228c 100644
--- a/distributed-transaction/TCC.md
+++ b/distributed-transaction/TCC.md
@@ -16,7 +16,7 @@ TCC 是一种对业务侵入性较强的事务方案，要求业务处理过程
-1. 用户向商店发送一个交易请求，譬如购买一直价值 ￥100 的钢笔。
+1. 用户向商店发送一个交易请求，譬如购买一支价值 ￥100 的钢笔。
2. 创建事务，生成事务 ID，记录在活动日志中，进入 Try 阶段。
- 支付服务：检查业务可行性，若可行，将用户的 100 元设置为冻结状态，通知下一步进行 Confirm 阶段；若不可行，通知下一步进入 Cancel 阶段。
- 仓库服务：检查业务可行性，若可行，将仓库该商品的其中一条库存设置为冻结状态，通知下一步进行 Confirm 阶段；若不可行，通知下一步进入 Cancel 阶段。