这里，简单记录一下自己在最近项目中遇到的paho的心得，这里也涵盖EMQX的问题。
1. cleanSession
这个标识，是确保client和server之间是否持久化状态的一个标志，不管是client还是server重启还是连接断掉。下面是来自paho客户端源码的注释。
Sets whether the client and server should remember state across restarts and reconnects.
- If set to false both the client and server will maintain state across restarts of the client, the server and the connection. As state is maintained:
- Message delivery will be reliable meeting the specified QOS even if the client, server or connection are restarted.
- The server will treat a subscription as durable.
- If set to true the client and server will not maintain state across restarts of the client, the server or the connection. This means
- Message delivery to the specified QOS cannot be maintained if the client, server or connection are restarted
- The server will treat a subscription as non-durable
1）。 这个标志位，设置为true，那么，当连接断掉，例如，调用EMQX的接口踢掉连接，此时，即便重连上了（无论是通过autoconnect设置为true，还是在connectonLost这个回调函数里面配置上重连的逻辑），MQTT客户端程序都是无法进行重新订阅数据的。这个行为，说明session里面保存了会话所采用的topic信息。
2）。这个标志位，设置为true，autoconnect设置为false，在connectLost这个回调函数里面，自行实现重新连接的逻辑，并且再次针对相同的topic和qos进行订阅的话，当连接被踢掉，这个时候，会重新连接上，并且也会订阅上数据，只是会出现很奇怪的现象，CPU占用率比连接断开前提高很多。 我的应用（订阅到数据后，对数据进行相应的逻辑处理，正常情况下，一条数据大概1~5ms处理完）压测环境下，连接未断前，1.3W的并发，CPU空闲率在40%左右，重连之后，CPU的空闲率只有10%左右，这个地方是个大坑，目前我还没有搞清楚到底是什么原因导致，若有人遇到类似问题同仁，请给我留言，告知可能的原因。（我的paho是1.2.0版本，EMQX：V3.1.1）
3）。这个标志位，设置为false，autoconnect设置为false，在connectLost这个回调函数里面，自行实现重连的逻辑，但是不对topic进行重新订阅，即便连接断掉，重新连接上的话，依然会进行连接断开之前的业务逻辑，订阅到所需的数据，CPU的负荷也不会变大，基本和断开之前的状态持平。
下面配上connectLost这个回调函数（MqttCallback接口的一个方法）相关代码：
public void connectionLost(Throwable cause) { // 连接丢失后，一般在这里面进行重连 System.out.println(">>>>>>>>>>>>>>>" + cause.getMessage()); System.out.println("连接断开，可以做重连"); for (int i = 0; i < 3; i++) { if(reconnect()) { break; }else{ try { Thread.sleep(i * 2); } catch (InterruptedException e) { e.printStackTrace(); } } } } private boolean reconnect() { try { mqttClient.connect(mqttConnectOptions); Thread.sleep(100); if( mqttClient.isConnected() ) { //mqttClient.subscribe(this.topic, 0); return true; } } catch (MqttException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } return false; }
2. EMQX的承压能力
网上标榜EMQX单节点处理能力多么牛逼，100W连接毫无压力，这个数值，其实呢，我觉得要仔细看测试场景，单单看连接数，其实没有什么意义，要看生产者消费者都存在的情况下，还有数据流通这种场景，连接能力或者数据处理能力如何。 我不是说100W连接能力是虚构的，我是想说纯粹的连接其实没有多大的价值，因为EMQX是消息总线，只有连接，不存在数据流动，有多大意义呢？
还是接着我上面的应用压测，我们团队开发的一个规则引擎，1.6W的消息并发（4000设备，每个设备每秒4条消息，当然是程序模拟出来的），规则引擎4C16G的服务器2台，每台跑3个实例，共享订阅两个EMQX节点（EMQX是集群），EMQX服务器配置4C16G。结果跑不了多久时间（1个小时不到，有时半个小时），就会出现EMQX平凡踢掉消费者连接的情况。
2019-09-19 14:22:42.710 [error] 0ba45c9872464c609c150f156e3f2a7e@10.95.198.25:52388 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:22:55.746 [error] 4014030aed1642bba6ecec85debed172@10.95.198.26:60404 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:23:08.131 [error] dde7f075ab2d45fdabfd192b5c6a4a30@10.95.198.25:52394 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:23:14.374 [error] 72a25aca01164c8c8b4cf48451c4e316@10.95.198.25:52456 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:23:41.686 [error] cd56963bfb4e4c0c8275abe9a24078de@10.95.198.26:60462 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:23:52.638 [error] 4014030aed1642bba6ecec85debed172@10.95.198.26:60514 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:24:06.015 [error] dde7f075ab2d45fdabfd192b5c6a4a30@10.95.198.25:52496 [Connection] Shutdown exceptionally due to message_queue_too_long 2019-09-19 14:24:13.541 [error] 0ba45c9872464c609c150f156e3f2a7e@10.95.198.25:52474 [Connection] Shutdown exceptionally due to message_queue_too_long
针对这个问题，我咨询过青云的EMQ团队的工程师，也在Github上咨询过EMQX的维护者，都反馈说是消费者处理速度太慢，emq的消息队列消息堆积导致。现象如此，怎么解决呢，似乎只能添加消费者服务，或者降低消息压力，EMQX能否提升性能呢？我觉得EMQX现在共享订阅的能力不行，就这4000个连接投递消息，1.6W的并发，4000个topic，采用共享订阅的方式，性能感觉不是很好，是我们程序设计的有问题，还是EMQX共享订阅性能真的有待提升？为什么这么说能，我们测试过非共享订阅，就是明确订阅某个指定topic。非共享订阅情况下，相同的服务器上，比共享订阅性能好很多很多（差不多一半）。。。（欢迎探讨）
从EMQX的配置中，针对上面这种消息队列太长的问题，emqx.conf的配置文件中有相关信息，参考下面这个错误找到了相关的配置参数，EMQX的官方参数解释或者支持真心跟不上，没有国外开源组织社区营造的好，这个需要努力。
2019-09-19 14:22:30.362 [error] f2ac199b0314449d822e150c8d51de93 crasher: initial call: emqx_session:init/1 pid: <0.20141.1> registered_name: [] exception exit: killed in function emqx_session:handle_info/2 (src/emqx_session.erl, line 641) in call from gen_server:try_dispatch/4 (gen_server.erl, line 637) in call from gen_server:handle_msg/6 (gen_server.erl, line 711) ancestors: [emqx_session_sup,emqx_sm_sup,emqx_sup,<0.1386.0>] message_queue_len: 0 messages: [] links: [<0.1577.0>] dictionary: [{force_shutdown_policy, #{max_heap_size => 838860800,message_queue_len => 8000}}, {deliver_stats,676193}, {'$logger_metadata$', #{client_id => <<"f2ac199b0314449d822e150c8d51de93">>}}] trap_exit: true status: running heap_size: 6772 stack_size: 27 reductions: 69920965 neighbours:
再看看emqx.conf的配置文件中，和这个queue相关的配置：
## Max message queue length and total heap size to force shutdown ## connection/session process. ## Message queue here is the Erlang process mailbox, but not the number ## of queued MQTT messages of QoS 1 and 2. ## ## Numbers delimited by `|'. Zero or negative is to disable. ## ## Default: ## - 8000|800MB on ARCH_64 system ## - 1000|100MB on ARCH_32 sytem ## zone.external.force_shutdown_policy = 8000|800MB
有人会说，你可以将这里的消息数量调大点啊，没错，这个调一下是可以改善，但是不能根治问题，自己想想吧，大点最多也就是对消息速率波动的韧性加大了，但是不能解决持续生成高于所谓的消费慢这种情况下的问题。 EMQ方说辞其实，在我们的这个场景下，我是不那么认同的，为什么这么说呢， 我的规则引擎消费日志里面显示，每条消息处理的时间并没有变长，CPU的忙碌程度并没有恶化， 添加共享订阅实例变多，EMQX性能下降了，我觉得EMQX在共享订阅变多的情况下，对消费者端投递消息的速率或者效率下降了，但是呢，EMQX这个broker从消息生产者这边接收消息的能力没有改变，导致EMQX的消息队列消息积压，最终出现踢连接的policy得以执行。。。
还有一个问题，不知道细心的读者有没有发现，消费者这边消息消费的好好的，消息积压了，EMQX为何要把消费者的连接给踢掉呢，为何不是将生产者的连接踢掉呢？这个逻辑我觉得有点不是很好理解，本来消息就积压了，是不是要加快消费才能缓解或者解除消息积压的问题？读者你们是如何理解的，也可以留言探讨！
