RocketMQ整个流程

1.发送消息，producer会在本地缓存的broker列表里面获取一个broker，如果没有，那就会去namesrv获取broker的地址，然后发
送消息到broker。
2.broker接受到消息后，会进行一系列检查，然后把收到的消息，存入到commitLog当中，然后进行刷盘，如果是同步的刷盘策略
，那么就会在写入到pageCache中时，再真正落地到磁盘的时候才会进行response的返回，如果是异步的话，那么会在写入
pageCache中时即可返回response，然后累计一定量的消息的时候才会持久化，相应的，异步的策略的效率更高了，可是带来的就
是风险性的评估，那么这个时候选择就需要根据实际情况来考虑问题了。
3.后台有一个线程ReputMessageService一直在查看commitLog的偏移量，如果commitLog的写入偏移了，那么这个时候就会把消息
的长度，id，起始位置等传送给consumeQueue，和index（index就是索引，根据topic和id得到相应msg的位置）。
4.consumer端消费，有两种模式，push和pull模式，其实都是基于pull来做的，PullMessageProcessor里面是相应的逻辑处理，大
致的处理流程：系统能够知道每个consumeQueue现在读取到的位置，如果没有消息未读取的话，就会阻塞response，默认20s。当
有消息的时候，先会去读取consumeQueue，然后读取出消息的起始位置等，然后去commitLog读取消息，并且修改commitLog中的消
息的读取次数等，消费者接着处理业务逻辑，然后返回给broker相应的结果，如果消费成功，那么修改consumeQueue的消费的位置
（不一定刷盘，所以需要保证业务端幂等）。如果消费失败，那么普通消息就会进入到重试队列，（类似于延时队列）进行重试，
达到一定重试次数之后仍然失败，那么就会放入到死信队列当中，这个时候需要人工介入（例如这个时候，可以在这个地方进行源
码的二次开发，或者注册监听器，当有消息放入死信队列的时候就发送提醒）。