这是一个创建于 588 天前的主题，其中的信息可能已经有所发展或是发生改变。
我看有的系统设计成
三张表：用户表 users 、消息表 messages 、消息接收者中间表 message_receive 。
中间表字段：message_id/userid/read_status 。
给他们定义了多对多关联，message_receive 为中间表。
问题
- 这个方案是否较好。
- 有 1W 用户，群发一条消息就要在中间表写 1W 条记录。
- 新用户无法看见之前的可能的通知公告类型的消息。
各位大神请问这种 消息 /站内消息模块 如何设计比较好？
 |
1
scung 2023-04-15 19:49:55 +08:00
个人愚见，中间表可以加上创建时间和用户阅读时间。
在消息产生时，系统可以争对当前在线用户进行推送，这时候只需要插入在线用户数量的中间表数据。 消息表可以设计一个字段表示离线用户是否需要推送，这样离线用户和新注册用户在他们登录后，进行消息的拉取，这时候根据该字段再创建中间表数据，然后根据创建的数据数量来进行推送（比如上线后收到一条推送，内容：有 5 条新消息未查看） |
 |
2
wangxiaoaer 2023-04-15 20:21:36 +08:00
简单点就是生产者消费者模式。
以向 1W 用户群发一条消息为例：生产服务（进程）负责写入 1w 条记录，每条记录初始标记为未发送，可以间隔进行。消费服务（进程）负责读取未发送的记录，间隔发送、提醒。 |
 |
3
RedBeanIce 2023-04-15 20:29:54 +08:00
消息写一条，那么无法对于吗每一条消息，做每个人的定制化操作。
消息写多条，那么存储量太大。 这是他们两个方案各自的缺点，我不知道有什么更好的答案，等楼下。 |
|
4
RedBeanIce 2023-04-15 20:30:24 +08:00
请忽略我的上述回答。。。我回复错了。
|
 |
5
night98 2023-04-15 23:36:55 +08:00
可以看一下阿里之前直播时候写的技术文档，最终他们是采用了读写混合模式，具体的技术细节可以去看文档，和你这个场景比较类似，不过他们是做的直播间评论的功能
|
 |
6
FrankFang128 2023-04-16 03:45:39 +08:00
支持群发怎么样
|
 |
7
sadfQED2 2023-04-16 08:27:53 +08:00 via Android
群发消息只写一条数据，然后客户端拉取
单发消息服务端推送。 当然，你这边用户量少，随便怎么搞都行 |
 |
8
fackVL 2023-04-16 09:27:42 +08:00 via iPhone
如果是我：消息模板表，单独消息表（带阅读状态，推送通知状态），群发消息表（全员推送通知状态，新用户只有未读不推送，新用户是否可见），群发消息阅读状态表（谁阅读了 insert 一条）。剩下的 mq 、缓存啥的还有业务逻辑不用说了吧。
|
Select Language