网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
// 1. 创建消费者(Push)对象
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“GROUP_TEST”);
---
### 如何保证消息的顺序消费
首先多个 queue 只能保证单个 queue 里的顺序,queue 是典型的 FIFO,天然顺序。**多个 queue 同时消费是无法绝对保证消息的有序性的**。所以总结如下:
**同一 topic,同一个 QUEUE,发消息的时候一个线程去发送消息,消费的时候 一个线程去消费一个 queue 里的消息。**
追问:怎么保证消息发到同一个 queue ?
Rocket MQ 给我们提供了 MessageQueueSelector 接口,可以自己重写里面的接口,实现自己的算法,举个最简单的例子:判断i % 2 == 0,那就都放到 queue1 里,否则放到 queue2 里。
for (int i = 0; i < 5; i++) {
Message message = new Message(“orderTopic”, (“hello!” + i).getBytes());
producer.send(
// 要发的那条消息
message,
// queue 选择器 ,向 topic中的哪个queue去写消息
new MessageQueueSelector() {
// 手动 选择一个queue
@Override
public MessageQueue select(
// 当前topic 里面包含的所有queue
List mqs,
// 具体要发的那条消息
Message msg,
// 对应到 send() 里的 args,也就是2000前面的那个0
Object arg) {
// 向固定的一个queue里写消息,比如这里就是向第一个queue里写消息
if (Integer.parseInt(arg.toString()) % 2 == 0) {
return mqs.get(0);
} else {
return mqs.get(1);
}
}
},
// 自定义参数:0
// 2000代表2000毫秒超时时间
i, 2000);
}
---
### 消息重复消费
影响消息正常发送和消费的重要原因是网络的不确定性。
引起重复消费的原因
**ACK**
正常情况下在 consumer 真正消费完消息后应该发送 ack,通知 broker 该消息已正常消费,从 queue 中剔除
当 ack 因为网络原因无法发送到 broker,broker 会认为此条消息没有被消费,此后会开启消息重投机制把消息再次投递到 consumer
**消费模式**
在 CLUSTERING 模式下,消息在 broker 中会保证相同 group 的 consumer 消费一次,但是针对不同group 的 consumer 会推送多次
**解决方案**
去重操作直接放在了**消费端**,消费端处理消息的业务逻辑保持幂等性。那么不管来多少条重复消息,可以实现处理的结果都一样。
---
### Broker中的消息被消费后会立即删除吗?
不会,每条消息都会持久化到 CommitLog 中,每个 Consumer 连接到 Broker 后会维持消费进度信息,当有消息消费后只是当前 Consumer 的消费进度(CommitLog的offset)更新了。
追问:那么消息会堆积吗?什么时候清理过期消息?
默认72小时后会删除不再使用的 CommitLog 文件
* 检查这个文件最后访问时间
* 判断是否大于过期时间
* 指定时间删除,默认凌晨4点
---
### 如何保证消息不丢失
首先在如下三个部分都可能会出现丢失消息的情况:
* Producer端
* Broker端
* Consumer端
#### Producer端如何保证消息不丢失
采取 send() 同步发消息,发送结果是同步感知的。
发送失败后可以重试,设置重试次数。默认 3 次。
`producer.setRetryTimesWhenSendFailed(10);`
集群部署,比如发送失败了的原因可能是当前Broker宕机了,重试的时候会发送到其他Broker上。
#### Broker端如何保证消息不丢失
修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。
`flushDiskType = SYNC_FLUSH`
集群部署,主从模式,高可用。
#### Consumer端如何保证消息不丢失
完全消费正常后在进行手动 ack 确认。
---
### 消息堆积如何处理
首先要分析一下消息堆积可能造成的原因
1、如果是机器本身的原因,比如消费者组有几个消费者服务挂掉了,剩下少量消费者消费能力不足导致的消费积压,那就正常重新启动,然后慢慢再去消费积压的消息。
2、如果是生产者端由业务暴增引起的生产过快,而消费者端消费能力不足,这个时候就可以采取**生产者端限流**或者进行**消费者扩容**;这个时候要注意,如果生产者只是短期暴增或者消息的业务不是很重要可以采用限流,如果是长期暴增真正的业务量上涨就必须要进行消费者扩容。
3、如果是消费者挂了,然后 broker 堆积了很多消息,然后可以先把堆积的消息读到别的地方比如 mysql 或者 es 然后去后续进行处理,然后把 RocketMQ 堆积的消息删掉,启动消费者保障消费者正常消费,这里要注意的是删除堆积消息之前,需要停止 mq。
---
### 高吞吐量下如何优化生产者和消费者的性能
开发
同一 group 下,多机部署,并行消费
单个 Consumer 提高消费线程个数
批量消费
消息批量拉取
业务逻辑批量处理
运维
网卡调优
jvm 调优
多线程与 cpu 调优
Page Cache
---
### RocketMQ是如何保证数据的高容错性的?
在不开启容错的情况下,轮询队列进行发送,如果失败了,重试的时候过滤失败的Broker
如果开启了容错策略,会通过RocketMQ的预测机制来预测一个Broker是否可用。
如果上次失败的Broker可用那么还是会选择该Broker的队列
如果上述情况失败,则随机选择一个进行发送
在发送消息的时候会记录一下调用的时间与是否报错,根据该时间去预测broker的可用时间。其实就是send消息的时候queue的选择。
---
### broker 如何处理拉取请求
Consumer 首次请求 Broker:
判断 Broker 中是否有符合条件的消息
* 有
+ 响应Consumer
+ 等待下次 Consumer 的请求
* 没有
+ PullRequestHoldService 来Hold连接,每个5s执行一次检查pullRequestTable有没有消息,有的话立即推送
+ 每隔1ms检查commitLog中是否有新消息,有的话写入到pullRequestTable
+ 当有新消息的时候返回请求
+ 挂起consumer的请求,即不断开连接,也不返回数据使用consumer的offset
---
### RocketMQ 的存储机制
RocketMq采用文件系统进行消息的存储,相对于ActiveMq采用关系型数据库进行存储的方式就更直接,性能更高了
RocketMq与Kafka在写消息与发送消息上,继续沿用了Kafka的这两个方面:顺序写和零拷贝
**1)顺序写**
我们知道,操作系统每次从磁盘读写数据的时候,都需要找到数据在磁盘上的地址,再进行读写。而如果是机械硬盘,寻址需要的时间往往会比较长而一般来说,如果把数据存储在内存上面,少了寻址的过程,性能会好很多;
但Kafka 的数据存储在磁盘上面,依然性能很好,这是为什么呢?
这是因为,Kafka采用的是顺序写,直接追加数据到末尾。实际上,磁盘顺序写的性能极高,在磁盘个数一定,转数一定的情况下,基本和内存速度一致
因此,磁盘的顺序写这一机制,极大地保证了Kafka本身的性能
**2)零拷贝**
比如:读取文件,再用socket发送出去这一过程
buffer = File.read
Socket.send(buffer)
传统方式实现:
先读取、再发送,实际会经过以下四次复制
1、将磁盘文件,读取到操作系统内核缓冲区Read Buffer
2、将内核缓冲区的数据,复制到应用程序缓冲区Application Buffer
3、将应用程序缓冲区Application Buffer中的数据,复制到socket网络发送缓冲区
4、将Socket buffer的数据,复制到网卡,由网卡进行网络传输
![在这里插入图片描述](https://img-blog.csdnimg.cn/f5653c2e112046a7be4b48d0566ab7a9.png)
传统方式,读取磁盘文件并进行网络发送,经过的四次数据copy是非常繁琐的
重新思考传统IO方式,会注意到在读取磁盘文件后,不需要做其他处理,直接用网络发送出去的这种场景下,第二次和第三次数据的复制过程,不仅没有任何帮助,反而带来了巨大的开销。那么这里使用了零拷贝,也就是说,直接由内核缓冲区Read Buffer将数据复制到网卡,省去第二步和第三步的复制。
![img](https://img-blog.csdnimg.cn/img_convert/42fd4f8145e8be6b909dd96b6c98f8f5.png)
![img](https://img-blog.csdnimg.cn/img_convert/52ee98d17b925030781ebfe9a9f0b4a4.png)
![img](https://img-blog.csdnimg.cn/img_convert/a82654bad46deb5cf6d0e4fd582b3e21.png)
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!**
**由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[如果你需要这些资料,可以戳这里获取](https://bbs.csdn.net/topics/618658159)**
中...(img-ujSfeqaq-1715818645707)]
[外链图片转存中...(img-RwDKcXvM-1715818645708)]
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!**
**由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[如果你需要这些资料,可以戳这里获取](https://bbs.csdn.net/topics/618658159)**