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

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

【作业要求】

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

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

3. 一页 PPT 即可。

【提示】

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

设计思路

使用关系数据库，消息部分的持久化存储内容主要包括 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 里面。

表设计

根据要求，只列出与消息数据直接相关的 Topic、Message 表。

Topic 表

id, 自增 ID，主键索引

topic, 主题

description 描述

create_time 创建时间

Message 表

id, 自增 ID，主键索引

tag, 标签

message_id, 消息 ID

message_key, 消息 Key

message_type, 消息类别

message_body, 消息内容

queue_id, 队列 ID

producer_addr, 生产者地址

producer_status, 生产者状态（发送成功、提交成功，回滚，未知）

produce_time, 生产时间

consumer_addr, 消费者地址

consumer_status, 消费者状态（消费成功，消费超时，消费异常，返回 NULL，消费失败）

consume_time 消费时间

reconsume_times, 重试消费次数

Message 表索引

消息 ID 做唯一索引，索引字段：message_id；

消息 Key 做非聚簇索引，索引字段：message_key；