参考文章: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 了,私信自然和所属的聊天室有联系,且考虑到私信可以在记录中删除(删除了只是不显示记录,但是对方会有记录,撤回才是真正的删除),就还需要记录私信的状态,以下是他的设计: