RocketMQ原理—4.消息读写的性能优化

大纲

1.Producer基于队列的消息分发机制

2.Producer基于Hash的有序消息分发

3.Broker如何实现高并发消息数据写入

4.RocketMQ读写队列的运作原理分析

5.Consumer拉取消息的流程原理分析

6.ConsumeQueue的随机位置读取需求分析

7.ConsumeQueue的物理存储结构设计

8.ConsumeQueue如何实现高性能消息读取

9.CommitLog基于内存的高并发写入优化

10.Broker数据丢失场景以及解决方案

11.PageCache内存高并发读写问题分析

12.基于JVM OffHeap的内存读写分离机制

13.JVM OffHeap + PageCache的数据丢失问题

14.ConsumeQueue异步写入失败的恢复机制

15.Broker写入与读取流程性能优化总结

1.Producer基于队列的消息分发机制

(1)消息是如何发送到Broker去的

(2)消息发送失败会如何处理

(3)发送消息时有哪些高阶特性可以使用

(1)消息是如何发送到Broker去的

Producer发送消息时需要指定一个Topic，需要知道Topic里有哪些Queue，以及这些Queue分别分布在哪些Broker上。因此，Producer发送消息到Broker的流程如下：

首先，Producer会从NameServer中拉取Topic的路由信息，然后缓存本地的Topic缓存中，并每隔30s进行刷新。

然后，Producer会对获取到的Topic的Queues进行负载均衡，选择其中的一个Queue并找出对应的Broker主节点。

最后，Producer才会与这个Broker的主节点进行通信并发送消息过去。

(2)消息发送失败会如何处理

如果Producer往Broker的主节点写入消息失败，那么就会执行重试——重新选择一个Queue和Broker主节点。此外，故障的Broker在一段时间内也不会再次被选中。这就是重试机制 + 故障退避机制。

Broker故障的延迟感知机制：Broker故障后，虽然NameServer会通过心跳 + 定时任务可以感知并摘除掉它，但该故障的Broker信息无需实时通知Producer。通过Producer端的重试机制 + 故障退避机制，就可以让Broker故障时也能做到高可用。

(3)发送消息时有哪些高阶特性可以使用

按照Key进行Hash，比如让orderId相同的消息都进入同一个Queue里，以保证它们的顺序性。

2.Producer基于Hash的有序消息分发

一个Topic会有很多个Queue，这些Queue会落到各个Broker上。默认情况下，Producer往一个Topic写入的数据，会均匀地分散到各个Broker的各个Queue里。所以各个Broker的各个Queue里都会有一些Producer的数据。

那么发送到Topic里的数据，是否是有顺序的？其实一个Queue就代表了一个队列，当消息进入到同一个Queue时，这些同一个Queue里的消息便是有顺序的，但是不同的Queue之间的消息则是没有顺序的。

如果需要让某一类数据有一定的特殊顺序性，比如同样orderId对应的多条消息(下单->支付->发券)是有顺序的，那么唯一的选择就是让同样orderId对应的所有消息都进入同一个Queue，并保证它们在同一个Queue里是有顺序的。

具体的做法就是：根据消息的某个字段值对应的Hash值，对Queue的数量进行取模，按取模结果来选择Queue。从而实现同样的字段值对应同样的Queue，由此来实现顺序性。

3.Broker如何实现高并发消息数据写入

(1)数据持久化

(2)磁盘的随机写和顺序写

(3)内存的随机写和顺序写

(4)RocketMQ的消息写入

写消息的方式有两种：一是随机写，二是顺序写。写消息的落地有两种：一是内存，二是磁盘。

(1)数据持久化

一般来说，如果要持久化保存写入的消息数据，消息必须要落地到磁盘。如果消息只落地到内存，为了避免内存里的数据丢失，此时就需要设计一套避