一、什么是站内消息系统？
如图所示，以微博为例，这些评论、点赞等消息加起来就叫做站内消息系统。
站内消息系统大概有以下几项内容：
- 系统消息：如系统下发的一些公共信息等都叫做系统消息，即系统发给用户的消息
- 行为消息：如评论、点赞等互动行为产生的消息，即用户行为对另一个用户产生提醒的消息
- 聊天消息：如私信，即用户发给用户的消息（聊天室也算）
同时呢，如果每一条消息都要显示，那么这个数据量将会很大（比如一个大V的微博被点赞100w次，那么就会收到100w条行为信息，这样不仅会导致加载缓慢，也会影响正常使用，因为满屏都是这些无效信息），所以一般我们都会对这些频繁重复的行为信息做聚合，如图所示：
只需要定时把还没下发的消息统计起来做聚合然后一次性下发给用户即可。
二、如何设计一个站内消息系统？
在上面我们提到，一个站内消息系统由系统消息、行为消息、聊天消息等组成，那么我们就一个个来简单分析一下吧。
1、系统消息
系统消息是由系统发送给用户的消息，一般可分为自动发送和手动发送。比如用户等级提升了会下发一条系统消息、用户违规会下发一条系统消息、又或者可以通过后台手动给某些用户下发系统消息。
所以在设计系统消息表时可以包括以下字段：
- 消息id
- 消息状态（是否已读）
- 用户id
- 下发时间、拉取时间
- 跳转链接url（如有）：比如有新活动的时候，我们可以给所有用户下发一条系统消息提醒他们去玩，并且点击消息可以直接跳转到活动页面
- …
具体推送模式我们可以使用推拉结合模式，给活跃用户采用推模式，给非活跃用户采用拉模式（当然具体问题具体分析，这个方案不是绝对的）。
2、行为消息
行为消息是用户行为对另一个用户产生提醒的消息，所以我们在表设计上可以做区分：
- 消息id
- 消息状态（是否已读）
- 用户id
- 下发时间、拉取时间
- 跳转链接url（如有）：如别人点赞了你的动态，你点击该点赞消息就可以跳转对应的动态详情页
- 动作类型：如评论、点赞等
- 目标id：如评论动态则为动态id、点赞评论则为点赞id
- 触发用户id
- …
具体推送模式我们可以分场景，如果比较频繁的场景可以考虑定时推模式，比如每10min拉取未下发的消息进行聚合下发即可。
3、聊天消息
聊天消息跟其他消息最大的区别点是它是需要实时的，如果我们延迟了几min才送达，那么这个功能我们会认为是不正常的。
我们可以看到，聊天消息一般分为两部分：
- 聊天用户列表
- 聊天消息列表（与某一具体用户的）
那么我们分别来对这两个列表做表设计就行。
聊天用户列表字段如下：
- 聊天id：比如用户与用户是一个聊天，多个用户一起的群组也是一个聊天
- 用户id：参与聊天的用户id（可以根据场景考虑设计成映射关系，如私信则对应两条记录，两条记录分别记录双方用户id。或者设计成对应关系，如私信则对应一条记录，而一条记录里同时记录双方用户id）
- 预览消息：可以看到在列表中我们可以看到最后一条消息（有的场景并不一定是最后一条消息，也可能是最近一条被@的消息），所以冗余在这里的话也可以提高查询性能
- …
聊天消息列表字段如下：
- 聊天id
- 消息id
- 消息文本
- 是否已读
- 是否已删除/已撤回
- 发送者id
- 接收者id
- 发送时间
- …
三、如何做消息设置？
消息的类型会有很多，当前用户也有不想收到的消息，所以一般设计一个站内消息系统，我们也要开放消息设置给用户，让他们自行决定想/不想收到哪些消息提醒。
然后当用户不想收到某种消息时，我们只需要在下发消息的时候加层过滤判断即可（如用户不想收到点赞信息，那么另一个用户对该用户的动态进行点赞后，我们将不用推送该条消息）。
