我们仔细观察就能发现，生活中的任何类型互联网服务都有 IM 系统的存在。
比如：
1）基础性服务类-腾讯新闻（评论消息）；
2）商务应用类-钉钉（审批工作流通知）；
3）交流娱乐类-QQ/微信（私聊群聊 &讨论组 &朋友圈）；
4）互联网自媒体-抖音快手（点赞打赏通知）。
在这些林林总总的互联网生态产品里，即时消息系统作为底层能力，在确保业务正常与用户体验优化上，始终扮演了至关重要的角色。
所以，现如今的互联网产品中，即时通讯技术已经不仅限于传统IM聊天工具本身，它早已通过有形或无形的方式嵌入到了各种形式的互联网应用当中。IM技术（或者说即时通讯技术）对于很多开发者来说，确实是必不好可少的领域知识，不可或缺。
典型的IM系统通常需要满足四点能力：高可靠性、高可用性、实时性和有序性。
以我的这个项目来说，架构设设计要点主要是：
1）微服务：拆分为用户微服务 &消息连接服务 &消息业务服务；
2）存储架构：兼容性能与资源开销，选择 reids&mysql；
3）高可用：可以支撑起高并发场景，选择 Spring 提供的 websocket；
4）支持多端消息同步：app 端、web 端、微信公众号、小程序消息；
5）支持在线与离线消息场景。
理解读扩散和写扩散
我们举个例子说明什么是读扩散，什么是写扩散：
一个群聊“相亲相爱一家人”，成员：爸爸、妈妈、哥哥、姐姐和我（共 5 人）。
因为你最近交到女朋友了，所以发了一条消息“我脱单了”到群里面，那么自然希望爸爸妈妈哥哥姐姐四个亲人都能收到了。
正常逻辑下，群聊消息发送的流程应该是这样：
1）遍历群聊的成员并发送消息；
2）查询每个成员的在线状态；
3）成员不在线的存储离线；
4）成员在线的实时推送。
问题在于：如果第4步发生异常，群友会丢失消息，那么会导致有家人不知道“你脱单了”，造成催婚的严重后果。
所以优化的方案是：不管群员是否在线，都要先存储消息。
按照上面的思路，优化后的群消息流程如下：
1）遍历群聊的成员并发送消息；
2）群聊所有人都存一份；
3）查询每个成员的在线状态；
4）在线的实时推送。
以上优化后的方案，便是所谓的“写扩散”了。
问题在于：每个人都存一份相同的“你脱单了”的消息，对磁盘和带宽造成了很大的浪费（这就是写扩散的最大弊端）。
所以优化的方案是：群消息实体存储一份，用户只存消息 ID 索引。
于是再次优化后的发送群消息流程如下：
1）遍历群聊的成员并发送消息；
2）先存一份消息实体；
3）然后群聊所有人都存一份消息实体的 ID 引用；
4）查询每个成员的在线状态；
5）在线的实时推送。
二次优化后的方案，便是所谓的“读扩散”了。
小结一下：
1）读扩散：读取操作很重，写入操作很轻，资源消耗相对小一些；
2）写扩散：读取操作很轻，写入操作很重，资源消耗相对大一些。
消息实体模型：
常见的消息业务，可以抽象为几个实体模型概念：用户/用户关系/用户设备/用户连接状态/消息/消息队列。
实体模型概念解释：
用户实体：
1）用户->用户终端设备：每个用户能够多端登录并收发消息；
2）用户->消息：考虑到读扩散，每个用户与消息的关系都是 1：n；
3）用户->消息队列：考虑到读扩散，每个用户都会维护自己的一份“消息列表”（1:1），如果考虑到扩容，甚至可以开辟一份消息溢出列表接收超出“消息列表”容量的消息数据（此时是 1：n）；
4）用户->用户连接状态：考虑到用户能够多端登录，那么 app/web 都会有对应的在线状态信息（1：n）；
5）用户->联系人关系：考虑到用户最终以某种业务联系到一起，组成多份联系人关系，最终形成私聊或者群聊（1：n）；
联系人关系（主要由业务决定用户与用户之间的关系），比如说：
1）某个家庭下有多少人，这个家庭群聊就有多少人；
2）在 ToB 场景，在钉钉企业版里，我们往往有企业群聊这个存在。
消息实体：
消息->消息队列：考虑到读扩散，消息最终归属于一个或多个消息队列里，因此群聊场景它会分布在不同的消息队列里。
消息队列实体：
消息队列：确切说是消息引用队列，它里面的索引元素最终指向具体的消息实体对象。
用户连接状态：
1）对于 app 端：网络原因导致断线，或者用户手动 kill 掉应用进程，都属于离线；
2）对于 web 端：网络原因导致浏览器断网，或者用户手动关闭标签页，都属于离线；
3）对于公众号：无法分别离线在线；
4）对于小程序：无法分别离线在线。
用户终端设备：
客户端一般是 Android&IOS，web 端一般是浏览器，还有其他灵活的 WebView（公众号/小程序）。即时通讯开发
消息的存储方案
对于消息存储方案，本质上只有三种方案：要么放在内存、要么放在磁盘、要么两者结合存储（据说大公司为了优化性能，活跃的消息数据都是放在内存里面的，毕竟有钱~）。
下面分别解析主要方案的优点与弊端：
1）方案一：考虑性能，数据全部放到 redis 进行存储；
2）方案二：考虑资源，数据用 redis + mysql 进行存储。
对于方案一：redis
前提：用户 & 联系人关系，由于是业务数据，因此统一默认使用关系型数据库存储。
解释如下：
1）用户发消息；
2）redis 创建一条实体数据 &一个实体数据计时器；
3）redis 在 B 用户的用户队列 添加实体数据引用；
4）B 用户拉取消息（后续 5.2 会提及拉模式）。
实现方案：
1）用户队列，zset（score 确保有序性）；
2）消息实体列表，hash（msg_id 确保唯一性）；
3）消息实体计数器，hash（支持群聊消息的引用次数，倒计时到零时则删除实体列表的对应消息，以节省资源）。
优点是：内存操作，响应性能好
弊端是：
1）内存消耗巨大，eg：除非大厂，小公司的服务器的宝贵内存资源是耗不起业务的，随着业务增长，不想拓展资源，就需要手动清理数据了；
2）受 redis 容灾性策略影响较大，如果 redis 宕机，直接导致数据丢失（可以使用 redis 的集群部署/哨兵机制/主从复制等手段解决）。
方案二：redis+mysql
前提：用户 & 联系人关系，由于是业务数据，因此统一默认使用关系型数据库存储。
释如下：
1）用户发消息；
2）mysql 创建一条实体数据；
3）redis 在 B 用户的用户队列 添加实体数据引用；
4）B 用户拉取消息（下文会提及拉模式）。
实现方案：
1）用户队列，zset（score 确保有序性）；
2）消息实体列表，转移到 mysql（表主键 id 确保唯一性）；
3）消息实体计数器，hash（删除这个概念，因为磁盘可用总资源远远高于内存总资源，哪怕一直存放 mysql 数据库，在业务量百万级别时也不会有大问题，如果是巨大体量业务就需要考虑分表分库处理检索数据的性能了）。
优点是：
1）抽离了数据量最大的消息实体，大大节省了内存资源；
2）磁盘资源易于拓展 ，便宜实用。
弊端是：磁盘读取操作，响应性能较差（从产品设计的角度出发，你维护的这套 IM 系统究竟是强 IM 还是弱 IM）。