这是一个创建于 908 天前的主题，其中的信息可能已经有所发展或是发生改变。
我看有的系统设计成
三张表：用户表 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