【RocketMQ问题总结-2】

RocketMQ 消息持久化

Broker通过底层的Netty服务器获取到一条消息后，会把这条消息的内容写入到一个CommitLog文件里去（一个Broker进程就只有一个CommitLog文件，也就是说这个Broker上所有Topic的消息都会写入这个文件）。
同时，Broker还会异步地把消息写入到ConsumeQueue文件里去，每一个MessageQueue都对应了一个ConsumeQueue文件。
最后，Broker还会异步地把消息写入一个IndexFile文件里，该文件中保存着消息的key以及消息在CommitLog中的offset偏移量（会自动关联并建立索引），这样后续如果要查询消息，只需要根据消息key从IndexFile中索引出偏移量，就可以立刻在CommitLog文件中找到消息了。
RocketMQ正式通过磁盘文件顺序写+OS PageCache写入+OS异步刷盘的策略来保证消息写入的性能。
在上述这种异步刷盘的模式下，Producer将消息发送给Broker，Broker将消息写入OS PageCache中，就会直接返回ACK给生产者，生产者收到ACK消息就认为写入成功了。
有异步刷盘就有同步刷盘，同步刷盘主要的不同点就是，只有Broker强制把这条消息刷入底层的磁盘文件后，才会返回ACK给生产者。
在异步刷盘的模式下，如果Broker将消息写入PageCahe并响应给生产者后突然宕机，此时消息在缓存中没有写入底层的磁盘文件，就会造成消息丢失——生产者认为发送成功，实际上消息写入失败。

MQ中的零拷贝应用

用户应用进程调用read函数，向操作系统发起IO调用，上下文从用户态转为内核态(切换1)
DMA控制器把数据从磁盘中，读取到内核缓冲区。
CPU把内核缓冲区数据，拷贝到用户应用缓冲区，上下文从内核态转为用户态(切换2)，read函数返回
用户应用进程通过write函数，发起IO调用，上下文从用户态转为内核态(切换3)
CPU将应用缓冲区中的数据，拷贝到socket缓冲区
DMA控制器把数据从socket缓冲区，拷贝到网卡设备，上下文从内核态切换回用户态(切换4)，write函数返回