写点什么

模块八 设计消息队列存储消息数据的 MySQL 表格

作者:小朱
  • 2022 年 1 月 02 日
  • 本文字数:1122 字

    阅读完需:约 4 分钟

需要存储的消息

从模块三了解到需要存储“游戏新版本发布”、“玩家充钱”、“VIP 升级事件”三类消息。对这三类消息进行分析:“游戏新版本发布”消息要素是:哪种游戏(比如传奇还是王者荣耀还是什么)、哪种新版本,该类消息的消费者是:论坛、包管理子系统、App、Web 站点;“玩家充钱”消息要素是:哪个玩家(比如张三还是李四)、充了多少钱,该类消息的消费者是:VIP 子系统;“VIP”升级事件消息要素是:哪个玩家升级为 VIP,该类消息的消费者是:福利子系统、客服子系统、商品子系统等。


经分析,虽然看上去“每个消息队列一张表”的设计会导致表更多且需设计更多的字段,但是全面来看,“每个消息队列一张表”的设计比“所有消息放一张表”的设计更好,理由如下:1 前者比后者少了“消息内容”的拼装和解析,效率更高;2 前者比后者能更高效地获取到消费方每次请求消费的消息;3 减轻了单表访问(写入、读取、删除)的压力,将单表访问的压力分摊到多张表。

具体的理由分析如下

•如果仅用一张表存储这 3 类消息,则该表中需要设计一个“消息内容”字段存放具体的消息、设计一个“队列名称”字段用于区分消息的类型、设计一个自增的 id 作为主键(也是索引),当然时间戳字段一般也需要的。若采用这样的表设计,则在消息写入前,需要拼装“消息内容”(可以是消息生产者拼装或者是消息队列程序中拼装);在消费者消费消息的时候,需要解析该“消息内容字段”,以便获取上面提到的消息要素,进而进行后续处理。

•另外,消息队列程序需要存储各个消费方消费消息的进度,即当前已经消费的最近的那条消息的 id。采用该种表设计,消费方消费消息时,需要根据目标消息类型查询该表中 id 大于当前 id 且 id 最小的消息。

•如果用 3 张表分别存储这 3 类消息,则每张表可以根据各自的消息要素设计相应的字段,这样消息写入前,不需要“拼装”操作,直接将相应的要素值存入相应的字段即可;消费方读取消息时,也不需要“解析”操作就能获取相应的字段值。

•另外,用 3 张表分别存储这 3 类消息,消费方读取消息时,只要查询消费方消费进度表,将该表中该消费方消费该类消息的 id 加 1,即可得到本次要读取的消息 id,直接根据该消息 id 查询消息表即可返回消息。效率更高。


设计表结构如下

其中前 3 个存储消息的表,主键均为每次自增 1 消息 ID,唯一定位一条消息;索引均为时间戳,便于清理 3 个月之前的消息。第 4 张表“消费方消费信息进度表”的记录数不会太多,记录数为消费方系统个数*消费的消息对列类型(需考虑消费方只消费特定的消息类型),建立组合索引也是唯一索引(消费方系统、消息队列类型),用于修改“已消费最大消息 ID”时唯一定位一条记录。第 5 张表是消费方消费消息日志表,建立组合索引(时间戳、消费方系统),便于查日志。

发布于: 10 分钟前
用户头像

小朱

关注

还未添加个人签名 2021.06.29 加入

还未添加个人简介

评论

发布
暂无评论
模块八 设计消息队列存储消息数据的 MySQL 表格