一：项目背景
公司业务发展需要，引入了mqtt推送服务；基于快速实现上线背景，mqtt服务未自己实现，使用的阿里云提供的组件服务；需要对一定基准配置下案例云mqtt推送服务能力评估，给业务技术方案参考。
二：压测方案
分析：
核心场景：建立指定X连接数，在不同的msg字节大小；评估mqtt推送能力并统计msg整条链路上响应时间符合业务使用场景。
mqtt组件能力评估：
1.评估MQTT瞬间的连接能力；
2.评估MQTT服务消息的吞吐量；
3.找到符合业务场景使用的吞吐量最佳点；
4.业务场景一租户两个收银台场景覆盖；
5.MQTT稳定性与弱网。
三：工程开发
基于对压测需求对梳理整理，工程开发需要包含三个部分内容：
1.初始化数据；-- 注册生成有效token，建立mqttl连接与对应topic关系，从业务调用量该部分不拉入压测范围；
2.建立连接并保持在线，统计推送msg 数量与响应时间；
3.消息发送 -- 消息发送与推送的关系 1:N，具体N看业务使用场景，--这部分由于项目保密不过细阐述
其中1，3两个部分都是http服务；常规脚本开发就完毕，但是send msg部分需要 埋点时间；
核心部分2开发：要保持分布式部署且利用机器多核资源。
语言选择：推荐go
由于时间问题，此次压测实现还是基于在locust python 去实现，但是建立连接且保持在线使用locust自带协程；这里强烈不建议用python&java多线程去做，特别是python多线程。
由于需要支持分布式部署且需要保持同一个参数在分布式节点只能有效执行一次；如果同一个连接参数只能保持一个在线，之前在线会被服务端关闭。
消费消息统计：消息消息总量与整个消息从发送到收到响应时间。
-- 脚本内容：
（由于格式问题，无法在旧文章中粘贴code；新建一个文章链接）
四：执行过程
-- 略
五：其它
MQTT基础能力：
1.mqtt.客户端瞬间开启2500个连接, ALL连接差不多20S全部成功连接；
2.mqtt目前最大吞吐量大概在15MB/s左右，主要包含msg字节大小*每秒消息推送处理能力；
-- 项目使用场景msg大小可能会在5kb~10kb之间，要保持业务在1～3s响应，mqtt推送的处理能力qps维持在 2000～1000的水平。
3.mqtt最佳业务支持点：
保持300连接在线，msg字节数大小1239，每秒推送10295条消息；整体消息响应时间在360ms；最大值在1s~3s内。
保持300连接在线，msg字节大小735，每秒推送20815.6条消息，整体消息响应时间在210；最大值在1s~3s内。
保持700连接在线，msg字节大小735，每秒推送19428.5条消息，整体消息响应在300，最大值在1s~3s内；
保持300连接在线，msg字节大小5537 ,每秒推送1800条消息，整体消息响应在1000，最大值在1s~3s内；
保持300连接在线，msg字节大小9874 ,每秒推送800条消息，整体消息响应在1100，最大值在1s~3s内。
4.mqtt吞吐量从连接数*msg大小*msg推送能力三个维度，不管在300、700、1200、1500、2900连接数场景下固定的msg大小mqtt服务msg推送qps几乎保持不变。
