IoT MQ设计篇：基于开源项目二次开发的坑

概述

在对开源项目进行一些调研后，结合实际情况，我们选择了基于Moquette进行开发，本篇主要从以下两个个维度介绍在二次开发遇到的问题：

1. moquette介绍，为什么选择moquette

2. 从选择到放弃，趟不过去的坑就不趟了吧

moquette

moquette是一个用java和netty实现的mqtt broker，主要特性有以下几点：

1. 基本完整支持了mqtt协议

2. 支持websocket，SSL等协议

3. 支持h2，mapdb数据本地持久化

选择moquette作为研究的开源项目的原因主要有以下两点：

1. Java和netty开发，技术栈很匹配，人力成本比较低

2. 项目比较小，学习成本低，可以借鉴很多处理mqtt协议的思想

从选择到放弃

上面介绍了为什么选择moqutte，在实际开发中，我们基于moquette，基本实现了一个版本，但是在经过测试时，遇到了很多问题：

1. 高可用问题：moquette不支持集群，所以我们要完全自己实现集群，才开始我们的架构是不太想用集中式存储的，所以用hazelcast做了jvm分布式集群，但是性能并不好，并且有的集群功能也没有实现好，在改动方面因为moquette这方面的规划并不是很好，所以对原生代码侵入非常大，改动也很困难

2. 高可靠问题：moquette原生是基于内存的，再采用mapdb持久化后，发现数据量大了之后也有比较多的问题。很多本该基于内存的也持久化了，而且持久化的数据在集群间共享也是个问题

3. 性能问题：我们测试了原生的moquette，单机（4c16g）只能支持6W的长连接，之后的连接就会出错，并且瞬时并发连接数支持的也很低，这块我们经过了大量的优化后（后续会讲具体的优化），性能提高了很多。

4. 功能：moquette是一个没有专门社区维护的项目，所以功能方面只是通用的功能，对于我们很多定制功能都无法满足，比如p2p消息，消息上行到云存储，权限控制，黑名单，设备管理等。这块需要在broker核心改动，导致改动也比较麻烦

综上，是我们在具体实践时遇到的一些问题，后面我们还是选择了自研的方式，但是通过moquette还是学习了很多处理mqtt协议逻辑的思想，放弃moquette的原因主要是扩展实在太困难了，改动非常麻烦，所以不如自己造轮子了。