Skip to content

Commit 4d84559

Browse files
committed
init
1 parent d57cef7 commit 4d84559

File tree

4 files changed

+267
-48
lines changed

4 files changed

+267
-48
lines changed

09消息队列/1概念和特性.md

Lines changed: 11 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -24,19 +24,18 @@
2424
>| 时间依赖,消费是否运行,点对点不是必须运行,发布订阅模式,必须有一个订阅者,不然消息作废
2525
2626

27-
2. 应用场景
27+
### **为什么需要消息队列?有什么优缺点?**
28+
消息队列(MQ)的主要作用:
29+
- **解耦**:生产者和消费者无需直接通信,降低系统耦合度。
30+
- **异步处理**:可以让系统异步执行任务,提高响应速度,如:发送注册邮件短信。
31+
- **削峰填谷**:通过消息堆积缓冲突发流量,防止数据库或服务崩溃。
32+
- **可靠通信**:提供消息持久化、重试机制,确保数据不会丢失。
33+
34+
**缺点:**
35+
- **增加系统复杂度**:引入 MQ 后,需要处理消息丢失、重复消费、顺序保证等问题。
36+
- **数据一致性问题**:由于 MQ 采用异步方式,可能导致数据不一致。
37+
- **运维成本高**:MQ 需要额外的监控、故障恢复、扩展维护
2838

2939

30-
1. 异步处理(用户注册,发送注册邮件短信)
31-
32-
2. 应用解耦(用户下单后通知扣库存)
33-
34-
3. 流量削锋(团购和秒杀)
35-
36-
4. 日志处理
37-
38-
5. 消息通讯
39-
40-
6. 可恢复性(系统中组件失效,不会全部影响)
4140

4241

