这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。

完整架构

三个月的成长

不知不觉，我在「圈内」已经三个月了。

回想第一天接手通知系统时的问题——推送延迟、重复推送、半夜打扰、没有偏好设置——现在都已经解决了。

完整架构

完整的通知系统分为三层：

业务层：评论服务 / 点赞服务 / 关注服务 / 私信服务
            ↓（业务事件）
通知服务层：通知调度服务（偏好 / 限流 / 聚合）
            ├─ 推送服务（APNs / 厂商推送）
            └─ 站内信服务（存储 / 查询）
            ↓
数据层：MySQL（消息存储）/ Redis（缓存 / 限流）/ RabbitMQ（队列）/ ES（日志）

三层职责

层	职责	关键点
业务层	产生业务事件	不直接发通知，只触发事件
通知服务层	调度、推送、站内信	偏好检查、限流、聚合
数据层	存储、缓存、队列、日志	各司其职

核心数据

设备、消息、未读、偏好各司其职

user_devices

多设备与 token

user_iddevice_tokenplatform / brandlast_active

insite_messages

站内信（分表存储）

message_iduser_id / typecontentis_readdatacreated_at

user_unread_counts

未读计数（独立表）

user_id / typecount

notification_preferences

用户偏好（Redis 缓存）

user_idglobal_enabledcategory_flagsquiet_hours

notifications

待发送通知（旧表，待重构）

id / user_id / contentstatuscreated_at

数据设计要点：保存业务事实，不把规则散落在应用逻辑里；索引服务高频查询，缩小扫描范围而不是堆字段；未读计数用独立表实时更新。

分层设计的意义

业务层不关心通知怎么发：解耦，业务只产生事件。
通知层不关心业务细节：统一处理偏好、限流、聚合。
数据层独立演进：存储、缓存、队列各自扩缩容。

一句话

完整通知系统 = 业务层产生事件 + 通知层调度分发 + 数据层支撑。三层解耦，让「及时、可靠、不打扰」在各自的层内解决。

下一节看关键技术决策。