架构师面试（十三）：未读数模型

我们今天继续 IM 系统的相关话题。

问题

IM 用户登录后，会首先在客户端看到一个未读消息的红色标记的数字，即消息未读数，这个未读数是怎么生成的呢？关于IM系统【未读数模型】的相关描述，下面说法正确的有哪几项？

A. 整体上来说 IM 的未读数模型包括【离线消息计算】方式和【计数器计算】方式；

B. IM 系统通过离线消息计算未读数时，客户端登录后需要将其所有的离线消息拉取到本地后进行计算，实现逻辑简单；不过在离线消息量很大时，网络流量消耗很高；这种实现模型适合PC机时代的产品；

C. IM 系统通过计数器计算未读数时，在服务端针对每位用户的好友只需要一个字段存储消息的未读数即可；客户端用户每次进入聊天窗口时，需要及时将其对应的未读数字段清零；

D. 因为网络的不稳定因素和前后端之间交互时间窗口的存在，消息未读数在IM系统的客户端和服务端之间有可能是不一致的，这是正常现象，不是系统设计的问题。

解析

【未读数】在IM系统中是一个非常核心的设计板块：首先用户登录后，客户端会通过显示好友的“未读数” 引导用户的操作，增强用户的使用体验；在大用户量的时候，【未读数】更能考察架构师的设计能力，毕竟 “有未读数，但没有新消息； 或者是 “有新消息但没有未读数提醒” 都是典型的异常漏洞，影响用户的使用。

整体上来说 IM 的未读数模型包括【离线消息计算】和【计数器计算】两种方式。

我们先说【离线消息计算】方式： 用户离线时，他的好友给他发消息时，会将消息保存在“离线表”中； 当用户登录时，会将他所有的离线消息全部拉取到本地，然后由本地计算出他的每个好友发送的消息的数目（也就是消息的未读数）。 这种处理方式，整体逻辑比较简单，但是登录环节就会非常重，因为涉及到拉取所有的离线消息的操作；如果用户的离线消息（尤其是群消息）比较多，那么会消耗非常多的流量，尤其是用户并不关心的消息也拉取到了本地。 早期的 IM 产品，也就是PC机时代，主要采用【离线消息计算】方式处理【未读数】。

我们再说【计数器计算】方式：不管用户是否在线，他的好友给他发消息时