RocketMQ（Metaq） 架构图

两主两从部署模式：

• Name Server无状态节点，节点之间无任何信息同步。
• Broker与Name Server集群中的 所有节点 建立长连接，定时注册Topic信息到所有Name Server。
• Producer与Name Server中的其中一个节点建立长连接，定期获取Topic路由信息。
• Consumer与Name Server中的其中一个节点建立长连接，定期从NameServer获取Topic路由信息。
• 拉模式

3、Tube架构图

• Tube集群使用了Zookeeper，目前主要用来保存Consumer的消费位置和Master HA的选举（历史遗留问题，全新的Tube系统设计可以摆脱对ZK的依赖）
• Broker向Master汇报自身信息，包括自身id、状态以及提供哪些Topic的发布和订阅服务，每个Topic下包含多少分区。
• 生产者和消费者向Master通报topic信息，返回从哪些Broker获取数据（客户端自己做负载均衡）
• Broker集群节点之间通过心跳和Master保持状态同步，当状态发生变化时，Master会负责通知相关节点。
• Master采用主备模式，通过ZK来进行选举。
• 拉模式

4、Hippo架构图

• 三台controller 一主两备承担整个系统节点数据的采集。（主备controller于心跳检测，在主故障的时候自动failover）
• 三台broker一主两备组成一个组，主broker向controller定期汇报心跳以告知controller当前组的存活状态。（主备broker之间存在心跳，主broker挂掉后，重新选举，shuffle）
• producer与controller之间存在心跳，获取topic所在组的broker组的ip端口机器queue信息。
• consumer与controller之间存在心跳，获取broker组信息列表+同组其他消费者信息列表。
• 限时锁定：消费者拉取某个队列的数据与确认回调之间设置一个超时时间，一旦超时时间还没确定，自动解锁。
• 提供控制台界面，根据当前收集到的正常运行的broker节点信息，可以指定给某个特定的broker组下发topic及queue添加事件。
• 拉模式

5、Herms系统架构

• broker加入/退出，consumer加入/退出，parition的负载均衡。
• metaserver通过zk发现broker ，自己创建路由表，并分配给broker。
• broker定时向meta server定时续lease。（通过zk做协调）
• consumer尽量不直接连接zk，consumer到meta server获取lease。（考虑到consumer量大，不通过zk做协调，直接和metaserver竞争lease）
• 可通过meta server做直接干预（如机器出现问题）。
• 长轮询pull模式，早期使用推模式，broker需要写的代码很复杂，而且一些高级特性不方便支持。