msg: emqx_connection_terminated, reason: {shutdown,message_queue_too_long}
message_queue_too_long 这个可以明确的说明消费能力跟不上。
你可以通过下面的配置来调高queue的长度，但是这也只能延缓积累的，积累超多，消耗的内存越多，直到你的内存用完。
force_shutdown {
max_message_queue_len = 10000 # 他默认是1000，或者不限制就设置为infinity
}
500 个设备每秒发一个json，那么总的流入才500 消息/秒。对EMQX来说，应该是很轻松的。你可以简化你的消费端，让他收到消息就只打印一下，不要处理。先看看会不会有问题。
消费端过多也不行： 这个需要更详细的日志看是否有其它异常，目前信息太少，无法定位。
问题3关于共享订阅的，不太理解。可以展开说说么。
麻烦提供一下 EMQX 当时的日志，客户端根据你使用的库和自己定的代码有关系。我们无法定位 
麻烦提供一下在emqx日志文件的日志，在log/emqx.log.1 这样的上当，这里有全部异常的日志，日志追踪只有部分的，现在看你这个日志追踪的日志里面也没有异常信息。
这日志里面每一条都在提示你消费端太慢了。好多消息积累。。。
我不清楚你是怎么写消费端的。如果真的是生产者只有500消息/秒。那消费的你是不是有sleep在。。导致了很慢。
为了排查问题，你可以简化一下消费端，收到消息只计个数。打印一下。看看是什么情况。
我用node-red测试也是一样的，根本不需要写代码 ，broker还是踢
node-red 可以拖拉直接生成消费节点，我搞了两个，其中一个也是频繁被踢出
