滚动公告数据库怎么设计？数据库设计原则与规范

在构建高并发、实时性要求极高的滚动公告系统时，数据库设计是决定系统性能与稳定性的基石，传统的单表结构往往难以兼顾海量数据的存储效率与高频查询的响应速度，因此需要采用分层存储、冷热分离以及索引优化相结合的策略。

核心数据模型设计

滚动公告通常包含基础信息、展示配置、状态控制以及统计指标，为了支持灵活的展示规则（如按用户标签展示、按时间段展示），我们需要将公告数据与展示规则解耦。

公告主表 (announcement_main)

该表存储公告的核心元数据,是系统的主数据源。

字段名	类型	约束	说明
id	BIGINT	PK, AUTO_INCREMENT	公告唯一标识
content	TEXT	NOT NULL	公告正文内容
type	TINYINT	NOT NULL	公告类型（1:普通, 2:紧急, 3:营销）
status	TINYINT	NOT NULL	状态（0:草稿, 1:待审核, 2:已发布, 3:已下线）
priority	INT	DEFAULT 0	优先级，数值越大越靠前
start_time	DATETIME	NOT NULL	生效开始时间
end_time	DATETIME	NOT NULL	生效结束时间
created_at	DATETIME	DEFAULT CURRENT_TIMESTAMP	创建时间
updated_at	DATETIME	DEFAULT CURRENT_TIMESTAMP ON UPDATE	更新时间

公告展示规则表 (announcement_rule)

为了支持精细化运营,如“仅对VIP用户展示”或“仅对特定地区展示”，需将规则独立存储，避免主表字段膨胀。

字段名	类型	约束	说明
id	BIGINT	PK, AUTO_INCREMENT	规则ID
announcement_id	BIGINT	FK, NOT NULL	关联公告ID
rule_type	VARCHAR(50)	NOT NULL	规则类型（user_tag, region, device_type）
rule_value	VARCHAR(255)	NOT NULL	规则值（如 “vip”, “beijing”, “ios”）
match_logic	TINYINT	DEFAULT 1	匹配逻辑（1:包含, 2:排除）

公告阅读记录表 (announcement_read_log)

用于统计用户是否已读,避免重复推送或展示已读标记，由于数据量极大，此表需考虑分表策略。

滚动公告系统的核心痛点在于“实时查询”与“批量推送”，如果直接扫描主表，随着数据积累，查询效率会急剧下降。

复合索引设计：
在 announcement_main 表中，最频繁的查询场景是“获取当前生效且未下线的公告”，必须建立复合索引：
```
CREATE INDEX idx_status_time_priority ON announcement_main (status, end_time, priority DESC);
```
该索引能确保数据库通过索引快速定位到 status=2（已发布）且 end_time > NOW() 的记录，并按优先级降序排列，避免文件排序（Filesort）。
读写分离与缓存层：
公告数据具有“写少读多”的特性，建议在应用层引入 Redis 缓存。
- Key设计：announcement:active:list
- 数据结构：使用 Sorted Set (ZSET)，Member 为公告 ID，Score 为优先级或时间戳。
- 更新策略：当公告状态变更或上下线时，异步更新 Redis 缓存，确保查询接口直接命中缓存，响应时间控制在毫秒级。
冷热数据分离：
对于历史公告，查询频率极低，可以定期将 end_time 早于当前时间超过一定阈值（如30天）的数据迁移至历史表或归档存储（如 Elasticsearch 或 HDFS），主表仅保留近期活跃数据，保持主表轻量化。

在分布式环境下,公告的发布与下线需要保证最终一致性。

状态机控制：公告状态流转应严格遵循状态机（草稿 -> 待审核 -> 已发布 -> 已下线），禁止非法跳跃。
分布式锁：在批量更新公告状态或执行定时任务（如自动下线）时，需使用分布式锁（如 Redis SETNX 或 ZooKeeper）防止重复执行。
消息队列解耦：公告发布成功后，发送消息至消息队列（如 Kafka/RabbitMQ），由消费者异步执行缓存刷新、推送通知生成等耗时操作，避免阻塞主业务流程。

滚动公告数据库怎么设计？数据库设计原则与规范