From 06545375a2cf6421d8c290937137557e2cf2cc89 Mon Sep 17 00:00:00 2001 From: daniubi <804703017@qq.com> Date: Tue, 29 Jun 2021 19:05:05 +0800 Subject: [PATCH 1/5] =?UTF-8?q?2.1.7=20=E6=B6=88=E6=81=AF=E7=9A=84=20push?= =?UTF-8?q?=20=E5=AE=9E=E7=8E=B0--=E8=A1=A5=E5=85=85?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 感觉这样对初学者而言更直观一点。 --- .../distributed-system/message-queue/RocketMQ-Questions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/system-design/distributed-system/message-queue/RocketMQ-Questions.md b/docs/system-design/distributed-system/message-queue/RocketMQ-Questions.md index a41a4035b7b..843d927a90a 100644 --- a/docs/system-design/distributed-system/message-queue/RocketMQ-Questions.md +++ b/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 消息重复发送的避免 From 86558e417d566c0f4c296eea8e22853634eeff5a Mon Sep 17 00:00:00 2001 From: daniubi <804703017@qq.com> Date: Wed, 30 Jun 2021 09:01:54 +0800 Subject: [PATCH 2/5] Update RocketMQ.md --- .../distributed-system/message-queue/RocketMQ.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/system-design/distributed-system/message-queue/RocketMQ.md b/docs/system-design/distributed-system/message-queue/RocketMQ.md index c74fab6feeb..9391d522e13 100644 --- a/docs/system-design/distributed-system/message-queue/RocketMQ.md +++ b/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，是不是有一点复杂🤣，看英文图片和英文文档的时候就 等等。。。 -> 如果喜欢可以点赞哟👍👍👍。 \ No newline at end of file +> 如果喜欢可以点赞哟👍👍👍。 From 0cafebbdc32f4f930f7d73ae45c34b6825cd1788 Mon Sep 17 00:00:00 2001 From: daniubi <804703017@qq.com> Date: Wed, 30 Jun 2021 09:16:23 +0800 Subject: [PATCH 3/5] Update RocketMQ.md --- .../distributed-system/message-queue/RocketMQ.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/system-design/distributed-system/message-queue/RocketMQ.md b/docs/system-design/distributed-system/message-queue/RocketMQ.md index c74fab6feeb..cd45b3d3525 100644 --- a/docs/system-design/distributed-system/message-queue/RocketMQ.md +++ b/docs/system-design/distributed-system/message-queue/RocketMQ.md @@ -200,6 +200,8 @@ 因为我们刚刚画的仅仅是一个消费者组，我们知道在发布订阅模式中一般会涉及到多个消费者组，而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)，它仅仅是为每个消费者组维护一个 **消费位移(offset)** ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费了。 +这里我有一个疑问：上面说【一个队列只会被一个消费者消费】下面说说【那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)】，讲不通啊，消息在不同队列上是重复的吗？ + ![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3857fefaa079.jpg) 可能你还有一个问题，**为什么一个主题中需要维护多个队列** ？ @@ -451,4 +453,4 @@ emmm，是不是有一点复杂🤣，看英文图片和英文文档的时候就 等等。。。 -> 如果喜欢可以点赞哟👍👍👍。 \ No newline at end of file +> 如果喜欢可以点赞哟👍👍👍。 From 9c185d3f350221f9aaa706bd1ddfe60edc50099c Mon Sep 17 00:00:00 2001 From: guide Date: Wed, 30 Jun 2021 21:19:28 +0800 Subject: [PATCH 4/5] Update RocketMQ.md --- docs/system-design/distributed-system/message-queue/RocketMQ.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/system-design/distributed-system/message-queue/RocketMQ.md b/docs/system-design/distributed-system/message-queue/RocketMQ.md index 38fb6b1a2df..9391d522e13 100644 --- a/docs/system-design/distributed-system/message-queue/RocketMQ.md +++ b/docs/system-design/distributed-system/message-queue/RocketMQ.md @@ -200,8 +200,6 @@ 因为我们刚刚画的仅仅是一个消费者组，我们知道在发布订阅模式中一般会涉及到多个消费者组，而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)，它仅仅是为每个消费者组维护一个 **消费位移(offset)** ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费了。 -这里我有一个疑问：上面说【一个队列只会被一个消费者消费】下面说说【那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)】，讲不通啊，消息在不同队列上是重复的吗？ - ![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/16ef3857fefaa079.jpg) 可能你还有一个问题，**为什么一个主题中需要维护多个队列** ？ From 53e1ffdf21865e501b3e21123b720543d52b2493 Mon Sep 17 00:00:00 2001 From: guide Date: Wed, 30 Jun 2021 21:19:31 +0800 Subject: [PATCH 5/5] Update MySQL.md --- docs/database/MySQL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/database/MySQL.md b/docs/database/MySQL.md index 5edb178dcb4..0241d05ee9a 100644 --- a/docs/database/MySQL.md +++ b/docs/database/MySQL.md @@ -132,7 +132,7 @@ MVCC 可以看作是行级锁的一个升级，可以有效减少加锁操作， - Record lock：记录锁，单个行记录上的锁 - Gap lock：间隙锁，锁定一个范围，不包括记录本身 -- Next-key lock：record+gap临键锁，锁定一个范围，包含记录本身 +- Next-key lock：record+gap 临键锁，锁定一个范围，包含记录本身 ## 查询缓存