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

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

问题

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

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

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

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

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

解析

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

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

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

我们再说【计数器计算】方式：不管用户是否在线，他的好友给他发消息时，除了将消息落库外，需要一个字段（每个好友对应一个字段，一般是在联系人表中，可以形象地成之为 计数器）专门累加消息的未读数；如果用户是离线状态，登录后，会首先读取这个计数器字段的数值显示给用户；如果用户是在线状态，在用户进入和离开聊天窗口时，需要将客户端的未读数实时同步到服务端，使未读数字段的数值保持一致。 这种处理方式，对于用户想要拉取的消息就非常灵活了，不关心的消息不用拉取，只用一个 未读数字段表示出有多少条消息未读即可，【计数器计算】方式非常适合移动互联网时代的IM产品。

【计数器计算】方式中，服务端的 “未读数” 表示用户收到了多少条消息，客户端的 “未读数” 表示用户还有多少条消息没有读，因此这两个数字是非常可能或大概率是不一致的，这是正常的现场，不是系统设计的问题；所以需要客户端实时地（一般是进入和离开聊天窗口时）将未读数同步到服务端（所以 D选项是正确的）。 在客户端将未读数同步到服务端时，是直接将 “未读数清零” 吗？ 大家注意，这是一个关键的设计： 直接清零是错误的，因为在清零之前如果收到了一条消息，那么这条消息就会被无辜的直接清零忽视了； 正确的做法是将 客户端聊天窗口中最新的一条消息的ID（或其他字段，比如：时间）发送到服务端，由服务端进行计算和未读数重置；所以C选项是错误的！（这个地方大家一定要注意哈，咱们在课上重点讲过的哦！）

答案

ABD