diff --git a/docs/high-concurrency/mq-time-delay-and-expired-failure.md b/docs/high-concurrency/mq-time-delay-and-expired-failure.md
index cf90a38..d69b7d0 100644
--- a/docs/high-concurrency/mq-time-delay-and-expired-failure.md
+++ b/docs/high-concurrency/mq-time-delay-and-expired-failure.md
@@ -15,7 +15,7 @@
 一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。
 
 一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下：
-- 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。
+- 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
 - 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
 - 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，**消费之后不做耗时的处理**，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
 - 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
@@ -29,4 +29,4 @@
 假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。
 
 ### mq 都快写满了
-如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，**消费一个丢弃一个，都不要了**，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
\ No newline at end of file
+如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，**消费一个丢弃一个，都不要了**，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。