《亿级流量系统架构设计与实战》第十三章 IM服务

IM服务

• 一、概述
• 二、消息投递

• 1、存储消息
• 2、接收消息
• 3、消息的有序性保证
• 4、消息存储
• 5、高并发架构
• 6、整体架构

内容总结自《亿级流量系统架构设计与实战》

一、概述

通俗地说，所谓的IM就是聊天。

消息具备功能：

1. 实时投递
2. 单聊消息和群聊消息
3. 消息撤回
4. 消息回执
5. 消息勿扰

消息投递特点：

1. 准确性
2. 消息不可丢失
3. 实时性
4. 有序性

IM相关概念：

1. 消息：用户发出的任何内容
2. 用户状态：在线、离线、挂起
3. 设备/终端：用户使用IM的客户端，通常包括移动端和Web端
4. 单聊：两个用户一对一聊天的模式
5. 群聊：多个用户聊天的模式
6. 绘画：描述用户通过聊天建立的关联关系

---

二、消息投递

1、存储消息

消息不可丢失意味着必须要把消息保存起来，而为了保证消息的准确性，又需要把消息保存到其所属会话的信箱中。信箱主要有两种实现模式，分别是读扩散模式和写扩散模式。

1）读扩散

每个会话占用一个信箱，与会话相关的用户收发消息就是对这个信箱进行读/写。每个会话占用一个信箱，与会话相关的用户收发消息就是对这个信箱进行读/写，如下图的三个信箱

节省存储，但消息只有一份，节省空间

2）写扩散

会话信箱不再被会话相关的用户全局共享，而是每个用户都拥有一个自己关联会话的信箱列表。在该模式下，用户发送消息，不仅需要把消息投递到自己的会话信箱中，而且需要把消息投递到消息接收者的会话信箱中

性能好，消息存在多个冗余的消息副本，更占空间

2、接收消息

将消息存储到会话信箱中可以保证消息的准确性和不丢失，但是消息尚未真正触达用户设备。

用户设备获取消息的一种方式是采用拉模式，即用户设备周期性地主动向IM服务后台发起获取消息地请求，由服务端将所有相关会话地未读消息返回

1. 拉模式：用户设备定时从信箱中拉取一次消息
2. 推模式：用户每发送一条消息，IM服务后台在把消息存储到信箱中的同时，还会把消息推送到用户设备

1）推模式

2）推拉模式结合

3）推拉模式结合（简化版）

3、消息的有序性保证

常规的保证消息有序性的方案，所有消息发送走一个入口，内部借助MQ处理流量问题

4、消息存储

1）存储消息本身的消息表：

字段名	类型	含义
id	bigint	主键
msg_id	bigint	消息id
conversation_id	varchar	会话id
user_id	bigint	消息发送者id
content	text	消息内容
status	bigint	消息状态
send_time	datetime	消息发送时间

2）管理会话数据的会话表：主要用于根据会话ID获取会话信息

字段名	类型	含义
id	bigint	主键
conversation_id	varchar	会话id
type	bigint	会话类型
member	bigint	会话相关的成员
avatar	varchar	用于群聊，保存群头像
announcement	text	用于群聊，保存群公告
recent_msg_time	datetime	会话最新产生消息的时间

3）会话消息链表：用于支持读扩散模式的消息存储，保证会话内消息有序

字段名	类型	含义
id	bigint	主键
conversation_id	varchar	会话id
msg_id	bigint	消息id
seq	bigint	消息在会话中的序列号，用于保证消息的顺序

4）用户消息链：与会话消息链相同，服务于写扩散模式的用户消息链也应该有一个类似结构的数据表user_msg_list

字段名	类型	含义
id	bigint	主键
user_id	bigint	用户id
msg_id	bigint	消息id
conversation_id	varchar	会话id
seq	bigint	消息在会话中的序列号，用于保证消息的顺序

5）用户会话链：记录用户与会话关联关系

字段名	类型	含义
id	bigint	主键
user_id	bigint	用户id
conversation_id	varchar	会话id
last_read_seq	bigint	此会话中用户已读的最后一条消息
notify_type	bigint	会话接收到消息的提醒类型
is_top	bigint	会话是否被置顶展示

5、高并发架构

即时通信是一个典型地读多写多地场景。

1. 发送消息：IM服务借助MQ搭建多级架构
2. 数据缓存：我们可以将消息表、会话表、用户会话链、会话消息链、用户消息链的数据全部存储到Redis中
3. 消息分级：根据会话的用户数量，对消息的实时性和触达成功率做优先级处理。优先级从高到低分别可以粉为单聊消息、100人以内群聊消息、100-1000人以内的群聊消息、1000人以上群聊。可以针对不同的优先级，创建专门的IM服务集群，集群之间不共享任何资源（消息队列、数据库、Redis等）

6、整体架构

原创作者: u_15942107 转载于: https://blog.51cto.com/u_15942107/11906798