消息功能中系统通知这一类信息的已读未读除了用数据表之外有没有比较好的解决方案

做个公告 不行吗 都要每个人去确认一遍公告 是否有必要呢

如果有必要的话 我也等一下答案 哈哈

之前有类似项目, 不过不是我做的,公司 另一个后端

大概实现做成多对多, 消息表/中间表/用户表, 已读字段存中间表, 这个项目中消息还有一个删除已读, 但是也是逻辑删除, 同样存中间表字段, 这样设计查询比较麻烦

之前做过类似的消息系统。消息存一个表，消息-用户存另一个表。

消息表只存消息本身，消息id，消息内容，来自谁，发送至，创建时间

消息-用户表存消息状态。ID，消息ID，uid，已读状态，删除状态。

每次用户发消息给别人，消息表存1条，消息用户表存两条，分别对应两个人对消息的状态，例如删除，已读。

但这个方法只能用于数据量少的应用，我们当时两万用户就已经顶不住了。。

可以表中添加查看人字段，存已读用户的ID，稍微好一点

没有魔法，我看阿里云，也经常发站内信。

全部用户都看的消息还好, 但是那种面向特定条件用户发的消息就很麻烦了, 所以还是加个中间表....

如果对应的值只有0和1，可以用bit map来解决存储空间的问题。redis中也有bit map。

偷懒，前端自己缓存处理。再做个过期机制，默认多久的消息就自动标为已读。 :speak_no_evil:

我支持加中间表方案

问下站长这里的已读未读是怎么做的 :joy:

消息表和用户消息表分开不就行了，一对一的两张表同时存，一对多的只存在消息表，满足条件的用户拉取的时候才存到用户消息表

@Summer

看标题 楼主不想要存数据库的方式~

我做过,讲一下吧,很简单的解决方案

使用redis的bitmap

//设置用户已读:
$redis->setBit('message:'.$msg_id, $uid, 1);

//获取是否读取状态:
$redis->getBit('message:'.$msg_id, $uid);

//支持千万级用户,并且不会有数据存储方面的压力

另外:bitmap还可以做签到,活跃统计,在线状态等等…

gk.link/a/10ViE

gk.link/a/10ViG

可以去看下这两章，有详细的解答

思路哈

• 公告类型的跟定向用户通知在两个表里存
• 公告类的加一个多对多已读表
• 通知类的就用la的默认notifications

至于说用户量大了之后

• 通过redis缓存通知 [id=>readed] 这样
• 定期把数据维护到数据库（总要有个持久化的位置 redis当然也行 只要不嫌占内存）
• 用户量真能百万，就不可能是la一个项目了 多半会有专门的通知系统

为什么不用时间戳呢，记录用户读取系统消息的时间，和最新的系统消息发送的时间比较，如果新新的系统消息发送时间 > 用户最后一次的已读时间，它就存在未读系统消息，反之都已读了，多一个字段就搞定了 :speak_no_evil:

我觉得可以参考“三端互通”软件做法，一般这种都会做成“公告”的模式。数据结构：标识、公告内容、过期时间、....。 让客户端根据标识、过期时间这些字段做一下本地缓存就行了，这样可以功能就变得相对简单 原因：

1. 一般不会有什么需求用到这一类的已读消息的数据，有就让客户端上报到打点系统就完了
2. 像钉钉、飞书这种高端商业软件才会认真地一条一条存

我司业务上该类通知消息并不重要 只是作为展示 我们直接前端处理 是否已读 后端只做通知消息记录