企业IM比如企业微信、钉钉里面的群消息的有个已读未读的功能，发送者刚发出消息时，当前群里其他群成员都是未读状态，陆陆续续有人看了这个消息，这时候消息的详情变成x人已读，y人未读，如下图所示，有具体的已读未读列表（万恶的功能，看到同事or老板的消息不能假装没看到了），每条消息对应一个唯一的messageid（uint64_t），每个用户对应一个唯一的userid（uint64_t）,应该如何保存这个消息对应的已读未读详情呢？
对于每一个messageid，存当前readids + unreadids，当群成员A已读某一条消息时，把A userid从unreadids移除写到readids上就好了，客户端更新到messageid对应的详情列表，就可以展示m人已读，n人未读
struct UserInfo
{
uint64_t userid;
uint32_t mapid;
};
struct GroupMetaInfo
{
vector <UserInfo> members;
string name;
uint32_t maxid;
// other info
};这样群成员每加入一个群里，就有mapid<->usreid的双向映射了，假如群里有5个成员ABCDE, 那就对应mapid 1-5，messageid对应的消息详情存储就可以设计成：
{ uint32_t maxid, uint8_t readbit[]}如上面的案例就是{5, readbit[0] =bin(0000 0000)}; 就占用了5B(4+1),A发消息，D已读消息时，就更新成{5,readbit[0]= bin(0000 1000)},其余4人都已读消息时 更新为{5, readbit[0]=bin(0001 1110)}。
-
退出的成员呢？比如C退出群，发消息时maxid还是5，已读+未读总人数应该是3(不包括发消息者本人)，目前信息只有5个bit（0/1），识别不出来谁已经退出群聊了 -
退出群聊的成员如何处理？从GruopMetaInfo里面删除么？退出群聊成员重新加入又如何分配id呢？
-
增加自增mapid字段，一个群聊维护一份，成本几乎可以忽略不计 -
每个成员已读未读由8B（64bit）优化成2bit，减少62/64, 200人已读未读旧的方案1600B, 现在只需要(200/8) * 2 + 4 = 54 ， 每条消息节约95%+
没有回复内容