fix(docs): fix typo

README.md

@@ -4,10 +4,11 @@
 [![original](https://img.shields.io/badge/original-%E4%B8%AD%E5%8D%8E%E7%9F%B3%E6%9D%89-blue.svg)](https://github.com/doocs/advanced-java)
 [![PRs Welcome](https://img.shields.io/badge/PRs-Welcome-brightgreen.svg)](http://makeapullrequest.com)
 
-本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。
+本系列知识出自中华石杉，我对这部分知识做了一个系统的整理，方便学习查阅。By the way，微信公众号**石杉的架构笔记**（id:shishan100）有其它很多架构知识，墙裂推荐~
 
 一点小建议：学习本系列知识之前，如果你完全没接触过 `MQ`、`ES`、`Redis`、`Dubbo`、`Hystrix` 等，那么我建议你可以先在网上搜一下每一块知识的快速入门，玩一下入门 Demo，然后再开始每一块知识的学习。这样效果更好噢~
 
+
 ## 高并发架构
 
 ### [消息队列](/docs/high-concurrency/mq-interview.md)

docs/high-concurrency/mq-time-delay-and-expired-failure.md

@@ -12,7 +12,7 @@
 ### 大量消息在 mq 里积压了几个小时了还没解决
 几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。
 
-一个消费者一秒是 1000 条，一秒 3个 消费者是 3000 条，一分钟就是是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。
+一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。
 
 一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下：
 - 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。