群发消息已读未读如何设计才能降低数据库的压力

>>然后查看哪些用户读了消息
要不再建一张表，只记录查看了消息的用户

1.表 B 的设计思路，其实是偷懒的做法，这种思路方便一次性查出 8 辈子的消息记录，缺点就是性能差。

2.科学的高性能的设计思路应该是，发一次消息，建一个表。这样每个表里就只有十万条消息了。

3.每隔一段时间清理这些表，如果历史数据需要保存，可以直接 dump 到文件，或者放置在内存占用少的数据库实例中。

已读和未读消息分两个表存

消息已读存 hbase，msgid:reader id

用 redis 记录发送的消息, 两个集合搞定. 一个记录发送的用户 ID 一个记录已读的用户 ID 然后去差集就好
已读未读的状态在前端的消息列表控制

大佬们有没有做过这样的需求？

把已读事件写到一个流里面，用 flink 做实时统计

我用的 redisSET 记录消息的用户状态，然后定时备份到 mysql，缺点很多，但是只要 redis 不挂勉强能应付

放客户端 sql 库啊

服务端可以这样做：消息发送后保存消息 id 和发送时的时间戳在内存中
半小时内在内存中用布隆过滤器处理客户端发过来的数据区分已读未读，写一个定时
对超过半小时的消息 id 入库处理（或者用消息队列异步合并写）。

客户端的已读未读就放在客户端的库一条条处理

插个眼 目前也有类似的需求

mark，感觉不同数量级的消息 会有不同的设计实践。

@jacobsun #5
@wennew #8 set 操作比直接用 hashmap 麻烦吧，而且直接写数据库就是了，redis 就是个缓存，统计已读有问题不是写已读数据有问题

其实直接发的时候都把发送用户 ID 己到 redis 消息 ID 对应的 hashmap 里就是了啊，读了就从里边删了，看哪些用户没读直接读整个 hashmap 就是了，设置一个合理过期时间也都不用清理，读不到再从数据库加载就是了，发消息和读消息都先写数据库再写 redis 就是了

如果你觉得直接用 hashmap 太耗内存，那么就在发消息式给个再当前消息内部有效的自增 ID，redis 这边就能用 bitmap 来存是否已读了啊，查的时候直接取出哪些位置没读，然后结合消息 ID 就直接能查除用户了，这个应该式最省内存也不是很消耗性能的方式了吧

做了一套类似的，不过没有明细需求，只统计发送数、已读数

@sujin190 hashmap 加过期时间还是变成 redis 了呀， 而且这东西确实可以用 nosql 冗余存储，mysql 这种确实不好使啊

@wennew #16 我的意思用 redis 的 set 数据结构比用 redis 的 hashmap 数据结构操作复杂，都是 redis 。。

才十万，直接存数据库建好索引分区肯定没问题。

@aguesuka 群发一条就 10 万，要是每天 100 个用户群发一条，一天就有 1000 万了，你看看一个月就有多少数据量了。