基本需求

支持mqtt3.1 / mqtt3.1.1 ,可选mqtt5.0协议
3.1和3.1.1是常见的协议版本，5.0普及可能还要一段时间。
支持QOS0、QOS1可选QOS2
各大厂商至少都支持 QOS1，保证消息必达
支持遗嘱信息：即设备异常断开后通知后端服务或者其他设备处理

支持持久化：比如QOS1的消息，设备因为网络原因接收不到或者异常断线，需要把未发送的信息保存在session中

支持多种连接方式
MQTT over TCP: 最基本的连接方式
MQTT over Webscoket: 基于Websocket连接的MQTT
MQTT over TCP/SSL: 基础连接之上做了加密，一般采用TLS加密
MQTT over Websocket/SSL: 基于Websocket的加密连接，一般SSL采用TLS


集群支持
海量连接，session持久化 
集群信息共享，可以保证某个节点宕机时功能还能正常使用，但是未发送的信息可能会丢失。

自定义权限验证
连接阶段是否允许连接
发送阶段判断是否允许发送
订阅阶段是否允许订阅
大部分开源Broker只支持userName和Password的验证。ClientId和Ip不一定支持


自定义验证方式

验证客户端的合法性有三点：CONNECT阶段验证是否允许连接、PUBLISH阶段验证是否允许发布、SUBSCRIBE阶段验证是否允许订阅。

CONNECT阶段需要验证ClientID、Username、Password、IP四项，不过大部分开源Broker都只支持Username和Password的验证。

PUBLISH、SUBSCRIBE的验证的目的是防止非法客户端订阅别人的主题，向别人的主题发布消息。
但每台设备每次订阅、发布都要验证一次 并发高，需要设计Cache和高效查询机制。





可选需求

保留信息
保留信息就是主题会依照QOS级别保留最后一条消息，当有新的订阅时会发送这条消息
主要应对订阅之后不知道第一条信息何时会发送的情况。
如获取设备状态，设备如果不发送信息新加进来的管理端就无法获得状态信息，不知道如何显示。
如果这个时候有一条保留信息，就能够知道当前设备状态。
开销较大，每次订阅主题都需要检查有没有保留消息。




功能层面

1. 能对接入的客户端进行管理，包括统计，监控流量，强制下线，数据传输等
2. 能对集群，broker主机进行监控等
3. 能将数据上云进行分析，主要是通过桥接RocketMQ等上行到其它存储平台进行数据分析等

系统层面
1. 服务高可用：不能有单点故障等问题，支持集群部署，数据必须有一定可靠性，不能出现数据大量丢失的情况
2. 高连接高请求：高性能，不过要求单机（4c16g）要支持十万级以上的连接，并且消息TPS要高，同时支持低延时
3. 高可扩展性：架构总是演进的，需求也一直在变，才开始的IoT MQ的设计只满足了最低的需求，所以必须要是高可扩展性的，例如可桥接其它数据平台等
4. 安全：物联网一定是公网的，所以需要考虑传输加密以及权限验证等安全，要实现TLS/SSL以及权限验证等
5. 规模：初始规模一般预估为真实需求的2到5倍，初始评估长连接设备数20W，消息大小为200byte的消息的TPS至少达到10000，响应时间在100ms内
6. 成本：集群部署为了节省主机成本所以单机性能有一定要求，人员方面技能储备以java为主




IoT MQ设计篇：开源or自研，系统复杂度分析
https://www.yuque.com/tristan-ku8np/zze/oht90h