kafka深入系列-业界消息中间件设计方案

目标：可靠性（保证消息不丢失）、异步、解耦（无需同时在线、不需要知道对方是谁）。

数据的存储级别：内存中的数据（断电丢数据）===》持久化磁盘（磁盘损坏）===》冗余备份（一致性问题）

 

一、业界MQ架构

1、Notify架构图

特点：

• Notify之间不互相通讯。

• 支持水平扩展。

• 客户端通过Config Server获得Notify地址列表。

• 客户端自动感知Notify的增加或减少。

• 发布者、消费者、Notify Server都支持集群。

• 消息根据不同的安全级别选择存放到不同的地方（如：File、Oracle、Mysql），然后放在内存中提高性能。

• 推模式

 

2、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需要写的代码很复杂，而且一些高级特性不方便支持。

 

二、存储模型

1、文件存储：顺序读写。

2、关系型数据库：提供良好的信息条件检索能力，缺点：容量和性能太差，难以满足大吞吐量。

3、NoSQL存储：支持一级索引，具备良好的线性扩容能力，大多数NoSQL存储具备数据容灾能力。