架构设计流程四步曲

1 场景设定

2 架构设计第 1 步：识别复杂度

架构设计的本质目的是为了解决软件系统的复杂性，所以在设计架构时，首先就要分析系统的复杂性。

消息队列是否需要高性能

消息队列是否需要高可用性

消息队列是否需要高可扩展性

3 架构设计第 2 步：设计备选方案

1. 备选方案 1：采用开源的 Kafka

2. 备选方案 2：集群 + MySQL 存储

具体方案：

简单描述一下方案：

• 采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据。
• 每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步。
• 正常情况下，分组内的主服务器对外提供消息写入和消息读取服务，备服务器不对外提供服务；主服务器宕机的情况下，备服务器对外提供消息读取的服务。
• 客户端采取轮询的策略写入和读取消息。

3. 备选方案 3：集群 + 自研存储方案

4 架构设计第 3 步：评估和选择备选方案

5 架构设计第 4 步：详细方案设计

1. 细化设计点 1：数据库表如何设计？

• 数据库设计两类表，一类是日志表，用于消息写入时快速存储到 MySQL 中；另一类是消息表，每个消息队列一张表。
• 业务系统发布消息时，首先写入到日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。
• 业务系统读取消息时，从消息表中读取。
• 日志表表名为 MQ_LOG，包含的字段：日志 ID、发布者信息、发布时间、队列名称、消息内容。
• 消息表表名就是队列名称，包含的字段：消息 ID（递增生成）、消息内容、消息发布时间、消息发布者。
• 日志表需要及时清除已经写入消息表的日志数据，消息表最多保存 30 天的消息数据。

2. 细化设计点 2：数据如何复制？

直接采用 MySQL 主从复制即可，只复制消息存储表，不复制日志表。

3. 细化设计点 3：主备服务器如何倒换？

采用 ZooKeeper 来做主备决策，主备服务器都连接到 ZooKeeper 建立自己的节点，主服务器的路径规则为“/MQ/server/ 分区编号 /master”，备机为“/MQ/server/ 分区编号 /slave”，节点类型为 EPHEMERAL。

备机监听主机的节点消息，当发现主服务器节点断连后，备服务器修改自己的状态，对外提供消息读取服务。

4. 细化设计点 4：业务服务器如何写入消息？

• 消息队列系统设计两个角色：生产者和消费者，每个角色都有唯一的名称。
• 消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，SDK 采取轮询算法发起消息写入请求给主服务器。如果某个主服务器无响应或者返回错误，SDK 将发起请求发送到下一台服务器。

5. 细化设计点 5：业务服务器如何读取消息？

• 消息队列系统提供 SDK 供各业务系统调用，SDK 从配置中读取所有消息队列系统的服务器信息，轮流向所有服务器发起消息读取请求。
• 消息队列服务器需要记录每个消费者的消费状态，即当前消费者已经读取到了哪条消息，当收到消息读取请求时，返回下一条未被读取的消息给消费者。

6. 细化设计点 6：业务服务器和消息队列服务器之间的通信协议如何设计？

考虑到消息队列系统后续可能会对接多种不同编程语言编写的系统，为了提升兼容性，传输协议用 TCP，数据格式为 ProtocolBuffer。