站内信设计

参考文章：https://cloud.tencent.com/developer/article/1684449

b站站内信业务设计：

消息的类型分为：

1、系统消息
2、@、点赞、回复等用户行为之间的消息(事件提醒)
3、用户之间的消息

系统消息

用一个用户消息表可以吗？

可以，但是可能在部分的业务场景中需要处理的地方很多。比如：需要给全部用户发一个营销推送，就需要一次增加大量的数据，需要做异步的处理，防止超时响应。
用户消息表t_user_system_notice
用户消息id、消息标题、消息内容、接收用户id、状态(是否发送)、拉取通知时间

我们可以创建一个系统消息通知表 t_manager_system_notice
系统消息id、标题、消息内容、消息类型(指定人、全部用户、vip用户)、是否已经发送、指定人id、发送消息的管理员、发布时间
优化（并且可以把t_user_system_notice 中的消息标题、消息内容更改为系统消息id，关联存储）

当有需要发送消息的请求的时候向t_manager_system_notice表中增加数据。再通过定时服务拉取发送到用户消息表即可，可以控制拉取的时间。

事件提醒

需要业务梳理
xxx 在某个评论中@了你；
xxx 点赞了你的文章；
xxx 点赞了你的评论；
xxx 回复了你的文章；
xxx 回复了你的评论。

可以梳理出表的结构 t_event_remind
事件id、动作类型(点赞、@、回复)、事件id、事件类型(文章、评论)、事件源的内容、事件所发生的地点链接 url、状态(是否已读)、操作者id、接收内容用户id、提醒时间

事件这里有可以优化的点，可以根据自己的系统设计来
比如一个文章有1000k的点赞，可以聚合查询展示优化用户的查看内容
可以根据按照 事件类型 和 source id 来分组的

SELECT * FROM t_event_remind WHERE recipient_id = 用户ID
AND action = 点赞 AND state = FALSE GROUP BY source_id , source_type;

如果觉得 SQL 层面的结果集处理还是很麻烦，可以先把用户所有的点赞消息先查出来， 然后在程序里面进行分组，这样会简单不少。

拓展2
其实还有一种设计提醒表的做法，即按业务分类，不同的提醒存入不同的表，这样可以分为:
点赞提醒表
回复提醒表
at(@)提醒表。

这种设计比第一种的更松耦合，不必所有类型的提醒都挤在一张表里，但是这也会带来表数量的膨胀。 所以各位小伙伴可以自行选择方案。

用户私聊

站内私信一般都是点到点的，且要求是实时的，服务端可以采用 Netty 等高性能网络通信框架完成请求。

按照这个设计，我们可以先设计出聊天室表 t_private_chat，因为是一对一，所以聊天室表会包含对话的两个用户的信息：

这里 user1_id 和 user2_id 代表两个用户的 ID，并无特定的先后顺序。

接下来是私信表 t_private_message 了，私信自然和所属的聊天室有联系，且考虑到私信可以在记录中删除（删除了只是不显示记录，但是对方会有记录，撤回才是真正的删除），就还需要记录私信的状态，以下是他的设计：