简述RocketMQ持久化机制
- commitLog:日志数据文件，被所有的queue共享，大小为1G，写满之后重新生成，顺序写
- consumeQueue:逻辑queue，消息先到达commitLog、然后异步转发到consumeQueue，包含queue 在 CommitLog 中的物理位置偏移量Offset，消息实体内容的大小和Message Tag 的hash值。大小约为600W个字节，写满之后重新生成，顺序写
- indexFile:通过key或者时间区间来查找CommitLog中的消息，文件名以创建的时间戳命名，固定的单个 IndexFile大小为400M，可以保存2000W个索引 所有队列共用一个日志数据文件，避免了kafka的分区数过多、日志文件过多导致磁盘IO读写压力较大造成性能瓶颈，
rocketmq的queue只存储少量数据、更加轻量化，对于磁盘的访问是串行化避免磁盘竞争，缺点在于:写入是顺序写，但读是随机的，先读ConsumeQueue，再读CommitLog，会降低消息读的效率
整体过程
- 消息发送到broker后，会被写入commitLog，写之前加锁，保证顺序写入。然后转发到consumeQueue
- 消息消费时先从consumeQueue读取消息在CommitLog中的起始物理偏移量Offset，消息大小、和消息Tag的 HashCode值。在从CommitLog读取消息内容
- 同步刷盘，消息持久化到磁盘才会给生产者返回ack，可以保证消息可靠、但是会影响性能
- 异步刷盘，消息写入pageCache就会返回ack给生产者，刷盘采用异步线程，降低读写延迟提高性能和吞吐
