从零开始开发IM（即时通讯）服务端

精选：★→2020年最新的常问企业面试题大全以及答案

作者：yuanrw

原文地址 https://juejin.im/post/5d6b3949f265da03c34c13e5

好消息：IM1.0.0 版本已经上线啦，支持特性：

• 私聊发送文本 / 文件

• 已发送 / 已送达 / 已读回执

• 支持使用 ldap 登录

• 支持接入外部的登录认证系统

• 提供客户端 jar 包，方便客户端开发
  github 链接： github.com/yuanrw/IM

前言

首先讲讲 IM（即时通讯）技术可以用来做什么：
聊天：qq、微信
直播：斗鱼直播、抖音
实时位置共享、游戏多人互动等等
可以说几乎所有高实时性的应用场景都需要用到 IM 技术。

本篇将带大家从零开始搭建一个轻量级的 IM 服务端，麻雀虽小，五脏俱全，我们搭建的 IM 服务端实现以下功能：

1. 一对一的文本消息、文件消息通信

2. 每个消息有 “已发送”/“已送达”/“已读” 回执

3. 存储离线消息

4. 支持用户登录，好友关系等基本功能。

5. 能够方便地水平扩展

通过这个项目能学到什么？

这个项目涵盖了很多后端必备知识：

• rpc 通信

• 数据库

• 缓存

• 消息队列

• 分布式、高并发的架构设计

• docker 部署

消息通信

文本消息

我们先从最简单的特性开始实现：一个普通消息的发送
消息格式如下：

message ChatMsg{
    id = 1;
    //消息id
    fromId = Alice
    //发送者userId
    destId = Bob
    //接收者userId
    msgBody = hello
    //消息体
}
复制代码

如上图，我们现在有两个用户：Alice 和 Bob 连接到了服务器，当 Alice 发送消息

message(hello)

给 Bob，服务端接收到消息，根据消息的 destId 进行转发，转发给 Bob。

发送回执

那我们要怎么来实现回执的发送呢？
我们定义一种回执数据格式 ACK，MsgType 有三种，分别是 sent（已发送）, delivered（已送达）, read（已读）：

message AckMsg {
    id;
    //消息id
    fromId;
    //发送者id
    destId;
    //接收者id
    msgType;
    //消息类型
    ackMsgId;
    //确认的消息id
}
enum MsgType {
    DELIVERED;
    READ;
}
复制代码

当服务端接受到 Alice 发来的消息时：

1. 向 Alice 发送一个 sent(hello)表示消息已经被发送到服务器。

message AckMsg {
    id = 2;
    fromId = Alice;
    destId = Bob;
    msgType = SENT;
    ackMsgId = 1;
}
复制代码

1. 服务器把

hello

转发给 Bob 后，立刻向 Alice 发送

delivered(hello)

表示消息已经发送给 Bob。

message AckMsg {
    id = 3;
    fromId = Bob;
    destId = Alice;
    msgType = DELIVERED;
    ackMsgId = 1;
}
复制代码

1. Bob 阅读消息后，客户端向服务器发送

read(hello)

表示消息已读

message AckMsg {
    id = 4;
    fromId = Bob;
    destId = Alice;
    msgType = READ;
    ackMsgId = 1;
}
复制代码

这个消息会像一个普通聊天消息一样被服务器处理，最终发送给 Alice。

在服务器这里不区分 ChatMsg和 AckMsg，处理过程都是一样的：解析消息的 destId并进行转发。

水平扩展

当用户量越来越大，必然需要增加服务器的数量，用户的连接被分散在不同的机器上。此时，就需要存储用户连接在哪台机器上。
我们引入一个新的模块来管理用户的连接信息。

管理用户状态

模块叫做 user status，共有三个接口：

public interface UserStatusService {
    /**
     * 用户上线，存储userId与机器id的关系
     *
     * @param userId
     * @param connectorId
     * @return 如果当前用户在线，则返回他连接的机器id，否则返回null
     */
    String online(String userId, String connectorId);
    /**
     * 用户下线
     *
     * @param userId
     */
    void offline(String userId);
    /**
     * 通过用户id查找他当前连接的机器id
     *
     * @param userId
     * @return
     */
    String getConnectorId(String userId);
}
复制代码

这样我们就能够对用户连接状态进行管理了，具体的实现应考虑服务的用户量、期望性能等进行实现。
此处我们使用 redis 来实现，将 userId 和 connectorId 的关系以 key-value 的形式存储。

消息转发

除此之外，还需要一个模块在不同的机器上转发消息，如下结构：

此时我们的服务被拆分成了 connector和 transfer两个模块， connector模块用于维持用户的长链接，而 transfer的作用是将消息在多个 connector之间转发。
现在 Alice 和 Bob 连接到了两台 connector 上，那么消息要如何传递呢？

1. Alice 上线，连接到 机器[1]上时

• 将 Alice 和它的连接存入内存中。

• 调用 user status的 online方法记录 Alice 上线。

• Alice 发送了一条消息给 Bob

• • 机器[1]收到消息后，解析 destId，在内存中查找是否有 Bob。

  • 如果没有，代表 Bob 未连接到这台机器，则转发给 transfer。

• transfer调用 user status的 getConnectorId(Bob)方法找到 Bob 所连接的 connector，返回 机器[2]，则转发给 机器[2]。

• 流程图：

  

  总结：

  • 引入 user status模块管理用户连接， transfer模块在不同的机器之间转发，使服务可以水平扩展。

  • 为了满足实时转发， transfer需要和每台 connector机器都保持长链接。

  离线消息

  如果用户当前不在线，就必须把消息持久化下来，等待用户下次上线再推送，这里使用 mysql 存储离线消息。
  为了方便地水平扩展，我们使用消息队列进行解耦。

  • transfer接收到消息后如果发现用户不在线，就发送给消息队列入库。

  • 用户登录时，服务器从库里拉取离线消息进行推送。

  用户登录、好友关系

  用户的注册登录、账户管理、好友关系链等功能更适合使用 http 协议，因此我们将这个模块做成一个 restful 服务，对外暴露 http 接口供客户端调用。

  至此服务端的基本架构就完成了：

  

  总结

  以上就是这篇博客的所有内容，本篇帮大家构建了 IM 服务端的架构，但还有很多细节需要我们去思考，例如：

  • 如何保证消息的顺序和唯一

  • 多个设备在线如何保证消息一致性

  • 如何处理消息发送失败

  • 消息的安全性

  • 如果要存储聊天记录要怎么做

  • 数据库分表分库

  • 服务高可用
    ……

  更多细节实现就留到下一篇啦～

  IM1.0.0 版本已上线，github 链接： github.com/yuanrw/IM
  觉得对你有帮助请点个 star 吧～！

  

  （完）
  

  推荐阅读

  Spring Boot整合JWT实现用户认证（附源码）
  

  IDEA新特性：提前知道代码怎么走

  还在担心写的一手烂SQL，送你4款工

  瞬间几千次的重复提交，我用 SpringBoot+Redis 扛住了

  爬了知乎“神回复”，笑得根本停不下来

  这 17 个 JVM 参数，高级 Java 必须掌握！

  
  好文！必须点赞