RocketMQ 架构原理

注册中心

注册中心使用得nameserver, nameserver不会进行频繁的读写，所以整体的性能开销小，稳定性也高。
注册中心没隔10s会扫描一次所有的broker，如果2min没有发送心跳过来，就人为挂了，断开连接。此时会更新topic与队列的对应关系，但不会通知producer和consumer

Broker 架构

broker通常以集群的形式运行，存储producer发来的消息。

与注册中心的交互

每个broker和所有注册中心保持长连接
每30s向注册中心发送心跳，心跳里面有自身的topic信息

负载均衡设计

broker与topic 是多对多的设计

高可用设计

主从结构，master负责消息的写入，slave负责消息的读取

整个broker都挂了，最多30s内所有发往这个消息和消费这个消息的都会失败，等到master起来后，重新同步

高可靠设计

所有的消息都会通过同步刷盘和异步刷盘的方式保存在磁盘上，可靠性很高
同步刷盘：写入成功才算成功
异步刷盘：服务器宕机才算成功，概率比较小

读写性能

零拷贝方式，减少用户态和内核态的多次切换

消费者架构

consumer会与注册中心保持长连接，定期查询MQ的topic配置信息，如果前注册中心的服务器宕机，consumer自动与下一台服务器连接。
consumer每30s获取一次配置中心的所有topic配置信息，如果某个broker宕机，最多30s就能够感知到

consumer与broker之间保持长连接
consumer每隔30s与关联的broker发送心跳，broker每10s扫描所有的长连接，如果2min没有发送心跳数据，则关闭连接，并通知其他消费者

生产者架构

一个Producer与注册中心的一台服务器保持长连接，并且会定时查询MQ的Topic配置信息，如果当前注册中心的服务器宕机，Producer会自动与下一台服务器连接

在保持长连接的情况下，Producer每30s获取一次配置中心的所有Topic的最新队列情况，如果某个Broker宕机，Producer最多需要30s可以从配置中心感知到（如果写入消息多次失败也可以感知到）

Producer及与之关联的Broker之间保持长连接
Producer默认每隔30s向与之关联的Broker发送心跳；Broker每10s扫描所有的长连接，如果某个连接2min内没有发送心跳数据，则关闭连接