2. IM 系统

IM 普遍存在于游戏、电商或工具型产品等各类 APP 中，作为用户和产品、买家和卖家、用户和用户之间的沟通渠道。另外，消息已不局限于传统聊天消息，也包括例如会议、行程待办、营销活动等各类通知的泛消息，IM 作为定向用户的触达通道和具备实时推送的能力。那怎么来构建典型的 IM 系统呢？

1. 功能板块

2. 典型架构

2.1 连接服务

1. 为什么 TCP 协议：保障消息可靠，选用简单依赖的底层协议。消息可靠是 IM 服务的基本能力，底层网络层依赖 tcp 的可靠协议，上层应用层依赖按位点有序的推拉机制保障。

2. 为什么长链接：

a. 消息实时性: 长连可以减少每次消息的交互次数，加快消息的更实时推送；

b. 有状态推送: 长连同时保持服务端维持端的在线离线状态, 方便消息的实时推送和同步；

c. 移动端省电: 长连同时减少端频繁建连的耗电。

通常的连接服务包括如下功能模块： 

2.2 处理服务

1. 功能职责: 处理服务存储和管理 IM 的用户、群、会话和消息等各域信息, 提供统一的 Biz 业务层的开放接口, 同时做会话消息和用户会话的预处理。 

2. 核心结构

2.3 推送服务

推送服务保证下行链路消息连续和有序的触达端用户, 同时具备优先级推送、条件推送和限流推送等各种策略的控制。 

下面是推送的基本流程和框架。

3. 推送模型

3.1 读写扩散

消息在触达发送每一位用户之前，会在系统进行简单预处理和预存储。

收件箱模式：每个用户的好友、好友群不同、会话也不同，导致待接收的消息列表也不一样，适合个性化的存储表达。所以针对每位用户，系统存储其专属待推送的消息盒子，称其为收件箱盒子。当用户在线时，按时间位点进行消息盒子的推送。

发件箱模式：收件箱模式可以针对每位用户消息做定制化推送，但缺点存在消息冗余存储。当万人群或头部主播直播百万级用户在线时，直播群每产生一条消息，存在明显百万级别的冗余存储和写扩散。这时采用发件箱模式，大规模用户群，采用单份存储，和降级历史消息推送和统一按当前时间位点推送。

3.2 推拉结合

推送消息: 当用户在线时，推送服务典型地按时间线的位点从远至近进行消息推送，具备消息实时性和可靠性的特点。可以满足大多数场景，由于大多用户频繁登入和退出时，每位好友或群历史消息有限。

拉取消息: 但当用户离线太久群待推历史消息较多时，用户重新在线会话时，推送消息由于推送的消息由远至近规则，给用户造成奇怪的体验。这时推送机制变为仅推送最近的消息，当用户进入会话需要光标上翻拉取更久远消息时，端主动翻页向服务端进行历史消息的拉取，采用推拉结合。 

4. 服务能力

IM 的核心能力满足消息个性化需求同时，必须保障消息的不丢不乱不重：

a. 不丢：位点推送 + 推拉结合 + 重试策略；

b. 不乱：统一时间尺度 + 会话维度有序；

c. 不重： 服务 ack 机制位点推送 + 端上排重策略。

5. 规划路线

IM 服务从零搭建到服务开放，一般都会经历下面四个阶段： 

a. 基础功能：在 IM 功能板块图里，逐步实现和满足各种消息的定制功能。例如：消息定制审核、多端同步和互踢，万人群定制等场景功能；

b. 弹性容灾：营销直播和活动热点通常导致峰值十倍百倍的消息突发增长，所以具备弹性扩容、冗余部署容灾和非核心功能降级等能力是支持突发业务场景的重要手段；

c. 成本控制：随着系统持续运行和服务，历史消息的规模化积累存储，降低内存和磁盘成本的诉求会提上日程。通常的方案手段通过近期消息和历史消息的分类分别进行冷热数据的区分存储。目前分布式数据库默认能友好的支持，通过分区字段的冷热属性设置，会把冷数据进行压缩备份、自动迁移至更低成本的存储介质和默认非索引的内存加载。

d. 异地部署：随着具备稳定的消息 SLA 保障能力，消息服务能力的开放和 PAAS 服务化是 IM 支持多部门业务或对外商业化的必经阶段。同时通过简单的复制多套部署和定制配置控制，实现多业务和多场景的隔离和多租户支持。