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 获取服务节点信息和元数据消息。
评论