8 设计消息队列存储消息数据的 MySQL

背景

实现消息队列，使用 mysql 数据库存储消息，基于 zookeeper 实现服务发现和高可用。

设计

一个 DataNode 中有多个 partition，一个 Topic 有一个或多个队列。

存储使用 mysql 作为底层消息存储，对应到数据库中，一个 DataNode 对应一个 MySql 数据库，Partition 对应一个数据库表，利用数据库成熟的主备实现高可用。

生产者向 parttion 中写入消息，消费者拉取进行消费，写入消息就用最简单的负载均衡算法实现，消息拉取方式用两种，push 和 pull 两种，消费者主动 pull 的模式更简单，可以快速实现。

数据库设计

元数据设计

元数据设计主要是存储了各个角色质检的关系，通过元数据可以找到那个 partition 存在哪个 DataNode 上，拉取数据应该去哪个 DataNode 上拉取；不同 Consumer 对不同的 partition 具有不同的 ConsumerOffset，通过获得 ConsumerOffset 知道当前消费到哪了。

Topic 与 Partition 之间是 1 对多的关系，记录一个 topic 和哪些 parttion 相关联

DataNode 与 Partition 之间是 1 对多的关系，记录一个 dataNode 存储了哪些 partition.

Partition 与 ConsumerOffset 之间是 1 对多的关系，记录一个 Partition 和哪些.ConsumerOffset 有关联

ConsumerOffset 与 Consumer 之间又形成多对一的关系。

以下只对 partition 数据表进行设计

partition 对应一个数据表，表设如下

tableName 设计为：dataNode_{topicname}_{partionindex}，topicname 为这个 partion 对应的主题，partionindex 为这个 topic 下的 partition 编号，编号从 0 开始。

id: 数据库自增字段

biz_id: 业务 id,全局唯一

msg：队列消息主体

create_time: 消息创建时间

producerId: 生产者 id

索引设计

id 作为主键索引，通过 ConsumerOffset 快速找到 id 进行数据拉取

biz_id 不设置之索引，避免插入时效率不高

总体架构

produce 和 Consumer 通过 SDK 从 Broker 进行数据拉取，consumer 消费消息之后通过 broker 将消费偏移量存入到 Metadata 区，通过 Admini 权限进行元数据管理;

使用 mysql 自带稳定的主备方式实现 Broker 高可用，

基于 zookeeper 实现服务发现；定时将 Metadata 元数据存入到 zookeeper，produce 和 Consumer 从 zookeeper 获取服务节点信息和元数据消息。