| 失效链接处理 |
|
如何设计一个站内消息系统？ PDF 下载
本站整理下载：
相关截图：
主要内容：
可以看到 B 站把消息⼤致分为了三类：
1. 系统推送的通知(System Notice)；
2. 回复、@、点赞等⽤户⾏为产⽣的提醒(Remind)；
3. ⽤户之间的私信(Chat)。
这样设计不仅分类明确，且处于同⼀个主体的事件提醒还会做⼀个聚合，极⼤的提⾼了⽤户体
验，不让⽤户收到太多分散的消息。
举个例⼦：⽐如你在某个视频或某篇⽂章下发表了评论，有 100 个⼈给你的评论点了赞，那么
你希望消息⻚⾯呈现的是⼀个⼀个⽤户给你点赞的提醒，还是像以下聚合之后的提醒：
我相信你⼤概率会选择后者。
我认为对于很多应⽤来说，这样的设计都是⾮常合理的，接下来我写写我对于消息系统的设
计。
系统通知⼀般是由后台管理员发出，然后指定某⼀类（全体，个⼈等）⽤户接收。基于此设
想，可以把系统通知⼤致分为两张表：
1. t_manager_system_notice（管理员系统通知表） ：记录管理员发出的通知 ；
2. t_user_system_notice（⽤户系统通知表） ： 存储⽤户接受的通知。
t_manager_system_notice（管理员系统通知表） 表结构如下：
t_user_system_notice（⽤户系统通知表）结构如下：
当管理员发布⼀条通知后，将通知插⼊ t_manager_system_notice 表中，然后系统定时的从
t_manager_system_notice 表中拉取通知，然后根据通知的 type 将通知插⼊
t_user_system_notice 表中。
如果通知的 type 是 single 的，那就只需要插⼊⼀条记录到 t_user_system_notice 中。如果是
全体⽤户，那么就需要将⼀个通知批量根据不同的⽤户 ID 插⼊到 t_user_system_notice 中，
这个数据量就需要根据平台的⽤户量来计算。
举个例⼦：管理员 A 发布了⼀个活动的通知，他需要将这个通知发布给全体⽤户，当拉取时
间到来时，系统会将这⼀条通知取出。随后系统到⽤户表中查询选取所有⽤户的 ID，然后将这
⼀条通知的信息根据所有⽤户的 ID，批量插⼊ t_user_system_notice 中。⽤户需要查看系统通
知时，从 t_user_system_notice 表中查询就⾏了。
需要注意的是：
1. 因为⼀次拉取的数据量可能很⼤，所以两次拉取的时间间隔可以设置的⻓⼀些。
2. 拉取 t_manager_system_notice 表中的通知时，需要判断 state，如果已经拉取过，就不
需要重复拉取，否则会造成重复消费。
3. 有的⼩伙伴可能有疑问： 某条通知已经被拉取过的话，在其后注册的⽤户是不是不能再接
收到这条通知？是的。但如果你想将已拉取过的通知推送给那些后注册的⽤户，也不是特
别⼤的问题。只需要再写⼀个定时任务，这个定时任务可以将通知的 push_time 与⽤户的
注册时间⽐较⼀下，重新推送即可。
认真思考的⼩伙伴应该也发现了，当⽤户量⽐较⼤⽐如上千万的时候，如果发送⼀个全体⽤户
的通知需要挨个插⼊数据到⼀张表的话，是不靠谱的！
常⻅的解决办法，有两种⽅式:
1. 每位⽤户单独有⼀张或者⼏张专⻔⽤来存放站内消息的表，根据 hash(userId) 作为表
名后缀。
2. 对于系统通知类型，只存放⼀条数据到 t_user_system_notice 表，⽤户⾃⼰拉取数据然后
再判断消息是否已经读取过即可。
并且，当⼀条通知需要发布给全体⽤户时，我们还应该考虑到⽤户的活跃度。因为如果有些⽤
户⻓期不活跃，我们还将通知推送给他（她），这显然会造成空间的浪费。 所以在选取⽤户 ID
时，我们可以将⽤户上次登录的时间与推送时间做⼀个⽐较，如果⽤户⼀年未登陆或⼏个⽉未
登录，我们就不选取其 ID，进⽽避免⽆谓的推送。
以上就是系统通知的设计了，接下来再看看较难的提醒类型的消息
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
