站内消息模块的最佳方案是怎样的？

[tlerbao]

我看有的系统设计成

三张表：用户表 users 、消息表 messages 、消息接收者中间表 message_receive 。

中间表字段：message_id/userid/read_status 。

给他们定义了多对多关联，message_receive 为中间表。

问题

1. 这个方案是否较好。
2. 有 1W 用户，群发一条消息就要在中间表写 1W 条记录。
3. 新用户无法看见之前的可能的通知公告类型的消息。

各位大神请问这种 消息 /站内消息模块 如何设计比较好？

[scung]

个人愚见，中间表可以加上创建时间和用户阅读时间。
在消息产生时，系统可以争对当前在线用户进行推送，这时候只需要插入在线用户数量的中间表数据。
消息表可以设计一个字段表示离线用户是否需要推送，这样离线用户和新注册用户在他们登录后，进行消息的拉取，这时候根据该字段再创建中间表数据，然后根据创建的数据数量来进行推送（比如上线后收到一条推送，内容：有 5 条新消息未查看）

[wangxiaoaer]

简单点就是生产者消费者模式。

以向 1W 用户群发一条消息为例：生产服务（进程）负责写入 1w 条记录，每条记录初始标记为未发送，可以间隔进行。消费服务（进程）负责读取未发送的记录，间隔发送、提醒。

[RedBeanIce]

消息写一条，那么无法对于吗每一条消息，做每个人的定制化操作。
消息写多条，那么存储量太大。

这是他们两个方案各自的缺点，我不知道有什么更好的答案，等楼下。

[RedBeanIce]

请忽略我的上述回答。。。我回复错了。

[night98]

可以看一下阿里之前直播时候写的技术文档，最终他们是采用了读写混合模式，具体的技术细节可以去看文档，和你这个场景比较类似，不过他们是做的直播间评论的功能

[FrankFang128]

支持群发怎么样

[sadfQED2]

群发消息只写一条数据，然后客户端拉取

单发消息服务端推送。

当然，你这边用户量少，随便怎么搞都行

[fackVL]

如果是我：消息模板表，单独消息表（带阅读状态，推送通知状态），群发消息表（全员推送通知状态，新用户只有未读不推送，新用户是否可见），群发消息阅读状态表（谁阅读了 insert 一条）。剩下的 mq 、缓存啥的还有业务逻辑不用说了吧。