布景

测试demo安装emqx时，首先考虑的功能性测试，并没有考虑太多的安全性需求，因而，emqx敞开的是匿名办法，现在要上生产环境，需要选用用户认证的办法。

现象

emqx按照原先的办法布置，敞开了匿名校验，设置了用户认证办法，emqx管理界面plugins中也敞开了用户认证插件，可是重新启动渠道时，一向报错：mqtt user authorization is refused the collection,即用户无权衔接，可是使用MQTT客户端衔接认证成功，能够衔接上，所以乎问题有点盘旋了。

处理办法

1、防火墙敞开所有有关MQTT衔接的端口

问题出现的第一反应是客户端衔接不到认证服务器，所以服务器大将所有有关mqtt衔接的端口全部敞开出来，重启了渠道，可是问题仍然在。

2、代码排查

考虑道路：

（1）MQTT客户端能够衔接，可是渠道衔接认证不通过，同样恳求的是1883的端口，那么说明1883自身端口没有问题；

（2）那么问题可能出现在代码用户认证上，查看了一下SpringBoot中的yaml文件，有关mqtt的装备，发现是正确的；

（3）那么就有一种可能，在恳求1883端口时，用户认证信息并没有正确携带

（4）所以乎找到问题根源了
查看了代码创立mqtt衔接的办法，仅仅使用了url和主题，而用户信息并没有正确创立，所以定位到问题根源了

（5）处理问题

public MqttConnectOptions getMqttConnectOptions() {
    MqttConnectOptions options = new MqttConnectOptions();
    options.setUserName(username);
    options.setPassword(password.toCharArray());
    options.setServerURIs(new String[]{url});
    options.setConnectionTimeout(completionTimeout);
    return options;
}
@Bean
public MqttPahoClientFactory mqttClientFactory() {
    DefaultMqttPahoClientFactory factory = new DefaultMqttPahoClientFactory();
    factory.setConnectionOptions(getMqttConnectOptions());
    return factory;
}
@Bean
public MessageProducerSupport mqttInbound() {
    MqttPahoMessageDrivenChannelAdapter adapter = new MqttPahoMessageDrivenChannelAdapter(clientId,mqttClientFactory(), topic);
    adapter.setCompletionTimeout(completionTimeout);
    adapter.setConverter(new DefaultPahoMessageConverter());
    adapter.setQos(1);
    adapter.setOutputChannel(new DirectChannel());
    return adapter;
}

上面就是修改后的关键代码，主要是在将用户信息填充到衔接特点中，并使用工厂形式创立了一个通道适配器，这样程序启动时便会初始化这些bean，实现与MQTT服务器的衔接并监听装备进去的主题。

至此这个填坑过程完成。

总结

排查问题看日志很重要，可是学会正确的剖析日志文件也是需要经验以及正确思路剖析的，假如对MQTT的一些常用端口号了解多一些，刚开始就不会认为是端口号的问题了，多走了两步弯路，今后要注意。