关于使用RocketMQ搭建多Master多Slave模式（同步）集群时遇到的问题
搭建多Master多Slave模式（同步）集群时的java.lang.NullPointerException异常
一、运行环境等基本描述（问题产生原因是权限问题，即权限不够导致无法启动broker，甚至broker线程无法通过jps命令查出。下面阐述分析思路）
1.1）操作系统：Linux
虚拟机：VMware Workstation 16 Pro 、WSL
Openjdk Version：11.0.19
使用RocketMQ进行多Master多Slave模式（同步）集群的搭建
2）集群配置：
# nameserver
xxx.xxx.xxx.xxx rocketmq-nameserver1
xxx.xxx.xxx.xxx rocketmq-nameserver2
# broker
# 在VMware Workstation上启动
xxx.xxx.xxx.xxx:10911 rocketmq-master1--> broker-a.properties
xxx.xxx.xxx.xxx:11011 rocketmq-slave2 --> broker-b-s.properties
# 在WSL上启动
xxx.xxx.xxx.xxx:10911 rocketmq-master2 --> broker-b.properties
xxx.xxx.xxx.xxx:11011 rocketmq-slave1 --> broker-a-s.properties
二、问题复现（在VMware Workstation上启动broker-a）
1.1）用户sumuwen并不是root用户，因此没有拥有至高权限
输入以上命令后，broker启动过程中抛出异常java.lang.NullPointerException
三、分析并解决问题
1.1）检查线程ID：使用jps命令检查目前正在运行的线程ID，发现broker并未启动
2）检查网络状态：使用netstat -tlnp命令检查网络状态，并未发现端口为10911的进程出现在网络状态中，说明broker并未被真正的启动。这一点也可以在broker.log或者在nohup命令生成的nohup.out文件中查询出来。其实，在这里linux就已经提示你了，因为不是root用户，所以目前用户的权限不足以查询出所有的信息。这一点其实也体现在了使用jps命令时，可能你已经启动了broker，但是jps命令就是查询不出来。这也是为什么我会进行检查线程ID和检查网络状态这两个操作的原因，目的就在确定broker是否已经启动。
3）使用sudo进行broker的启动（每次启动一个broker利用上面的方法检查broker是否启动成功是一个非常有效率而且能够定位到启动的错误是什么的好习惯。当然，你也可以选择切换到root用户使用jps命令查询broker是否启动成功）。在此之前，需要注意一件事情，第一次使用sudo命令时需要输入密码，建议在输入密码后再使用sudo命令启动broker。
注：nohup命令会在执行后在你目前终端所处的文件位置生成一个nohup.out文件，里面记录了一些关于你执行命令的状态信息。在启动broker的过程中除非你设置了环境变量，否则需要时刻注意你的终端中所处的文件位置，因为如果文件位置不对，你也无法在任何文件地点启动broker。启动broker的文件位置一般是rocketmq的bin目录下。
4）切换到root用户，我们发现broker-a被成功启动。这里如果你不是root用户使用jps的话，你是查询不出来broker成功启动的进程ID的。但是你可以使用（在使用非root用户时）命令netstat -tlnp命令，可以发现端口号10911已被使用（只不过无法确定是否是broker-a使用的，这时候去看broker.log以及nohup.out文件进行进一步的判断就十分重要了）
2.1）使用WSL的同志们会发现，不需要sudo，不需要切换root用户，直接使用broker启动命令，然后用jps命令进行线程ID的查询，broker就成功启动了！这是因为WSL的用户，在一开始就是root，即权限最高。因此，上述问题也就不复存在了。
2）上述仅仅是启动了集群中的broker-a，在VMware Workstation上还要启动broker-b-s，步骤分析基本一样，就不过多赘述了。
3）以上问题分析流程以及解决方式是启动broker时出现java.lang.NullPointerException异常的一种解决思路的提供。
4）希望你能以最短的时间解决你的问题。