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

IM服务

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

一、概述

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

消息具备功能：

实时投递
单聊消息和群聊消息
消息撤回
消息回执
消息勿扰

消息投递特点：

准确性
消息不可丢失
实时性
有序性

IM相关概念：

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

二、消息投递

1、存储消息

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

1）读扩散

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

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

2）写扩散

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

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

2、接收消息

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

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

拉模式：用户设备定时从信箱中拉取一次消息
推模式：用户每发送一条消息，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、高并发架构

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

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