09消息队列/2对比.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,3 +12,46 @@
1212
|常用场景|日志,大数据|金融支付|降低耦合|共享cache,session|||
1313
|事务||||||XA事务|
1414
|动态扩容|支持zk|不支持|不支持||||
15+
16+
### **RabbitMQ、Kafka、RocketMQ 的区别是什么?**
17+
| 对比项 | RabbitMQ | Kafka | RocketMQ |
18+
|-------------|---------------|-------------|-------------|
19+
| **数据存储** | 基于内存+磁盘 | 仅基于磁盘存储 | 基于磁盘存储 |
20+
| **吞吐量** | 低(万级) | 高(百万级) | 中等(十万级) |
21+
| **消息顺序** | 队列保证顺序 | 分区保证局部顺序 | 队列保证顺序 |
22+
| **消费模式** | **Push** | **Pull** | **Pull** |
23+
| **事务支持** | 支持事务 | 不支持事务 | 支持事务 |
24+
| **典型应用** | 短信、邮件 | 日志收集、数据分析 | 订单、支付 |
25+
26+
### **如何保证 MQ 消息不丢失?**
27+
**回答:**
28+
1. **生产端**
29+
- **消息持久化**(RabbitMQ 开启 `persistent=true`
30+
- **事务模式**(RabbitMQ 开启事务,但降低吞吐量)
31+
- **发送确认机制(Confirm)**
32+
2. **消息队列**
33+
- **持久化存储**(Kafka 默认写入磁盘日志)
34+
- **多副本机制**(Kafka `replication` 参数)
35+
3. **消费端**
36+
- **ACK 机制**(RabbitMQ 需要 `ack=true`
37+
- **幂等性处理**(防止重复消费)
38+
39+
40+
41+
### **如何保证 MQ 消息顺序?**
42+
**回答:**
43+
1. **单个分区(单个队列)**
44+
-**Kafka** 中,同一类消息写入同一个分区
45+
-**RabbitMQ** 中,只让一个消费者消费该队列
46+
2. **有序消费**
47+
- **Kafka**:消费者按 **同一分区** 读取消息
48+
- **RabbitMQ**:使用 **x-delayed-message** 插件
49+
3. **全局顺序**
50+
- 只能保证某个 **key** 级别的顺序,全局顺序 MQ 无法保证
51+
52+
### **Q7: 如何扩展 RabbitMQ?支持动态扩容吗?**
53+
**回答:**
54+
1. **手动添加节点**
55+
2. **Kubernetes 动态扩容**
56+
3. **分片机制**
57+
- 采用 **多个队列**,不同队列存放不同的消息类型

09消息队列/3RabbitMQ.md

Lines changed: 107 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -1,36 +1,16 @@
11
## rabbitmq
2-
[信道,交换机,队列](https://www.cnblogs.com/zhangxue/p/7699698.html)
32

4-
[概念](https://www.cnblogs.com/jun-ma/p/4840869.html)
3+
### RabbitMQ 是什么?它的核心组件有哪些?**
4+
RabbitMQ 是一个基于 **AMQP(Advanced Message Queuing Protocol)** 协议的消息队列中间件,具有高可靠性、持久化存储和灵活的路由机制。
55

6-
[教程](https://github.com/rabbitmq/rabbitmq-tutorials)
7-
8-
[queue参数](https://www.cnblogs.com/LiangSW/p/6218886.html)
9-
10-
[go](https://blog.csdn.net/smile_YangYue/article/details/80709427)
11-
12-
### 概念:
13-
14-
15-
Broker:简单来说就是消息队列服务器实体。
16-
17-
  Exchange:消息交换机,它指定消息按什么规则,路由到哪个队列。
18-
种类:direct 1:1 完全匹配 fanout 1:n 1条消息发送到绑定到的队列 topic n:1 n条消息根据模糊匹配,发送到一个队列
19-
20-
21-
  Queue:消息队列载体,每个消息都会被投入到一个或多个队列。
22-
23-
  Binding:绑定,它的作用就是把exchange和queue按照路由规则绑定起来。
24-
25-
  Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
26-
27-
  vhost:虚拟主机,一个broker里可以开设多个vhost,用作不同用户的权限分离。
28-
29-
  producer:消息生产者,就是投递消息的程序。
30-
31-
  consumer:消息消费者,就是接受消息的程序。
32-
33-
  channel:消息通道,在客户端的每个连接里,可建立多个channel,每个channel代表一个会话任务。
6+
**RabbitMQ 的核心组件:**
7+
- **Producer(生产者):** 负责发送消息到 RabbitMQ。
8+
- **Exchange(交换机):** 接收生产者的消息,并根据路由规则分发到队列。
9+
- **Queue(队列):** 存储消息,等待消费者消费。
10+
- **Consumer(消费者):** 从队列中取出消息并处理。
11+
- **Binding(绑定):** 连接队列和交换机,定义路由规则。
12+
- **Routing Key(路由键):** 生产者发送消息时附带的关键字,影响消息的投递方式。
13+
- **Virtual Host(虚拟主机):** 类似于命名空间,用于隔离不同的应用或租户。
3414

3515

3616
### 使用过程:
@@ -47,6 +27,97 @@
4727

4828
exchange接收到消息后,就根据消息的key和已经设置的binding,进行消息路由,将消息投递到一个或多个队列里。
4929

30+
### **RabbitMQ 与 Kafka 的区别是什么?**
31+
| **对比项** | **RabbitMQ** | **Kafka** |
32+
|-------------|-------------|----------|
33+
| **消息协议** | AMQP | 自定义协议 |
34+
| **数据存储** | 内存+磁盘存储 | 仅磁盘存储 |
35+
| **消息模式** | **Push** | **Pull** |
36+
| **吞吐量** | 低(万级) | 高(百万级) |
37+
| **消息顺序** | 队列级别保证顺序 | 分区级别保证顺序 |
38+
| **事务支持** | 支持事务 | 不支持事务 |
39+
| **典型应用** | 订单、任务调度 | 日志采集、大数据处理 |
40+
41+
### **RabbitMQ 如何保证消息不丢失?**
42+
1. **生产者端**
43+
- 开启 **消息持久化**`delivery_mode=2`)。
44+
- 使用 **Publisher Confirms** 机制,确保消息成功投递到交换机。
45+
2. **RabbitMQ 服务器**
46+
- 队列持久化(`durable=true`),避免 RabbitMQ 宕机导致数据丢失。
47+
- 开启 **高可用模式**(镜像队列)。
48+
- 开启 **磁盘持久化**,确保消息写入磁盘。
49+
3. **消费者端**
50+
- **ACK 确认机制**`manual_ack=true`),确保消息被成功处理后才从队列删除。
51+
- 处理失败时,**拒绝并重新入队**`basic.reject``basic.nack`)。
52+
53+
### **RabbitMQ 如何保证消息顺序?**
54+
- **单一队列消费**:单一消费者顺序消费,确保 FIFO(适用于低并发)。
55+
- **严格保证多消费者顺序**
56+
- 将消息 **按 key 进行分片**,使用多个队列,每个队列一个消费者。
57+
- 在业务层 **排序合并** 处理结果。
58+
59+
60+
### **RabbitMQ 的镜像队列(HA 队列)是什么?**
61+
- **RabbitMQ 镜像队列**:在多个节点上复制队列,保证高可用。
62+
- **如何启用?**
63+
- 配置 **policy**
64+
```sh
65+
rabbitmqctl set_policy ha-all "^queue_name" '{"ha-mode":"all"}'
66+
```
67+
- **优缺点**
68+
- **优点**:避免单点故障,RabbitMQ 宕机不会丢失数据。
69+
- **缺点**:同步数据增加网络和存储开销。
70+
71+
### **如何优化 RabbitMQ 的性能?**
72+
1. **生产者优化**
73+
- **批量发布**`batch.publish`),减少网络 I/O 开销。
74+
- **消息压缩**(gzip/snappy),减少数据传输量。
75+
2. **队列优化**
76+
- **多个队列并行**,避免单个队列成为性能瓶颈。
77+
- **合理使用 TTL(消息过期时间)**,防止积压。
78+
3. **消费者优化**
79+
- **并发消费**,使用多个 Channel 处理消息。
80+
- **预取消息(Prefetch Count)**,减少消费者等待时间:
81+
```sh
82+
channel.basic_qos(prefetch_count=10)
83+
```
84+
85+
### **RabbitMQ 如何处理消息堆积?**
86+
1. **短期优化**
87+
- **增加消费者数量**,提高消费速度。
88+
- **降低生产速率**,避免消息继续堆积。
89+
2. **长期优化**
90+
- **拆分队列**,使用多个队列并行处理不同的消息类型。
91+
- **限流**,RabbitMQ 提供 **prefetch** 机制,防止消费者超载:
92+
```sh
93+
channel.basic_qos(prefetch_count=100)
94+
```
95+
- **增加 RabbitMQ 节点**,进行集群扩展。
96+
97+
# **死信队列(Dead Letter Queue,DLQ)**
98+
99+
死信队列(DLQ)是一个特殊的队列,用于存储无法正常消费的消息。消息进入死信队列通常由以下原因导致:
100+
101+
1. **消息过期**:消息在队列中存活时间超过 TTL(Time-To-Live)后自动进入死信队列。
102+
2. **队列满**:消息无法被消费且队列已满,无法再接收新消息。
103+
3. **消费者拒绝消息**:消费者处理消息失败,且未进行 `ack` 确认。
104+
4. **队列未绑定**:消息发送到的队列无消费者。
105+
106+
死信队列用于后续的故障排查、重试处理或人工干预,防止消息丢失。
107+
108+
109+
110+
### **RabbitMQ 的消息投递模式有哪些?**
111+
RabbitMQ 提供了 4 种常见的消息投递模式:
112+
1. **Direct(直连交换机)**
113+
- 只有 Routing Key 完全匹配的队列才能收到消息。
114+
2. **Fanout(广播模式)**
115+
- 消息发送到交换机后,所有绑定的队列都能收到消息(不需要 Routing Key)。
116+
3. **Topic(主题模式)**
117+
- Routing Key 支持通配符(`*` 表示一个单词,`#` 表示多个单词)。
118+
4. **Headers(头部交换机)**
119+
- 根据消息头部属性(Headers)匹配队列,而不是 Routing Key。
120+
50121
### 模式
51122

52123
[详细的图](http://www.rabbitmq.com/getstarted.html)
@@ -59,3 +130,9 @@ exchange接收到消息后,就根据消息的key和已经设置的binding,
59130
1. direct
60131
2. fanout
61132
3. topic
133+
134+
### 扩容
135+
- 默认不支持自动扩容,手动加节点扩容。
136+
- 可使用Kubernetes,底层通过负载均衡和节点池管理实现扩容。
137+
- 采用 **多个队列**,不同队列存放不同的消息类型。
138+

09消息队列/4Kafka.md

Lines changed: 106 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,90 @@
11
## Kafka
22

3-
[小白也懂](http://www.sohu.com/a/144225753_236714)
3+
#### 架构图
44

5-
[详细原理](https://blog.csdn.net/ychenfeng/article/details/74980531)
5+
![架构图2](https://images2015.cnblogs.com/blog/512650/201611/512650-20161103135336861-18609635.png)
6+
7+
### 1. Kafka 的核心组件有哪些?
8+
- **Producer**:负责将消息发送到 Kafka。
9+
- **Consumer**:从 Kafka 消费消息。
10+
- **Broker**:Kafka 服务器,负责存储消息和处理消息请求。
11+
- **Zookeeper**:用于管理和协调 Kafka 集群(存储元数据、Leader 选举等)。
12+
- **Topic**:消息的类别,Producer 将消息发送到特定的 Topic。
13+
- **Partition**:Topic 被划分为多个 Partition,分布在多个 Broker 上。
14+
- **Consumer Group**:消费者组,允许多个消费者并行消费一个 Topic。
15+
16+
### 2. Kafka 的工作流程是怎样的?
17+
- Producer 生产消息,并将消息写入到指定的 Topic。
18+
- Kafka Broker 将消息存储在 Topic 的 Partition 中。
19+
- Consumer 从 Kafka Broker 读取消息。消费者可以根据 Consumer Group 来划分不同的消费任务。
20+
21+
### 3. Kafka 是如何保证高吞吐量的?
22+
- **分区(Partition)**:消息被分布到多个分区,允许并行处理。
23+
- **顺序写入(Sequential Writes)**:消息按顺序写入磁盘,避免了随机写入的性能瓶颈。
24+
- **批量处理**:Kafka 支持生产者端和消费者端的批量消息发送和消费,减少了 I/O 操作。
25+
- **压缩(Compression)**:Kafka 支持压缩消息,减少了存储和传输的带宽占用。
26+
27+
### 4. Kafka 的存储机制是怎样的?
28+
Kafka 采用顺序写入日志的方式存储消息,每个消息都有一个唯一的 Offset,消息会被持久化到磁盘。Kafka 使用了基于分区的存储方式,消息以分区为单位存储,可以轻松扩展和负载均衡。
29+
30+
### 5. Kafka 的生产者(Producer)和消费者(Consumer)如何交互?
31+
- 生产者将消息发送到 Kafka 的某个 Topic。
32+
- 消费者订阅一个或多个 Topic,拉取消息。
33+
- 消费者在消费时基于消息的 Offset 进行读取,可以选择提交(commit)或不提交(acknowledge)消息的 Offset。
34+
35+
### 6. Kafka 是如何保证消息的顺序性的?
36+
Kafka 保证的是在同一个 Partition 中消息的顺序性。由于每个 Partition 中的消息是顺序写入的,所以消息的顺序在 Partition 内是有保证的。多个消费者组中的消费者之间不保证顺序。
37+
38+
### 7. Kafka 是如何处理消息丢失问题的?
39+
- 每个 Partition 有多个副本,其中一个副本为 Leader,其他为 Follower。
40+
- 消息写入时会写入所有副本(可配置),确保数据的高可靠性。
41+
- 消息的持久化和副本机制保证即使部分 Broker 宕机,消息仍然不会丢失。
42+
43+
### 8. Kafka 是如何实现分区(Partition)的?
44+
Kafka 将 Topic 分为多个 Partition,每个 Partition 可以在不同的 Broker 上。分区的数目可以根据需要进行配置,Partition 的划分使得 Kafka 可以横向扩展,支持高并发。
45+
46+
### 9. Kafka 是如何进行 Leader 选举的?
47+
Kafka 使用 Zookeeper 来进行 Leader 选举。当一个 Partition 的 Leader 宕机时,Zookeeper 会检测到并触发选举,选举一个新的 Broker 来作为该 Partition 的 Leader。
48+
49+
### 11. Kafka 副本(Replica)机制是如何工作的?
50+
每个 Partition 会有多个副本,其中一个副本为 Leader,负责读写操作;其他副本为 Follower,只负责同步数据。副本之间的同步是异步的,但 Kafka 会保证在 Leader 宕机时自动选举出新的 Leader。
51+
52+
### 12. Kafka 的 Zookeeper 作用是什么?可以去掉 Zookeeper 吗?
53+
Zookeeper 在 Kafka 中主要用于:
54+
- 存储元数据(例如 Topic、Partition 的信息)。
55+
- 进行 Broker 的管理和负载均衡。
56+
- 进行 Leader 选举。
57+
58+
Kafka 在 2.8 版本引入了 KRaft 模式(Kafka Raft Metadata Mode),逐步去除 Zookeeper,实现了更加简化和高效的架构。
59+
60+
### 14. Kafka 为什么比传统消息队列(RabbitMQ、ActiveMQ)快?
61+
Kafka 通过顺序写入、分区机制和批量处理的方式极大地提升了吞吐量,同时 Kafka 适合大规模分布式环境,并且能够高效地处理大量的消息。
62+
63+
### 15. Kafka 生产者端如何优化消息发送?
64+
- **批量发送**:将多条消息打包成一批发送。
65+
- **压缩**:启用压缩算法(如 GZIP、Snappy)减少消息大小。
66+
- **异步发送**:生产者可以异步发送消息,避免等待响应,提高吞吐量。
67+
68+
### 16. Kafka 是如何保证消息不丢失的?
69+
Kafka 通过副本机制和持久化存储来保证消息不丢失。消息写入时,会写入多个副本,确保数据的高可靠性。在消费者消费时,如果消息未被确认,消息可以重新投递。
70+
71+
### 20. Kafka 如何扩容和缩容?
72+
扩容:通过增加新的 Broker 节点并将 Partition 副本分布到新的节点上。
73+
缩容:移除 Broker 后,调整 Partition 副本的分布,确保不会丢失数据。
74+
75+
76+
### 21. Kafka 发生 Leader 选举时会有哪些影响?
77+
在发生 Leader 选举时,该 Partition 会暂时无法进行读写操作,直到新的 Leader 被选举出来并恢复服务。
78+
79+
### 22. 在 Kafka 中如何设计一个高可用、高吞吐的消息系统?
80+
- 配置多个 Partition 和副本,以确保高并发和容错能力。
81+
- 使用合适的生产者和消费者配置(如批量处理、压缩、异步等)。
82+
- 配置合理的消息过期时间,避免消息积压。
83+
- 使用合理的消息存储和清理策略。
684

7-
[深入研究](https://www.cnblogs.com/xifenglou/p/7251112.html)
885

9-
#### 架构图
1086

11-
![架构图1](http://www.uml.org.cn/bigdata/images/2017072521.png)
1287

13-
![架构图2](https://images2015.cnblogs.com/blog/512650/201611/512650-20161103135336861-18609635.png)
1488

1589
#### 概念
1690

@@ -77,6 +151,32 @@ kafka保证消息被安全生产, 通过request.required.acks属性进行配置:
77151

78152
kafka在所有broker中选出一个controller,所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式(比Zookeeper Queue的方式更高效)通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配
79153

154+
15. 消费
155+
- 一个消费组,下面可以有多个消费者,策略(如:轮询)消费不同分区数据。
156+
- 多个消费组,每组都可以消费同样的topic下的全部数据。
157+
158+
### **如何优化 Kafka 的性能?**
159+
1. **优化生产者**
160+
- **批量发送**`batch.size` 调大)
161+
- **压缩消息**`compression.type` 设置为 `snappy`
162+
- **异步发送**`acks=1``acks=0` 提高吞吐)
163+
2. **优化 Broker**
164+
- **增加分区数**`num.partitions`
165+
- **副本异步刷盘**`unclean.leader.election.enable=true`
166+
3. **优化消费者**
167+
- **多线程消费**`poll()` 处理更多数据)
168+
- **手动提交偏移量**(避免重复消费)
169+
170+
16. 如何观察 Kafka 负载变化
171+
```shell
172+
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID
173+
my-consumer-group my-topic 0 1000 1100 100 consumer-1
174+
my-consumer-group my-topic 1 950 1050 100 consumer-2
175+
176+
```
177+
- LAG(Log Append Gap)=最新的 Log End Offset−当前消费的 Offset。
178+
- PARTITION 列表:如果增加了新的分区,消费者会自动负载均衡。
179+
- LAG 值:表示未消费的消息量,若 LAG 过大,说明消费速度跟不上生产速度。
80180

81181

82182

0 commit comments

Comments
 (0)