1.如何解决IO问题？

JMQ没有采用AMQ通过自己开发重复造轮子的方式解决IO问题，而是使用了Netty4.0，此框架开源，支持epoll，编程模型相对简单。这在一定程度上减少了服务端的开发工作，也降低了服务端的复杂度。

在应用层，我们自定义了JMQ协议，序列化和反序列化也完全自己开发。这种序列化反序列化方式虽然在一定程度上降低我们的开发效率，但我们不用考虑如果采用第三方的序列化和反序列化方案会带来的性能损耗问题，对于性能上的提升是显而易见的。

2.如何存储消息？

JMQ存储分为日志文件(journal)和消息队列文件(queue)以及消费位置文件(offset)都存储在Broker所在机器的本地磁盘上。

日志文件，主要存储消息内容，包括消息所在队列文件的位置，有以下特点：

a. 同一broker上不同topic消息存储在同一日志文件上，日志文件按固定大小切分；

b. 文件名为起始全局偏移量；

c. 消息顺序追加。

d.日志文件同步刷盘

由于JMQ主要使用在可靠性要求极高的下单、支付等环节，所以broker必须保证收到的每条消息都落到物理磁盘，这样一种日志文件设计主要是为了提高多topic大并发下磁盘的写性能。不仅限于模型的设计，为了提高写性能我们在逻辑上还实现了Group commit。下图是JMQ中Group Commit基本示意图：

图5：Group commit 示意图

消息队列，主要存储消息所在日志文件的全局偏移量，此文件有以下特点：

a.同一broker上不同topic的队列信息存储在不同的队列文件上，队列文件按固定大小切分;

b.文件名为全局偏移量；

c.索引顺序追加；

d.队列文件异步刷盘。

由于在日志的写入是单线程的，那我们在写入之前就可以提前获取到消息在队列文件的位置，并将这个位置写入到在日志文件当中。所以只要日志文件写成功，即便队列文件写失败，我们也能从日志文件中将队列恢复出来，因此队列文件采用异步刷盘。

图6：日志文件和队列文件模型

消费位置文件：

消费位置文件主要用于存储不同订阅者针对于某个topic所消费到的队列的一个偏移量。

下图简单描述了消息在服务端的流转过程：

图7：消息流转示意图

3.如何容灾？

说到容灾，我们上一节谈到了每条消息在broker上都会落地，但这远远不够，我们必须要保证单机失效甚至机房失效的情况下数据还能被恢复，所以我们需要的一套完整的方案来进行数据灾备。在AMQ里采用的是一主一从，主从分布在一个数据中心，主从同步复制这样的方案。

JMQ里我们实现了一套全新的复制方案：采用一主一从，至少一个备份，主从分布在同一个数据中心、备份分布在其他数据中心，主从同步复制、备份异步复制这样一种方式进行数据灾备。主从同步复制这样就保证了同一条消息我们至少有两个完整备份，即便一个备份丢失，我们还有另一个备份可用。备份节点就保证了极端情况下即使整个数据中心挂掉，我们绝大部分的消息还能得以恢复；

图8：JMQ复制模型

4.Push or pull？消息如何路由？

JMQ采用pull模式，也就是消息由producer发送到broker之后是由consumer主动发起请求去broker上取消息。

发送者的路由和AMQ客户端采取的策略基本相同。

消费者路由和AMQ差不多也是随机，不同点在于JMQ是拉模式，在Broker采取长轮询策略。

5.如何处理消费失败的消息？

与AMQ不同，由于JMQ 的broker直接就支持重试，在Consumer在处理消息失败时直接向服务端发送一个重试消息命令，服务端接到到命令后将此消息入库。随后在consumer发起拉取消息命令时，服务端再根据一定的策略从库里将消息取出，返回给consumer进行处理。这样做带来一个好处就是JMQ客户端减少了一个第三方服务依赖。

6.如何记录消息轨迹？

JMQ消息轨迹功能整体流程和AMQ基本相同，主要不同点在于JMQ将消息轨迹相关信息存储到HBase，这样JMQ消息轨迹信息的存储周期变的更长，可以存储的量也更大了，并且采用多种手段优化之后性能也得到了极大的提升。

7.如何管理元数据？

通过第一部分我们知道，AMQ的元数据会持久化在MySQL，并在入库的同时写入ZooKeeper，由ZK再下发到Broker和客户端。这样就有两个问题：

a.客户端引入了ZooKeeper这个第三方服务，引入服务越多那客户端稳定性和可维护性就越差。

b.注册中心也就是ZooKeeper直接暴露给了客户端，这样就会导致注册中心的连接数越来越多在出现故障时缺乏必要的手段对注册中心进行保护。

在JMQ中我们依然利用MySQL来持久化元数据，同时也会将元数据写入ZooKeeper，ZooKeeper再通知到Broker，但客户端不再直接连接ZooKeeper，而是转而连接Broker，从Broker上获取元数据信息。由于每个Broker都有全量的元数据信息，所以客户端端连接任意的Broker都能获取到元数据信息。这种设计就带来了几个好处：

a.减少了客户端对ZooKeeper服务的依赖，至此我们客户端就只需和broker通信，客户逻辑得到了简化，客户端稳定得到了极大提升。

b.ZooKeeper不再暴露给客户端，这样ZooKeeper的稳定性也有了保证。

c.由于连接任意一个Broker都能获取到元数据，极端情况下即便有个别broker宕机也不影响客户端获取元数据，所以从另外一个角度来看这又提高了我们注册中心的可用性。

8.其他。

除了以上提到的一些基本问题之外，我们还解决了很多问题，由于篇幅问题就

不一一在此罗列说明，其中包括但不限于：

a. 如何实现严格顺序消息；

b. 如何实现广播消息；

c. 如何实现两阶段事务；

d. 如何实现消息回放。

下面是JMQ的一个粗略整体架构图：

图9：JMQ架构图

JMQ性能数据

测试所用机器情况：

场景1：一主一从，Master同步刷盘+同步复制到Slave

场景2：一主一从，Master异步刷盘+异步复制Slave

JMQ规模

Topic数量：1000+

接入应用数量：2500+

单日消息入队数量：500亿+