[pull] master from Snailclimb:master

docs/database/MySQL.md

@@ -132,7 +132,7 @@ MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作，
 
 - Record lock：记录锁，单个行记录上的锁
 - Gap lock：间隙锁，锁定一个范围，不包括记录本身
-- Next-key lock：record+gap临键锁，锁定一个范围，包含记录本身
+- Next-key lock：record+gap 临键锁，锁定一个范围，包含记录本身
 
 ## 查询缓存
 

docs/system-design/distributed-system/message-queue/RocketMQ-Questions.md

@@ -172,6 +172,8 @@ class Broker {
 
 1. 注意，RocketMQ 已经说了自己会有低延迟问题，其中就包括这个消息的 push 延迟问题
 2. 因为这并不是真正的将消息主动的推送到消费者，而是 Broker 定时任务每5s将消息推送到消费者
+3. pull模式需要我们手动调用consumer拉消息，而push模式则只需要我们提供一个listener即可实现对消息的监听，而实际上，RocketMQ的push模式是基于pull模式实现的，它没有实现真正的push。
+4. push方式里，consumer把轮询过程封装了，并注册MessageListener监听器，取到消息后，唤醒MessageListener的consumeMessage()来消费，对用户而言，感觉消息是被推送过来的。
 
 ### 2.1.8 消息重复发送的避免
 

docs/system-design/distributed-system/message-queue/RocketMQ.md

@@ -190,7 +190,7 @@
 
 你可以看到图中生产者组中的生产者会向主题发送消息，而 **主题中存在多个队列**，生产者每次生产消息之后是指定主题中的某个队列发送消息的。
 
-每个主题中都有多个队列(这里还不涉及到 `Broker`)，集群消费模式下，一个消费者集群多台机器共同消费一个 `topic` 的多个队列，**一个队列只会被一个消费者消费**。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。就像上图中 `Consumer1` 和 `Consumer2` 分别对应着两个队列，而 `Consuer3` 是没有队列对应的，所以一般来讲要控制 **消费者组中的消费者个数和主题中队列个数相同** 。
+每个主题中都有多个队列(分布在不同的 `Broker`中，如果是集群的话，`Broker`又分布在不同的服务器中)，集群消费模式下，一个消费者集群多台机器共同消费一个 `topic` 的多个队列，**一个队列只会被一个消费者消费**。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。就像上图中 `Consumer1` 和 `Consumer2` 分别对应着两个队列，而 `Consuer3` 是没有队列对应的，所以一般来讲要控制 **消费者组中的消费者个数和主题中队列个数相同** 。
 
 当然也可以消费者个数小于队列个数，只不过不太建议。如下图。
 
@@ -451,4 +451,4 @@ emmm，是不是有一点复杂🤣，看英文图片和英文文档的时候就
 
 等等。。。
 
-> 如果喜欢可以点赞哟👍👍👍。
+> 如果喜欢可以点赞哟👍👍👍。