消息已读、未读是怎么设计的？
比如企业微信、钉钉里面的群消息的有个已读未读的功能，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成x人已读，y人未读。每条消息对应一个唯一的 messageid（uint64_t），每个用户对应一个唯一的 userid（uint64_t），应该如何保存这个消息对应的已读未读详情呢？
其实未读已读就是一个0/1的标记而已，可以维护一个Bitmap来实现呢。
保存 userid 到自增 mapid 的映射
struct UserInfo
这样群成员每加入一个群里，就有 mapid<->usreid 的双向映射了。
假如群里有5个成员 ABCDE, 那就对应 mapid 1-5，messageid 对应的消息详情存储就可以设计成
{ uint32_t maxid, uint8_t readbit[]}
如上面的案例就是 {5, readbit = bin(0000 0000)}; 就占用了 5B(4+1) 。
A发消息，D已读消息时，就更新成 {5,readbit= bin(0000 1000)}。
其余4人都已读消息时，更新为 {5, readbit=bin(0001 1110)} 。
这是个粗略的方案，里面还有一些细节值得思考：
退出的成员呢？
比如C退出群，发消息时maxid还是5，已读 + 未读总人数应该是3（不包括发消息者本人），目前信息只有5个bit（0/1），识别不出来谁已经退出群聊了。
退出群聊的成员如何处理？从GruopMetaInfo里面删除么？退出群聊成员重新加入又如何分配id呢？
首先2这个点：
退出群聊的成员只能标记删除，不能物理删除，不然客户端展示已读未读详情时，通过mapid找不到对应的userid，退出的成员又重新加入群聊这个就好办了，把标记删除改成非标记删除，还是用旧的mapid。
至于1呢：
可以再加多一个 Bitmap ，记录成员在消息发送时是否已经退出群聊了，退出群聊就置为1。
所以最终方案就是：
群信息增加userid，自增mapid双向映射，退出群聊成员标记删除。
messageid 已读未读详情存储 {maxid, readbit[], quitbit[]}
新的方案带来怎样的收益呢？
增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计。
每个成员已读未读由8B（64bit）优化成2bit，减少62/64， 200人已读未读旧的方案1600B，现在只需要(200/8) * 2 + 4 = 54 ， 每条消息节约95%+。
如果maxid如果到百万甚至千万级别，那岂不是灾难？
一般实际场景，群聊是会限制人数的，就算不断踢人加新人，那maxid最多也只能到企业人数。
如果maxid达到一个特别大数字，已读未读对应的存储可以增加多一个flag，如果bitmap存储成本远超过最初的方案，可以用最初的方案来实现，客户端提前埋好兼容逻辑。
页:
[1]