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

•需要存储的消息

从模块三了解到需要存储“游戏新版本发布”、“玩家充钱”、“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 张表是消费方消费消息日志表，建立组合索引（时间戳、消费方系统），便于查日志。