RocketMQ 批处置模型演进之路 Apache
RocketMQ 的指标，是努力于打造一个信息、事情、流一体的超融合处置平台。这象征着它要求满足各个场景下各式各样的要求，而批量处置则是流计算畛域关于极致吞吐量要求的经典解法，这当然也象征着 RocketMQ 也有一套属于自己格调的批处置模型。
至于什么样的批量模型才叫“属于自己格调”呢，且听我娓娓道来。
批处置的外围现实是将多个义务或数据汇合在一同，启动一致处置。这种方法的好处在于可以充沛应用系统资源，缩小义务切换带来的开支，从而提高全体效率。比如在工业制作中，工厂通常会将相反类型的零部件批量消费，以降低消费老本和提高消费速度。在互联网畛域，批处置则表现为批量数据的存储、传输和处置，以优化性能和优化系统吞吐量。
批处置在极致吞吐量需求下的运行，愈加清楚。例如，在大数据剖析中，海量的数据要求集中处置才干得出无心义的结果。假设逐条处置数据，不只效率低下，还或许形成系统瓶颈。经过批处置，可以将数据划分为若干批次，在预约的时期窗口内一致处置，从而提高系统的并行处置才干，优化全体吞吐量。
此外，批处置其实并不象征着就义延时，就比如在 CPU Cache中，对单个字节的操作无论如何时期上都是会优于多个字节，但是这样的比拟并没无心义，由于延时的感知并不是无量小的，用户经常并不关心 CPU口头一条指令要求花多长时期，而是口头完单个“义务/作业”要求多久，在微观的概念上，反而批处置具有更低的延时。
下图，是作为用户视角上感知比拟强的老三样，区分是 Producer、Consumer、Broker：
而早期批处置模型，实践上只和 Producer、Broker 无关，在这条链路上会有批量信息的概念，当信息抵达 Broker 后这个概念就会隐没。
基于这点咱们来看详细是怎样回事。首先批量信息的源头实践上就是 Producer 端的 Send 接口，在大局部场景下，咱们发送一条信息都会经常使用以下的方式去操作：
SendResult send(Message msg);十分地扼要简要，将一条信息发送到 Broker，假设咱们要经常使用上早期的批处置模型，也只要要稍作修正：
SendResult send(Collection<Message> msgs)可以看到，将多条信息串成一个汇合，而后照旧是调用 send 接口，就可以成功早期批处置模型的经常使用了（从用户侧视角看就曾经 ok 了），就像下图一样，两军交兵，谁火力更猛上下立判～
那么真就到此为止了吗？当然不是，首先这里的汇合是有考究的，并不是轻易将多条信息放在一同，就可以 send 进来的，它要求满足一些解放条件：
这些解放条件临时先不开展，由于就似乎它字面意思一样艰深易懂，但是这也象征着它的经常使用并不是为所欲为的，有肯定的学习老本，也有肯定的开发要求，经常使用前要求依据这些解放条件自行分类，而后再装进“大炮”中点火发射。
这里或许有人会问，这不是尴尬我胖虎吗？为什么要加这么多解放？是不是故意的？实践上并非如此，咱们可以构想一下，假设咱们是商家：
很显然，第二个场景很或许会收到快递小哥一个大大的白眼，这种事道理所应当的做不了，这也是为什么属于同一个 Collection<Message> 的信息肯定要满足各种各样的解放条件了，在 Broker 实践收到一个“批量信息”时，会做以下处置：
首先它会依据这一批信息的某些属性，筛选出对应的队列，也就是上图中最底下的「p1、p2......」，在选定好队列之后，就可以启动后续的写入等操作了，这也是为什么肯定要求相反 Topic，由于不同的 Topic 是没法选定同一个队列的。
接上去就到了上图所示流程，可以看到这里区分来了三个信息，区分是 《四条信息》《一条信息》《三条信息》，接上去他们会依次进入 unPack流程，这个流程有点像序列化环节，由于从客户端发送过去的信息都是内存结构的，距离实践存储在文件系统中的结构还有一些不同。在 unPack环节中，会区分解包成：四条信息、一条信息、三条信息；此时和延续 Send八条信息是没有任何区别的，也就是在这一刻，批量信息的生命周期就走到了止境，此刻往后，“众生对等、不分你我”。
也正是这个机制，Consumer 其实并不知道 Producer发送的时刻“究竟是发射弓箭，还是扑灭大炮”。这么做有个十分好的好处，那就是有着最高的兼容性，一切的一切似乎和单条信息 Send的经典用法没有任何区别，在这种状况下，每条信息都有最高的自在度，例如各自独立的 tag、独立的 keys、惟一的 msgId等等，而基于这些所衍生进去的生态（例如信息轨迹）都是无缝连贯的。也就是说： 只要要改换发送者经常使用的 Send 接口，就可以取得极大的发送性能优化，而消费者端无需任何改动。
首先咱们要有一个共识，那就是关于信息队列这种系统，全体性能下限比值“消费/消费”应该要满足至少大于等于一，由于大局部状况下，咱们的消费进去的信息至少应该被消费一次性（否则间接都不用 Send 了岂不美哉）。
其真实以往，发送性能没有被拔高之前，它就是整个消费到消费链路上的短板，也就是说消费速率可以轻松超越消费速率，整个环节也就十分协调。but！在经常使用早期批处置模型后，消费速率的大幅度优化就泄露了另外一个疑问，也就是会出现消费速率跟不上消费的状况，这种状况下，去谈整个系统的性能都是“无稽之谈”。
而出现消费速率短板的要素，还要从索引构建讲起。由于消费是要找到详细的信息位置，那就肯定依赖于索引，也就是说， 一条信息的索引构建成功之前，是无法被消费到的。 下图就是索引构建流程的繁难图：
这是整个间接选择消费速率下限的流程。经过一个叫 ReputMessageService 的线程，顺序扫描 CommitLog文件，将其宰割为一条一条的信息，再对这些信息启动校验等行为，将其转换成一条条的索引信息，并写入对应分区的 ConsumeQueue 文件。
整个环节是齐全串行的，从宰割信息，到转换索引，到写入文件，每一条信息都要经过这么一次性流转。由于一开局是串行成功，所以变革起来也十分的人造，那就是经过流水线变革，提高它的并发度，这外面有几个要求处置的疑问：
针对这几个难点，在设计中也引入了“批量处置”的思绪，其实大到架构设计、小到成功细节，处处都表现了这一理念，下图就是变革后的流程：
由于 CommitLog扫描环节很难并行化处置，那就罗唆不做并行化变革了，就经常使用复线程去顺序扫描，但是扫描的时刻会启动一个便捷的批处置，扫描进去的信息并不是单条的，而是尽或许凑齐一个较大的 buffer 块，自动是 4MB，这个由多条信息形成的 buffer 块咱们无妨将其称为一个 batch msg。
而后就是对这些 batch msg 启动并行解析，将 batch msg 以单条信息的粒度扫描进去，并构建对应的 DispatchRequest结构，最终依次落盘到 ConsumeQueue 文件中。其中的关键点在于 batch msg 的顺序如何保障，以及DispatchRequest 在流转时怎样保障顺序和效率。为此我专门成功了一个轻量级的队列 DispatchRequestOrderlyQueue，这个 Queue 驳回环状结构，可以随着顺序标号始终递进，并且能做到 “无序入队，有序出队” ，详细设计和成功均在开源 RocketMQ 仓库中，这里就不多赘述。
在经过变革后，索引构建流程不再成为扯后腿的一员，从原本眼中钉的角色美美隐身了～
但是这并不够！由于早期的模型出于兼容性等思索，所以照旧束手束脚的，于是 BatchCQ 模型降生了，重要要素分为两个维度：
那 BatchCQ 又是如何改良上述的疑问的呢？其实也十分地直观，那就是“见字如面”，将 ConsumeQueue 也批量化。这个模型去掉 Broker 端写入前的解包行为，索引也只启动一次性构建：
// 发送端开启 AutoBatch 才干rmqProducer.setAutoBatch(true);
