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

需求分析

设计消息队列存储消息数据的 MySQL 表格：

1. 包括表名、字段、索引；

2. 用文字描述设计思路和理由，例如：为什么设计某个索引？

3. 需要考虑每个消息队列一张表，还是所有消息放一张表，里面加一个“队列名称”的字段。

设计思路

使用关系型数据库，消息部分的持久化存储内容主要包括 Topic，Message，其它的还有 Queue，ConsumerGroup。这里重点讨论前两者。

Topic

主题，每个 topic 对应一个“消息队列”，每个“消息队列” 采用一张表单独存储。基于几方面考虑：

• 性能，如果消息太多，则单表数据太多，会对整体性能有影响，主要是查询和更新；

• 隔离，如果某一个 topic 的消息太多，导致表数据太多，会影响其它的 topic；

• 可用性，同样的，如果某个 topic 有问题不会影响到其它的 topic；

• 诊断 & 维护，有利于诊断问题和维护，缩小范围。

Message

消息，消息主要包括标签，消息 ID、Key、消息内容、消息类别、生产者相关（IP+端口，状态，生产时间）、消费者相关（IP+端口，状态，消费时间，重试消费次数），队列 ID（参考下面 Queue 的说明）。

标签，相当于 Topic 的子分类。以电商交易为例，过程中会有订单消息、支付消息、物流消息，Topic 可定义为 Trade_Topic，标签则可定义为：order、pay、logistics。

消息类别，分为普通消息、分区顺序消息、全局顺序消息、事务消息、定时/延时消息。

索引，一般来说需要对 Topic、Message ID 和 Message Key 做查询。现在一个 Topic 一个表，查询 Topic 就可以直接定位到具体的表做查询。Message ID 和 Message Key 各自对对应的字段创建索引即可。

ConsumerGroup

消息者组，同一个消费者组订阅同一个 Topic，实现负载均衡和容错。

Queue

队列，为了能够并行生产和消费，需要引入 Queue，每个 Topic 包含 1~多个 Queue，Topic 的消息分散这些 Queue 里面。

消息表设计

表名：message_xxx(xxx 指主题名称）

索引：id 既是主键，也是索引，用于位移查询。

消费表设计

表名：message_consumer_xxx(xxx 指主题名称）

索引：consumerid，consumer_time 和 msg_id 建立联合索引