共计 5673 个字符，预计需要花费 15 分钟才能阅读完成。
本篇主要明确消息通知系统的概念和具体实现，包括数据库设计、技术方案、逻辑关系分析等。消息通知系统是一个比较复杂的系统，这里主要分析站内消息如何设计和实现。
我们常见的消息推送渠道有以下几种：
设备推送
站内推送
短信推送
邮箱推送
我们常见的站内通知有以下几种类别：
公告 Announcement
提醒 Remind
资源订阅提醒「我关注的资源有更新、评论等事件时通知我」
资源发布提醒「我发布的资源有评论、收藏等事件时通知我」
系统提醒「平台会根据一些算法、规则等可能会对你的资源做一些事情，这时你会收到系统通知」
私信 Mailbox
以上三种消息有各自特点，实现也各不相同，其中「提醒」类通知是最复杂的，下面会详细讲。
数据模型设计
公告
公告是指平台发送一条含有具体内容的消息，站内所有用户都能收到这条消息。
方案一：【适合活跃用户在 5 万左右】
公告表「notify_announce」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 公告编号；
senderID: {type: ‘string’, required: true} // 发送者编号，通常为系统管理员；
title: {type: ‘string’, required: true} // 公告标题;
content: {type:’text’, required: true} // 公告内容；
createdAt: {type: ‘timestamp’, required: true} // 发送时间；
用户公告表「notify_announce_user」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 用户公告编号；
announceID: {type: ‘integer’} // 公告编号；
recipientID: {type: ‘string’, required: true} // 接收用户编号；
createdAt：{type: ‘timestamp’, required: true} // 拉取公告时间；
state: {type: ‘integer’, required: true} // 状态，已读 | 未读；
readAt：{type: ‘timestamp’, required: true} // 阅读时间；
平台发布一则公告之后，当用户登录的时候去拉取站内公告并插入 notify_announce_user 表，这样那些很久都没登陆的用户就没必要插入了。「首次拉取，根据用户的注册时间；否则根据 notify_announce_user.createdAt 即上一次拉取的时间节点获取公告」
方案二：【适合活跃用户在百万 - 千万左右】
和方案一雷同，只是需要把 notify_announce_user 表进行哈希分表，需事先生成表：notify_announce_<hash(uid)>。
用户公告表「notify_announce_<hash(uid)>」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 用户公告编号；
announceID: {type: ‘integer’} // 公告编号；
recipientID: {type: ‘string’, required: true} // 接收用户编号；
createdAt：{type: ‘timestamp’, required: true} // 拉取公告时间；
state: {type: ‘integer’, required: true} // 状态，已读 | 未读；
readAt：{type: ‘timestamp’, required: true} // 阅读时间；
提醒
提醒是指「我的资源」或「我关注的资源」有新的动态产生时通知我。提醒的内容无非就是：「someone do something in someone’s something」「谁对一样属于谁的事物做了什么操作」
常见的提醒消息例子，如：XXX 关注了你 –「这则属于资源发布提醒」XXX 喜欢了你的文章《消息通知系统模型设计》–「这则属于资源发布提醒」你喜欢的文章《消息通知系统模型设计》有新的评论 –「这则属于资源订阅提醒」你的文章《消息通知系统模型设计》已被加入专题《系统设计》–「这则属于系统提醒」小明赞同了你的回答 XXXXXXXXX -「这则属于资源发布提醒」
最后一个例子中包含了消息的生产者（小明），消息记录的行为（赞同），行为的对象（你的回答内容）
分析提醒类消息的句子结构：someone = 动作发起者，标记为「sender」do something = 对资源的操作，如：评论、喜欢、关注都属于一个动作，标记为「action」something = 被作用对象，如：一篇文章，文章的评论等，标记为「object」someone’s = 动作的目标对象或目标资源的所有者，标记为「objectOwner」
总结：sender 和 objectOwner 就是网站的用户，object 就是网站资源，可能是一篇文章，一条文章的评论等等。action 就是动作，可以是赞、评论、收藏、关注、捐款等等。
提醒设置
提醒通常是可以在「设置 - 通知」里自定义配置的，用户可以选择性地「订阅」接收和不接收某类通知。
呈现在界面上是这样的：
通知设置
我发布的 publish
文章
被 评论 是 / 否 通知我
被 收藏 是 / 否 通知我
被 点赞 是 / 否 通知我
被 喜欢 是 / 否 通知我
被 捐款 是 / 否 通知我
我订阅的 follow
文章
有 更新 是 / 否 通知我
被 评论 是 / 否 通知我
订阅
一般系统默认是订阅了所有通知的。系统在给用户推送消息的时候必须查询通知「订阅」模块，以获取某一事件提醒消息应该推送到哪些用户。也就是说「事件」和「用户」之间有一个订阅关系。
那么接下来我们分析下「订阅」有哪些关键元素：
比如我发布了一篇文章，那么我会订阅文章《XXX》的评论动作，所以文章《XXX》每被人评论了，就需要发送一则提醒告知我。
分析得出以下关键元素：
订阅者「subscriber」
订阅的对象「object」
订阅的动作「action」
订阅对象和订阅者的关系「objectRelationship」
什么是订阅的目标关系呢？
拿知乎来说，比如我喜欢了一篇文章，我希望我订阅这篇文章的更新、评论动作。那这篇文章和我什么关系？不是所属关系，只是喜欢。
objectRelationship = 我发布的，对应着 actions = [评论，收藏]
objectRelationship = 我喜欢的，对应着 actions = [更新，评论]
讲了那么多，现在来构建「提醒」的数据结构该吧！
提醒表「notify_remind」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 主键；
remindID: {type: ‘string’, required: true} // 通知提醒编号；
senderID: {type: ‘string’, required: true} // 操作者的 ID，三个 0 代表是系统发送的；
senderName: {type: ‘string’, required: true} // 操作者用户名；
senderAction: {type: ‘string’, required: true} // 操作者的动作，如：赞了、评论了、喜欢了、捐款了、收藏了；
objectID: {type: ‘string’, required: true}, // 目标对象 ID；
object: {type: ‘string’, required: false}, // 目标对象内容或简介，比如：文章标题；
objectType: {type: ‘string’, required: true} // 被操作对象类型，如：人、文章、活动、视频等；
recipientID: {type: ‘string’} // 消息接收者；可能是对象的所有者或订阅者；
message: {type: ‘text’, required: true} // 消息内容，由提醒模版生成，需要提前定义；
createdAt：{type: ‘timestamp’, required: true} // 创建时间；
status：{type: ‘integer’, required: false} // 是否阅读，默认未读；
readAt:{type: ‘timestamp’, required: false} // 阅读时间；
假如：特朗普关注了金正恩，以下字段的值是这样的
senderID = 特朗普的 ID
senderName = 特朗普
senderAction = 关注
objectID = 金正恩的 ID
object = 金正恩
objectType = 人
recipientID = 金正恩的 ID
message = 特朗普关注了金正恩
这种情况 objectID 和 recipientID 是一样的。
这里需要特别说下消息模版，模版由「对象」、「动作」和「对象关系」构成唯一性。
通知提醒订阅表「notify_remind_subscribe」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 订阅 ID；
userID: {type: ‘string’, required: true}，// 用户 ID，对应 notify_remind 中的 recipientID；
objectType: {type: ‘string’, required: true} // 资源对象类型，如：文章、评论、视频、活动、用户；
action: {type: ‘string’, required: true} // 资源订阅动作，多个动作逗号分隔如: comment,like,post,update etc.
objectRelationship: {type: ‘string’, required: true} // 用户与资源的关系，用户发布的 published，用户关注的 followed；
createdAt：{type: ‘timestamp’, required: true} // 创建时间；
特别说下「objectRelationship」字段的作用，这个字段用来区分「消息模版」，为什么呢？因为同一个「资源对象」和「动作」会有两类订阅者，一类是该资源的 Owner，另一类是该资源的 Subscriber，这两类人收到的通知消息内容应该是不一样的。
聚合
假如我在抖音上发布了一个短视频，在我不在线的时候，被评论了 1000 遍，当我一上线的时候，应该是收到一千条消息，类似于：「* 评论了你的文章《XXX》」? 还是应该收到一条信息：「有 1000 个人评论了你的文章《XXX》」?
当然是后者更好些，要尽可能少的骚扰用户。
消息推送
是不是感觉有点晕了，还是先上一张消息通知的推送流程图吧：
订阅表一共有两张噢，一张是「通知订阅表」、另一张是用户对资源的「对象订阅表」。具体实现就不多讲了，配合这张图，理解上面讲的应该不会有问题了。
私信
通常私信有这么几种需求：
点到点：用户发给用户的站内信，系统发给用户的站内信。「1:1」
点到多：系统发给多个用户的站内信，接收对象较少，而且接收对象无特殊共性。「1:N」
点到面：系统发给用户组的站内信，接收对象同属于某用户组之类的共同属性。「1:N」
点到全部：系统发给全站用户的站内信，接收对象为全部用户，通常为系统通知。「1:N」
这里主要讲「点到点」的站内信。
私信表「notify_mailbox」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 编号；
dialogueID: {type: ‘string’, required: true} // 对话编号；
senderID: {type: ‘string’, required: true} // 发送者编号；
recipientID: {type: ‘string’, required: true} // 接收者编号；
messageID: {type: ‘integer’, required: true} // 私信内容 ID；
createdAt：{type: ‘timestamp’, required: true} // 发送时间；
state: {type: ‘integer’, required: true} // 状态，已读 | 未读；
readAt：{type: ‘timestamp’, required: true} // 阅读时间；
Inbox
私信列表
select * from notify_inbox where recipientID=”uid” order by createdAt desc
对话列表
select * from notify_inbox where dialogueID=“XXXXXXXXXXXX”and (recipientID=“uid”or senderID=”uid”) order by createdAt asc
私信回复时，回复的是 dialogueID
Outbox
私信列表
select * from notify_inbox where senderID=”uid” order by createdAt desc
对话列表
select * from notify_inbox where dialogueID=“XXXXXXXXXXXX”and (senderID=“uid”or recipientID=”uid”) order by createdAt asc
私信内容表「notify_inbox_message」表结构如下：
id: {type: ‘integer’, primaryKey: true, autoIncrement:true} // 编号；
senderID: {type: ‘string’, required: true} // 发送者编号；
content: {type: ‘string’, required: true} // 私信内容；
createdAt：{type: ‘timestamp’, required: true}
参考
消息系统设计与实现 通知系统设计
