（二）借助arthas排查生产RocketMq报SLAVE_NOT_AVAILABLE异常问题

平台迁移到云平台后，交易逐步恢复正常，在日常监控业务情况时，发现一个业务突然出现大量异常，本文记录排查过程。

1. 发现问题

下图红色部分，为大量报出异常的应用，排查发现，错误出现在处理交易通知的时候。在系统收到通知后，回继续逻辑，然后将结果放入MQ中，由通知系统下发给商户。问题就出在消息写入MQ的结果上，代码中判断写入状态为 SendStatus.SEND_OK时，写入成功，但是现在执行了异常流程，更奇怪的是，后续业务并没有受影响。

image.png

2. 分析与排查

现在知道了以下前提：

• MQ写入状态不是：SendStatus.SEND_OK
• 后续业务正常，说明消息实际是写入成功了

2.1 RocketMq的投递状态

• FLUSH_DISK_TIMEOUT
  如果 Broker 设置MessageStoreConfig的FlushDiskType=SYNC_FLUSH(默认是ASYNC_FLUSH)，并且代理没有在MessageStoreConfig的syncFlushTimeout(默认是5秒)时间内完成刷盘，您将获得这个状态。

• FLUSH_SLAVE_TIMEOUT
  如果 Broker 的角色是 SYNC_MASTER (默认是ASYNC_MASTER)，并且 Slave Broker 没有在MessageStoreConfig的syncFlushTimeout(默认是5秒)时间内完成同步，您将得到这个状态。

• SLAVE_NOT_AVAILABLE
  消息发送成功，但是此时Slave不可用。如果Broker服务器的角色是同步Master，即SYNC_MASTER（默认是异步Master服务器即ASYNC_MASTER），但没有配置slave Broker服务器，则将返回该状态——无Slave服务器可用。

• SEND_OK
  SEND_OK 并不意味着它是可靠的。为了确保没有信息会丢失，应启用 SYNC_MASTER 或 SYNC_FLUSH

从以上可以猜测，系统当前的投递状态应该是“ SLAVE_NOT_AVAILABLE”，但是由于日志没有打印投递异常时的具体状态值，所以要想验证具体的状态，只能想其他办法了。

2.2 arthas 查看方法变量的值

Arthas 是Alibaba开源的Java诊断工具，深受开发者喜爱。

当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：

这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
是否有一个全局视角来查看系统的运行状况？
有什么办法可以监控到JVM的实时运行状态？
怎么快速定位应用的热点，生成火焰图？

下载最新版

目前业务虽然报错，但是实际逻辑还是完整的，为了最小化影响，不能采取紧急的修复，所以决定使用arthas观察一下相关方法的内部变量值，看看投递状态到底是什么。

首先，找到报错的代码处，添加一个日志打印出投递状态，然后将类编译。

if (Objects.nonNull(sendResult) && sendResult.getSendStatus() == SendStatus.SEND_OK) {
    result = true;
}
else {
    // 新增异常日志
    logger.error("error sendStatus:{}", (Object)sendResult.getSendStatus());
}

然后将编译好的类，上传到服务器，按照arthas的操作指南，定位到要调试的应用。

$ $ java -jar arthas-boot.jar
* [1]: 35542
  [2]: 71560 my-app.jar

my-app进程是第2个，则输入2，再输入回车/enter。Arthas会attach到目标进程上，并输出日志：

[INFO] Try to attach process 71560
[INFO] Attach process 71560 success.
[INFO] arthas-client connect 127.0.0.1 3658
  ,---.  ,------. ,--------.,--.  ,--.  ,---.   ,---.
 /  O  \ |  .--. ''--.  .--'|  '--'  | /  O  \ '   .-'
|  .-.  ||  '--'.'   |  |   |  .--.  ||  .-.  |`.  `-.
|  | |  ||  |\  \    |  |   |  |  |  ||  | |  |.-'    |
`--' `--'`--' '--'   `--'   `--'  `--'`--' `--'`-----'
 
wiki: https://arthas.aliyun.com/doc
version: 3.0.5.20181127201536
pid: 71560
time: 2018-11-28 19:16:24
 
$

redefine

加载外部的.class文件，redefine jvm已加载的类。

这里，我们用重新编译好的添加了日志打印的类，替换jvm里的类。
在arthas终端界面，执行命令：

redefine /tmp/YourClass.class

替换完成后，观察应用日志，发现投递状态确实为“ SLAVE_NOT_AVAILABLE”/

2.3 检测RocketMq双主集群

在控制台可见，集群能够正常的识别，但是消息记录中，slave节点确实都为0，问题确实存在。

image.png

经过运维的再三排查，说集群配置没有问题。再经过数个小时的强迫性排查后，在晚上运维给出了一个让人啼笑皆非的原因：

slave节点的10911端口没有开放，导致无法与master实时同步

年轻人，希望你“耗子尾汁”！
年轻人，希望你“耗子尾汁”！！
年轻人，希望你“耗子尾汁”！！！

3. 收获

在排错过程中，不要完全相信任何人，特别是运维。

要避免灯下黑的现象。