消息队列总结 - Rockianst

1.RabbiMQ

在公司业务实际使用中发现以下问题

同步发送
- 业务代码一版采用queue处理可异步执行的非核心业务，但是业务代码大多数情况下投递消息都使用同步接口，可能会阻塞整个请求。
连接block问题：

内存达到一定比例后会阻塞生产者继续发送消息
Rabbimq积压，Rabbimq io过高都会引起消息投递block

使用上
- 发没发不知道，发了什么内容不知道（除非业务代码打印日志），无法追溯
消息丢失问题
- 项目中很多Queue的属性配置是写在代码中，一旦选择错误，则在某些场景会造成消息丢失。
- Queue属性 - durable/transient transient消息存在内存中，如果Rabbimq重启则消息丢失。
- 没有启用confirm机制，消息有没有正确的投递到队列中不能保证。
- exchange没有绑定queue或绑定不对
- queue所在节点挂了，用户无感知

2.Kafka

1.支持积压大量消息

2.自动容灾，高可用

3.单实例partition/topic过多会导致吞吐下降

4.适合大吞吐业务（比如用于日志采集），不适合小吞吐业务（资源浪费）

注意点kafka的每个partition都会生成一份commitlog，一个broker上会存在N个topic，所以Kafka的topic数量不能过多。否则会导致pageCache命中率变低，影响吞吐性能。

3.RocketMQ

a.消息存取

所有的producer投递的message都会写到统一的一个commitlog中，默认1G,当commitlog写满会根据规则再生成一个commitlog。

RocketMQ底层对CommitLog、ConsumeQueue之类的磁盘文件的读写操作，基本上都会采用mmap技术来实现。如果具体到代码层面，就是基于JDK NIO包下的MappedByteBuffer的map()函数来实现，将一个磁盘文件（比如一个CommitLog文件，或者是一个ConsumeQueue文件）映射到内存里来。省去一次用户态到内核态的拷贝损耗。详细可见：https://blog.csdn.net/qq_42046105/article/details/104218193

rocketmq中会有一个异步线程为commitlog建立索引，通过建立类似索引文件—ConsumeQueue的方式来区分不同Topic下面的不同MessageQueue的消息。

消费者消费时，会先从consumer offset manager中查找offset，找到messageQueue文件，然后在messageQueue文件中读取持久化消息的起始物理位置偏移量offset、大小size和消息Tag的HashCode值，随后再从CommitLog中进行读取待拉取消费消息的真正实体内容部分。