大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习 IM 系统😊
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 32 天，点击查看活动详情
IM
IM 的应用场景和业务功能
- 即时通讯；例如 QQ 、微信
- 用户点对点聊天；豆瓣、知乎
- 主播互动、实时弹幕；YY、抖音
- 实时监控、远程控制；智能家居 IOT
- 多人互动；游戏类场景
- 位置共享；交通类场景
- 在线白板；教学类场景
一个聊天系统分为几大部分组成：客户端、接入服务、业务处理服务、存储服务和外部接口服务
客户端是用户用来收发消息的终端设备。接入服务是涵盖四个功能：连接保持、协议解析、Session 维护和消息推送。业务处理服务是消息业务逻辑处理层，例如消息的存储、未读数量变更、更新最近联系人等。存储服务是持久化一些信息，例如账号信息、关系链、消息本身。外部接口服务是为了让用户在 App 未打开时可以收到新消息，所以要使用手机系统自身的公共连接服务来操作系统级消息推送，如苹果手机自带的 APNs、安卓手机自带的 GCM 服务、各种手机厂商的推送
接入服务和业务处理服务为什么要独立？
- 接入服务作为消息收发的出入口，必须是一个高可用的服务，保持足够的稳定性是一个必要条件。因为业务处理服务会随着产品需求迭代，变更非常频繁，导致经常重新部署。如果和接入服务放在一起，就会导致正在连接的客户端经常性的断连、重置、重连
- 接入服务和业务处理服务进行拆分有助于提高业务开发效率，降低业务开发门槛
IM 系统的特性
- 实时性
- 可靠性（不丢消息、消息不重复）
- 一致性（同一条消息在多人、多终端需要保持展现顺序的一致性）
- 安全性（数据传输安全、数据存储安全、消息内容安全）
消息存储
为了方便查看历史消息或者暂存离线消息，所以需要进行服务端存储
常见的消息系统关键点：
- 消息的发送方通过发送通道来把消息提交到 IM 服务端
- IM 服务端接收到发送的消息后，会进行消息的存储以便于后续历史消息的查看，消息的存储从实现上可以分为：消息内容存储、消息索引存储、最近联系人列表存储
- IM 服务端接收到发送的消息后，还会针对接收方进行未读数的变更，以提醒用户查看未读的消息，消息未读数的实现上一般分为：用户维度的总未读和会话维度的会话未读
- IM 服务端进行完消息存储和未读变更后，会通过接收通道把消息推送给接收方，接收通道一般是通过 IM 服务端和消息接收方之间维护的长连接来实现，还会使用第三方操作系统级别的辅助通道，来提升“自建的长连接不可用“时，实时触达的能力。
消息系统的一些表的设计
内容表
索引表
最近联系人表 （通常携带两人最近一条聊天消息用于展示）
一个可靠的长连接特点
- IM 服务端和接收方能较为精确地感知这个长连接的可用性，当由于网络原因连接被中断时，能快速感知并进行重连等恢复性操作
- 可靠性的另一层含义是：通过这个长连接投递的消息不能出现丢失的情况，否则会比较影响用户体验。这个问题的解决会在后续第 3 篇的课程中来详细展开
此文章为3月Day5学习笔记，内容来源于极客时间《即时消息技术剖析与实战》 这门课真的非常好，推荐大家看看
