如何开启ipv6访问？
在开通实例时，您需要选择已开启ipv6的VPC与子网，并打开ipv6开关。开通完成后，将自动为实例分配ipv6地址。您可登录实例控制台获取ipv6连接地址，可通过IPv6地址段访问实例。
应用客户端
连接拒绝Connect faild
解决方案：当出现这类问题时，检查当前网络并无异常时，并排查下ulimit –a openfiles是否为1024，修改至65535。
超时异常RemotingTimeoutException
服务器端日志出现RemotingTimeoutException：wait response on the channel < 10.4.246.198:10911 > timeout, 3000ms。
解决方案：这类情况一般由于客户端与服务端通信出现问题，可以ping Ip 以及telnet ip port 来排查这类，同时也要检查防火墙的问题。
找不到路由No route info of this topic
问题可能原因：
- 没创建topic。
- name server填错了。
- 网络问题无法获取路由。
解决方案：
- 在管理台创建topic。
- 检查客户端配置的namesrv的地址是否配错了。
- 检查网络是否正常。
备不可用SLAVE_NOT_AVAILABLE
当生产者发送消息时，出现“status:SLAVE_NOT_AVAILABLE”，说明从节点发生状况。
解决方案：
- 从节点机器出现问题，重启从节点，并查看网络连接。
- 在多网卡情况下，broker配置文件properties中，需增加配置项，例如：brokerIP1=10.4.246.130，brokerIP2=10.4.246.130
- 防止网卡ip读取错误，取不到从节点信息。
消息体大小越界
客户端报此类异常Fail to send message, for: message body size over max message size, max: 524288。
解决方案：
- 检查服务端的最大消息体大小，即启动broker配置文件的maxMessageSize大小，如未配置，默认是512K。
- 检查客户端设置的最大消息体(默认128k)是否小于当前发送的消息体大小。
注意：ROCKETMQ建议消息体在50K或以下(压缩后)。
组名已经创建
当消息生产端/消费端运行时，报错The producer/consumer group has been created。
问题原因：在同一个jvm里面只允许一个producerGroupName被加载一次 （consumerGroupName同理），否则就会报错。
解决方案：
- 如果使用同一个producerGroupName，部署多个实例（起多个进程）。
- 在一个进程里，起多个线程，共用一个Producer对象实例。
Subscription group not exist或者抛出%retry%的topic没有路由信息
问题原因：没有建立消费关系或者没有创建相关订阅组。
解决方案：在管理台或命令行创建对应订阅组。
Messgae already acked，ackMessage failed
解决方案：这种异常表明该消息已被签收，直接跳过即可。
重试签收调用次数
ackMessageRetry重试签收是只需要调一次就够了，还是需要调多次。例如：签收失败后，调用重试签收，如果重试签收也失败，是否需要再次调用重试签收，还是会自动重试签收。
现有版本接口不会自动帮你重试签收的， 重试签收失败后，需要自己再次调用重试签收接口。
签收时出现不确定异常，如发生超时，或者网络异常时，是需要应用判断消息是否已经签收成功
解决方案：
- 通过管理台“即时查询”模块，查询这消息是否已经签收成功，看结果再做处理。
- 重试签收，如果已经签收会抛已签收异常。主要还是看应用的自己处理。
客户端注册失败
客户端日志报No matched consumer for the PullRequest PullRequest。
问题原因：客户端实例注册失败。
解决方案：检查客户端代码，重启客户端进程。
the consumer message buffer is full, so do flow control
客户端日志出现the consumer message buffer is full, so do flow control
问题原因：push客户端消费过慢，本地缓存队列已满，暂时停止向服务端拉取消息。消费慢的原因可能是网络原因、topic队列数过多、消费者过少，内存过小等。
解决方案：
（1）查看网络是否异常，缓慢。
（2）增加消费者实例。
（3）如果消息不重要，又不方便增加消费者实例，可以减少topic队列数量。
system busy, start flow control for a while
客户端日志出现 [REJECTREQUEST]system busy, start flow control for a while 或者 [PCBUSY_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue。
问题原因：
- 在关闭生产者实例的同时用生产者实例发送消息，连接关闭了netty会拒绝请求。
- 线程少，处理发送请求过慢。
解决方案：
- 应用优化使用流程，禁止在close生产者实例后使用生产者。
- 如果Broker是同步主，那么改成异步主，或者将 sendMessageThreadPoolNums=32且waitTimeMillsInSendQueue=1000。
消费者消费不到消息如何处理
进入控制台查看订阅管理菜单，检查订阅组是否有消费实例在线，如果不在线检查消费客户端日志是否有连接异常。
检查消费客户端逻辑，是否存在订阅关系不一致的情况。
消费者机器宕机重启是否会造成消息丢失
RocketMQ的消息数据以及订阅信息都是持久化保存的，当消费者下线重新上线后，会Broker持久化的下线前的消费偏移重新开始消费，所以不会发生消息丢失的情况。
订阅消息时是否可以允许消息Tag为空
订阅主题时如果Tag设置为空会导致消费者消费不到消息，如不希望通过Tag进行消息过滤，可以将Tag设置为*，示例如下：
consumer.subscribe(topic, "*");
客户端连接时出现“signature validate by dauth failed”错误
这种错误的原因一般是由于ACL认证失败，较大的可能是客户端配置的AccessKey和SecretKey出现错误，可以检查下这两项配置是否输入有误。
