中间件(五)：Broker底层原理

目录

写在前面

1、生产者往Broker集群发送消息底层原理

1.1、创建Topic的时候为何要指定MessageQueue数量？

1.2、Topic、MessageQueue以及Broker之间到底是什么关系

1.3、生产者发送消息的时候写入哪个MessageQueue？

1.4、如果某个Broker出现故障该怎么办？

 2、Broker是如何持久化存储消息的？

2.1、CommitLog消息顺序写入机制

2.2、如何让消息写入CommitLog文件近乎内存写性能的？

3、基于DLedger技术的Broker 主从同步原理

3.1、基于DLedger技术替换Broker的CommitLog

3.2、DLedger是如何基于Raft协议选举Leader Broker的？

3.3、DLedger是如何基于Raft协议进行多副本同步的？

 3.4、如果Leader Brok

总结

4、消费者是如何获取消息处理以及进行ACK?

4.1、消费者组

4.2、MessageQueue与消费者的关系

4.3、Push和Pull模式

4.4、Broker是如何将消息读取出来返回给消费机器的？

 4.5、消费者机器如何处理消息、进行ACK以及提交消费进度？  

4.6、如果消费组中出现机器宕机或者扩容加机器，会怎么处理？

5、消费者到底是根据什么策略从Master或Slave上拉取消息的

5.1、ConsumeQueue文件也是基于os cache的

5.2、什么时候会从os cache读？什么时候会从磁盘读？

5.3、Master Broker什么时候会让你从Slave Broker拉取数据？

---

写在前面

        目前公司生产环境的情况，就是部署了一个小规模的RocketMQ生产集群，基本都是在稳定运行中，可以支撑公司的核心链路以及秒杀业务，然后有订单系统、大数据系统、库存系统、积分系统等各种公司核心系统都接入了RocketMQ的生产和消费。

• 对生产者往Broker集群发送消息的底层原理做一个研究？
• 看看Broker对于接收到的消息，到底是如何存储到磁盘上去的？
• 基于DLedger技术部署的Broker高可用集群，到底如何进行数据同步的？
• 消费者到底是基于什么策略选择Master或Slave拉取数据的？
• 消费者是如何从Broker拉取消息回来，进行处理以及ACK的？
• 如果消费者故障了会如何处理？

整体分为1、发送；