服务端异常
1）地址冲突，在启动broker时，出现地址已在使用错误
解决方案：修改配置文件里面的listenPort的值，然后重新启动。
2）brokerName不匹配，启动出现异常：broker-b does not match the expected group name: broker-a
问题原因：启动其他Master broker服务时，直接将之前使用过的store目录以及bdb目录复制过来，仅仅只是修改了brokerName，导致此问题出现。
解决方案：2.0以后版本brokerName一旦创建启动后就不能改变，否则只能删除store 目录才能解决。
3）service not available
发送消息一定量的时候，出现 create maped file failed, please make sure OS and JDK both 64bit。或者当topic的队列数位1024个的时候，会出现service not available now, maybe disk full，maybe your broker machine memory too small。
解决方案：使用ulimit-a命令查询系统参数，检查open files是否超过655350，max memory size是为否unlimited，若不是，需要重新根据安装手册的步骤，重新调整系统参数。
4）磁盘空间不足
当磁盘空间大于85%时，会出现“ CODE: 14 DESC: service not available now, maybe disk full, CL: 0.87 CQ: 0.87 INDEX: 0.87, maybe your broker machine memory too small.” 的异常。解决方案：消息中间件有两种策略， 包括数据高安全性与服务高可靠性，分别如下
若磁盘使用率大于85%，策略为数据高安全性，且无过期文件，可以按实际需求，减少数据保存时间来触发消息删除，腾出磁盘空间。
（1）使用updateBrokerConfig命令，修改fileReservedTime属性，此属性为消息保存时间，单位为小时。按需减少保存时间，则可以腾出磁盘空间。
（2）主备都需要同时修改。
5）通过deamon拉起broker时报错
deamon.log日志中报Fail to queryBrokerMaxOffset。
问题原因：
（1）配置文件错误。
（2）做过主备切换，然后手动干预或重启集群，启动进程的地址和角色与zookeeper中 存储的不同，造成启动失败。
（3）上次启动失败后未清理错误数据。
解决方法：
（1）删除zk中该集群的信息
（2）核对配置文件，确保端口和路径有效
（3）删除running目录
（4）重新通过自动部署或者手动部署启动进程
6）消费进度停滞不前
通过consumerProgress命令查询消费进度某些队列无变化，而客户端正在正 常消费。
问题原因：某些队列有消息没有签收，导致服务端消费进度没有后移。
解决方案：通过consumerProgress命令显示的consumer offset找到对应消息，并按如下判断执行：
（1）如果是BDB消费模式，重启应用即可或者通过以下api void com.ctg.mq.api.IMQAckHandler.ackMessageSuccess(String msgID)签收卡住的消息即可。
（2）如果是原生有序消费模式，重启应用即可。
（3）如果是原生无序消费模式，启动一个同消费组的实例，会将该消息签收。
7）删除topic失败
删除topic时出现topic **** is consuming by consumer ****，或者topic *** is publishing by producer ***异常
问题原因：删除topic必须没有生产者和消费者正在订阅该topic（与该topic相关的生产者消费者都必须离线），否则会失败。
解决方案：
（1）可以通过一下方式查看是否还有客户端连接该topic：管理平台->主题管理->详情->生产组|消费组->连接实例。
（2）如果使用命令行删除有序队列，需要使用集群删除，例如：sh mqadmin deleteTopic -n 10.142.90.33:9876 -c mq_cluster -t mytesttopic。
（3）如果使用命令行删除无序队列，可以使用broker删除，例如：sh mqadmin deleteTopic -n 10.142.90.33:9876 -b 10.142.90.33:10911 -t mytesttopic。
8）启动broker时BDB报错
问题原因：可能是迁移了store目录或者更换了broker的组名、地址或端口。
解决方案：删除store目录下的consumeStore目录，重启broker即可解决。
9） 从broker已启动，但clusterList看不到
从broker已启动，但无法加入到集群（clusterList查询不到）
问题原因：
（1）查看/etc/hosts文件，机器名与IP的映射关系是否填写有误。
（2）查看防火墙设置（是否有端口未开放），listenPort 到 listenPort+2的端口都 需要开放（如果主broker的listenPort=10911，那么10911、10912、10913都要开放）
10） 通过命令行创建有序topic，但是web管理台显示的是无序的
通过updateTopic命令，加-o true创建有序topic，但是web端查询的时候 显示是无序的。
问题原因：集群有多个namesrv，但是创建的时候只填了一个namesrv。
解决方案：创建时加上这个broker集群的所有namesrv，中间用分号分割，例如：sh mqadmin updateTopic -n “10.142.90.30:9876;10.142.90.28:9876” -t crmTopic -o true
11）消费者订阅关系不存在
broker.log日志报错，the consumer's subscription not exist, group: consumerAepIdealLogGroup
问题原因：使用同个订阅组，同时消费不同的topic，订阅关系会被覆盖。
解决方案：不能使用同个订阅组的消费组去订阅不同的topic，如果需要变换订阅关系，请关闭旧消费者。
12）使用clusterList查询 主TPS不为0，从TPS一直为0
这种情况最大的可能是从同步出错，可以做进一步的确认，查看store.log或者 stoererror.log，一般会看到有持续的报错信息。这种情况可以删除从的store目录，重新进行同步。
注意：部署有高可用模块或者主的brokerRole=ASYNC_MASTER，否则停止从的时候，生产会报错。
解决方案：
（1）手工停止从broker（kill pid，注意不要加-9，如果自动拉起broker参数设置为true，则需要先关掉从的deamon）。
（2）删除或者备份从的store目录（为保险起见，空间允许的话，可以mv备份，不要直接删除。
（3）手工启动broker（sh sh/broker_*.sh）。
（4）从broker启动完成后，用clusterList查看，可以看到从的TPS比较高，因为正在同步。
13）主broker异常恢复
需要走异常恢复流程的一般是consumequeue生成有问题，导致无法拉取消息（注意 有多种情况会导致无法拉取消息，不一定是consumequeue有问题，注意判断）、根据offset查询报错。
异常恢复流程：
（1）停止需要恢复这一组broker的主从deamon，主从broker。
（2）删除主broker store目录下的checkpoint consumequeue consumeStore index（也可以mv 改下名字来备份）。
（3）检查store目录下的abort文存是否存在，如果不存在新建一个（touch abort）
（4）启动主broker，查看store.log，可以看到打印恢复过程的日志，如果没有报错，说明恢复成功
（5）如果commitlog文件比较多，可能恢复时间较长，可以通过查看store.log或者broker端口是否起来判断恢复是否完成。
（6）主broker起来后，通过消费或者根据offset查询消息来验证是否恢复成功。
（7）如果主broker恢复成功，启动从broker，启动主从deamon。
14）RPC异常（所以服务端组件均可能出现）
问题原因：使用非组件RPC协议访问导致，比如用http协议、或者telnet等，均可导致decode错误。
解决方案：无需解决，应服务端及客户端RPC请求均无影响。
应用客户端
1）连接拒绝Connect faild。
解决方案：当出现这类问题时，检查当前网络并无异常时，并排查下ulimit –a openfiles是否为1024，修改至65535。
2）超时异常RemotingTimeoutException。
服务器端日志出现RemotingTimeoutException：wait response on the channel <10.4.246.198:10911> timeout, 3000ms。
解决方案：这类情况一般由于客户端与服务端通信出现问题，可以ping Ip 以及telnet ip port 来排查这类，同时也要检查防火墙的问题。
3）找不到路由No route info of this topic。
问题可能原因：
（1）没创建topic。
（2）name server填错了。
（3）网络问题无法获取路由。
解决方案：
（1）在管理台创建topic。
（2）检查客户端配置的namesrv的地址是否配错了。
（3）检查网络是否正常。
4）备不可用SLAVE_NOT_AVAILABLE
当生产者发送消息时，出现“status:SLAVE_NOT_AVAILABLE”，说明从节点 发生状况
解决方案：
（1）从节点机器出现问题，重启从节点，并查看网络连接.
（2）在多网卡情况下，broker配置文件properties中，需增加配置项，例：
brokerIP1=10.4.246.130
brokerIP2=10.4.246.130
（3）防止网卡ip读取错误，取不到从节点信息。
5）消息体大小越界
客户端报此类异常Fail to send message, for: message body size over max message size, max: 524288
解决方案：
（1）检查服务端的最大消息体大小，即启动broker配置文件的maxMessageSize大小，如未配置，默认是512K。
（2）检查客户端设置的最大消息体(默认128k)是否小于当前发送的消息体大小。
注意：ROCKETMQ建议消息体在50K或以下(压缩后)。
6）组名已经创建
当消息生产端/消费端运行时，报错The producer/consumer group has been created
问题原因：在同一个jvm里面只允许一个producerGroupName被加载一次 （consumerGroupName同理），否则就会报错。
解决方案：
（1）如果使用同一个producerGroupName，部署多个实例（起多个进程）。
（2）在一个进程里，起多个线程，共用一个Producer对象实例。
7）Subscription group not exist或者抛出%retry%的topic没有路由信息
问题原因：没有建立消费关系或者没有创建相关订阅组。
解决方案：在管理台或命令行创建对应订阅组。
8）Messgae already acked，ackMessage failed
解决方案：这种异常表明该消息已被签收，直接跳过即可。
9）重试签收调用次数
ackMessageRetry重试签收是只需要调一次就够了，还是需要调多次。例如， 签收失败后，调用重试签收，如果重试签收也失败，是否需要再次调用重试签收，还是会自动重试签收。
现有版本接口不会自动帮你重试签收的， 重试签收失败后，需要自己再次调用 重试签收接口。
10）签收时出现不确定异常，如发生超时，或者网络异常时，是需要应用判断消息是否已经签收成功。
解决方案：
（1）通过管理台“即时查询”模块，查询这消息是否已经签收成功，看结果再做处理，
（2）重试签收，如果已经签收会抛已签收异常。主要还是看应用的自己处理
11）客户端注册失败
客户端日志报No matched consumer for the PullRequest PullRequest。
问题原因：客户端实例注册失败
解决方案：检查客户端代码，重启客户端进程。
12）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队列数量。
13）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。
问题原因：
（1）在关闭生产者实例的同时用生产者实例发送消息，连接关闭了netty会拒绝请求。
（2）线程少，处理发送请求过慢。
解决方案：
（1）应用优化使用流程，禁止在close生产者实例后使用生产者。
（2）如果Broker是同步主，那么改成异步主，或者将 sendMessageThreadPoolNums=32且waitTimeMillsInSendQueue=1000。
14）消费者消费不到消息如何处理
进入控制台查看订阅管理菜单，检查订阅组是否有消费实例在线，如果不在线检查消费客户端日志是否有连接异常。
检查消费客户端逻辑，是否存在订阅关系不一致的情况。
15）消费者机器宕机重启是否会造成消息丢失
RocketMQ的消息数据以及订阅信息都是持久化保存的，当消费者下线重新上线后，会Broker持久化的下线前的消费偏移重新开始消费，所以不会发生消息丢失的情况。
16）订阅消息时是否可以允许消息Tag为空
订阅主题时如果Tag设置为空会导致消费者消费不到消息，如不希望通过Tag进行消息过滤，可以将Tag设置为*，示例如下：
consumer.subscribe(topic, "*");
17）客户端连接时出现“signature validate by dauth failed”错误
这种错误的原因一般是由于ACL认证失败，较大的可能是客户端配置的AccessKey和SecretKey出现错误，可以检查下这两项配置是否输入有误。