在社交关系中的即时消息一般分为两种，单聊和群聊，而用户有可能有多台设备同时登录

所及对应关系基本如下

设备用户关系

用户<-1---------------*->设备

用户群组关系

用户<-*---------------*->群组

发送消息的过程：

单聊：A 发送消息给 B

A----send msg----> server ----deliver msg-->  B

群聊： A 发送消息给 Group1(用户 A, B, C, D)

                            |----deliver msg-->  B
A----send msg---> server -->|----deliver msg-->  C
                            |----deliver msg-->  D

上边只是一个理想状态，并没有考虑用户是否在线，还有多设备的问题，考虑在线的话就得考虑是否保存离线消息，离线消息保存多久(假想不离线存储聊天信息)

只考虑在线与否，不考虑多设备的发型消息过程：

单聊：A 发送消息给 B

                            | B 在线 |---   直接  deliver msg-->  B
A----send msg----> server --|       |
                            | B 离线 |--- 等待上线 deliver msg-->  B

群聊： A 发送消息给 Group1(用户 A, B在线, C离线, D在线)

                            |----   直接  deliver msg-->  B
A----send msg---> server -->|---- 等待上线 deliver msg-->  C
                            |----   直接  deliver msg-->  D

考虑多设备的情况其实跟上边的过程也并没有太大差别，只需要把用户应设成多个设备就好，只是在移动互联网的背景下整个模型就稍微有些不同了，在人手一部手机的情况下手机号或者手机设备基本可以与用户画上等号，从用户体验的角度考虑在用户离线的情况下使用第三方消息触达就有点必要了，比如手机APP，浏览器，桌面应用消息通知、手机短信、邮件等等，当然主流的还是 APP 的消息通知

那么把离线消息通知考虑进来,另外再模拟一种情况就是用户取消订阅群组的消息提醒

单聊：A 发送消息给 B

                            | B 在线 |--- 直接     deliver msg   ----------->  B
A----send msg----> server --|       |
                            | B 离线 |--- 第三方触达 -----> 上线 deliver msg-->  B

群聊： A 发送消息给 Group1(用户 A, B在线, C离线不提醒, D离线提醒)

                            |---- 直接                 deliver msg -->  B
A----send msg---> server -->|---- 等待上线              deliver msg -->  C
                            |---- 第三方触达 -----> 上线 deliver msg -->  D

OK，梳理完业务模型再来看 MQTT 协议以及 EMQTT 提供的功能

关于 mqtt 和发布订阅模式先摘抄一份介绍

MQTT设计原则：

精简，不添加可有可无的功能。
发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。
允许用户动态创建主题，零运维成本。
把传输量降到最低以提高传输效率。
把低带宽、高延迟、不稳定的网络等因素考虑在内。
支持连续的会话控制。
理解客户端计算能力可能很低。
提供服务质量管理。
假设数据不可知，不强求传输数据的类型与格式，保持灵活性

发布/订阅模式

与请求/回答这种同步模式不同，发布/定义模式解耦了发布消息的客户（发布者）与订阅消息的客户（订阅者）之间的关系，这意味着发布者和订阅者之间并不需要直接建立联系。打个比方，你打电话给朋友，一直要等到朋友接电话了才能够开始交流，是一个典型的同步请求/回答的场景；而给一个好友邮件列表发电子邮件就不一样，你发好电子邮件该干嘛干嘛，好友们到有空了去查看邮件就是了，是一个典型的异步发布/订阅的场景。

主题

MQTT是通过主题对消息进行分类的，并且可以通过通配符进行过滤，如：

building-b/floor-5：代表B楼5层的设备。
+/floor-5：代表任何一个楼的5层的设备。
building-b/#：代表B楼所有的设备。

以上内容摘自知乎专栏 MQTT入门篇

EMQ

介绍 EMQ 2.0 (Erlang/Enterprise/Elastic MQTT Broker) 是基于 Erlang/OTP 语言平台开发，支持大规模连接和分布式集群，发布订阅模式的开源 MQTT 消息服务器。

全异步架构

EMQ 消息服务器是基于 Erlang/OTP 平台的全异步的架构：异步 TCP 连接处理、异步主题(Topic)订阅、异步消息发布。只有在资源负载限制部分采用同步设计，比如 TCP 连接创建和 Mnesia 数据库事务执行。

一条 MQTT 消息从发布者(Publisher)到订阅者(Subscriber)，在 EMQ 消息服务器内部异步流过一系列 Erlang 进程 Mailbox:

                  ----------          -----------          ----------
Publisher --Msg-->| Client | --Msg--> | Session | --Msg--> | Client | --Msg--> Subscriber
                  ----------          -----------          ----------

来源 emqtt 官网

实测用户登录到 emqtt 服务器后，用户和话题的订阅关系是依靠 session 保存的，只要不清除 session 用户下次登录依然保留当前的订阅关系，而且用户掉线后 QoS 1,2 的消息会保存在服务器端，当用户再次登录即可收到之前的消息。

设计实现

所以即时消息服务可以进行如下设计

用户 A:
iPhone {
设备 ID: 'device-a-iPhone'
用户 ID: '111'
}

iPad {
设备 ID: 'device-a-iPad'
用户 ID: '111'
}
Android {
设备 ID: 'device-a-android'
用户 ID: '111'
}

用户 B:
{
设备 ID: 'device-b'
用户 ID: '222'
}

用户 C:
{
设备 ID: 'device-c'
用户 ID: '333'
}

Group1: [用户 A, 用户 B, 用户 C,]

单聊：

用户订阅自己相关的 topic, 进行接收消息

A 订阅 'user/111/#'
B 订阅 'user/222/#'
C 订阅 'user/333/#'

用户发布消息到别人的 topic ，如 A 发消息给 B：

A 发消息给 B     ----> 发布消息到 'user/222/inbox/111'
A 申请加 B 为好友 ----> 发布消息到 'user/222/application/111'

群聊用户订阅自己加入的群相关的 topic, 进行接收消息

A 订阅topic ----> 'group/1/#'
B 订阅topic ----> 'group/1/#'
C 订阅topic ----> 'group/1/#'

发消息

A 发消息到 Group1 ----> 发布消息到 'group/1/inbox/111'
B 发消息到 Group1 ----> 发布消息到 'group/1/inbox/222'
C 发消息到 Group1 ----> 发布消息到 'group/1/inbox/333'

加群、邀请

A 申请加入群聊 Group1 ----> 发布消息到 'group/1/application/111'
B 邀请 C 加入 Group1 ----> 发布消息到 'group/1/invitation/333/from/222'

接收邀请(注意是接收不是接受)

A 订阅topic ---->  'group/+/invitation/111/from/+'
B 订阅topic ---->  'group/+/invitation/222/from/+'
B 订阅topic ---->  'group/+/invitation/333/from/+'

群主接收申请(注意是接收不是接受)

A 订阅topic ---->  'group/1/application/+'

多设备登录

A-iPhone 设备登录设置 session-id 为 device-a-iPhone 
A-iPad 设备登录设置 session-id 为 device-a-iPad
A-Android 设备登录设置 session-id 为 device-a-Android

登录之前可以判断是否有相关 session，如果没有就创建 session 并进行一遍如上订阅操作，当然也可根据设备进行区别订阅

至此基本的发送和接受就搞定了，关于离线消息第三方送达则需要自己开发插件去处理 session 接收到消息但用户 disconnect 的情况