IM零碎中，特地是在企业应用场景下，音讯的已读未读状态是一个强需要。
性能看起来很酷，但用起来是一言难尽（上班族心里苦.... ）。实际上，技术实现也并不容易。
那么，对于已读未读状态：
1）如果是私聊：音讯的浏览状态比拟容易实现，在性能和存储上也不存在问题；2）如果是群聊：思考到存储和解决性能，特地当处于一个云环境时，如何高效地解决群聊的已读未读状态是一个十分值得探讨的话题。这里提到的“高效”含3个方面：
1）存储空间；2）处理速度；3）传输字节数。本文将从服务端的角度来探讨已读未读状态，在具体的技术实现上对于存储空间占用方面的思路差别。
已读未读状态交互流程
发送者发送的IM聊天音讯，在接收者浏览音讯后，是否要求阅读者告诉已读，可能是由系统配置、组织配置、群组配置等决定，也可能由发送者依据业务需要决定。以下的探讨，均假如音讯须要已读未读状态。
客户端与服务端之间，对于浏览状态的命令只需3个，每个命令含申请和应答。
告诉音讯已读（私聊、群聊通用）
当小宝浏览了一条或若干条音讯，需向服务端发送音讯已读告诉：“众爱卿发的x+y+z音讯，朕已阅”。
服务端收到小宝的已读告诉时，需实现以下事项：
1）存储音讯的已读状态；
2）返回应答给小宝；
3）向已读列表的音讯的原始发送者告诉音讯已读。
对于第“3）”步：
1）私聊的场合，比拟好了解，就是发送给私聊的对方；
2）群聊的场合，可很不一样：因为小宝发送的已读音讯列表，可能是由众爱卿发送的。思考这种假如：张三、李四、王五收回的群聊音讯，被小宝一下都浏览了，那么小宝收回的已读告诉蕴含的音讯列表，须要被IMS分解成3个已读告诉（3个不同的音讯列表），别离告诉给张三、李四、王五，告诉内容是“爱卿（不含'"众"）发的这些音讯，朕已阅”。
查问音讯的未读人数（私聊、群聊通用）
音讯的发送者，加载音讯列表到聊天窗口时，可能须要展现音讯是否被已读。
对群聊而言，显示的信息可能是n人未读的提醒，那么须要向服务端查问音讯的未读人数，因为客户端可能在UI显示本人收回的多条音讯，需反对一次申请查问多条音讯。
以未读人数的形式来示意音讯的浏览状态，对立了私聊、群聊的查问，使得客户端-服务端间的接口更简略，同时使客户端的实现逻辑更对立。
就像上面这样：
1）对于私聊：如果未读人数n>0，示意音讯未读；
2）对于群聊：间接显示n人未读即可，当然，当n等于0时示意全副已读。
查问群音讯的已读、未读人员清单（群聊）
当客户端心愿显示某一条群聊音讯的已读、未读人员列表，需向服务端发动查问。
几种具体的已读未读状态存储思路探讨
根本约定
群聊的浏览状态比私聊简单，因而这里着重探讨群聊的浏览状态。
假如群成员数是n，各个客户端立刻IM服务端发送已读告诉。服务端需存储每个人的浏览状态，包含那些未读的成员。因为群的成员清单可能变动，比方明天减少了一个成员，则昨天发的音讯、与明天发的音讯，其接收者列表不一样。
即：
1）同一个群的不同音讯，对应的接收者列表可能不一样。
2）换言之，每一条音讯都须要记录残缺的接收者列表和已读人员列表。
为了不便探讨，本章假如群成员有640人为前提。即时通讯聊天软件开发能够征询蔚可云开发。
存储思路1
每一条音讯都保护：
1）接管人员列表receiver_list；
2）已读人员列表read_list。
具体是：
1）IM Server收到一条音讯时，用整体群成员构建receiver_list；
2）IM Server收到群成员对这条音讯的已读告诉时，将此成员退出到read_list。
客户端获取此音讯的数据：
1）当须要获取未读人数时，用receiver_list的个数减去read_list的个数；
2）当须要获取已读、未读人员列表时，需用receiver_list减去read_list失去未读人员列表。
那么，思路1每条音讯的存储空间是：
640个ID + 不定数量的已读人员ID
存储思路2
每一条音讯保护：
1）未读人员列表unread_list；
2）已读人员列表read_list。
具体是：
1）IM Server收到一条音讯时，用整体群成员构建unread_list；
2）IM Server收到群成员对这条音讯的已读告诉时，将此成员从unread_list移出，同时退出到read_list。
客户端获取此音讯的数据：
1）当须要获取未读人数时，间接计算unread_list的个数；
2）当须要获取已读、未读人员列表时，间接返回unread_list和read_list。
那么，思路2每条音讯的存储空间是：
未读人员ID + 已读人员ID，共计640个ID
思路2的实现，占用的空间是案1的0.5倍~1.0倍。即案2占用的空间少，但在每次收到客户端的已读告诉时，比案1多了一个操作：从unread_list进行增员。