前言¶

全异步架构:

EMQ 消息服务器是基于 Erlang/OTP 平台的全异步的架构：
  异步 TCP 连接处理、
  异步主题(Topic)订阅、
  异步消息发布
只有在资源负载限制部分采用同步设计，比如
  TCP 连接创建、
  Mnesia 数据库事务执行
一条 MQTT 消息从发布者(Publisher)到订阅者(Subscriber)，在 EMQ 消息服务器内部异步流过一系列 Erlang 进程 Mailbox:
                  ----------          -----------          ----------
Publisher --Msg-->| Client | --Msg--> | Session | --Msg--> | Client | --Msg--> Subscriber
                  ----------          -----------          ----------

消息持久化:

EMQ 1.0 版本不支持服务器内部消息持久化
EMQ 2.0 版本将发布 EMQ X 平台产品，支持消息持久化到 Redis、Kafka、Cassandra、PostgreSQL 等数据库

首先，EMQ 解决的核心问题是连接与路由；
其次，我们认为内置持久化是个错误设计。

广泛使用的 JMS 服务器 ActiveMQ，几乎每个大版本都在重新设计持久化部分
Kafka 在上述问题上，做出了正确的设计：一个完全基于磁盘分布式 Commit Log 的消息服务器

内置消息持久化在设计上有两个问题:
1.如何平衡内存与磁盘使用？消息路由基于内存，消息存储是基于磁盘。
2.多服务器分布集群架构下，如何放置 Queue 如何复制 Queue 的消息？

NetSplit问题:

EMQ 1.0 消息服务器集群，基于 Mnesia 数据库设计
NetSplit 发生时，节点间状态是：Erlang 节点间可以连通，互相询问自己是否宕机，对方回答你已经宕机:(

NetSplit 故障发生时，EMQ 消息服务器的 log/emqttd_error.log 日志，会打印 critical 级别日志:

Mnesia inconsistent_database event: running_partitioned_network, emqttd@host
EMQ 集群部署在同一 IDC 网络下，NetSplit 发生的几率很低，一旦发生又很难自动处理。所以 EMQ 1.0 版本设计选择是，集群不自动化处理 NetSplit，需要人工重启部分节点。