RocketMQ系列之高可用测试

说明：

通过部署集群，然后测试集群的高可用性。以更好的熟悉RocketMQ的原理和使用。


1.使用JAVA程序测试以下高可用项：

1）master宕机，消息是否会丢失，消费是否正常？
测试：producer生产消息，关闭所有master，producer不能生产消息，启动consumer，数据消费正常。启动producer生产消息，启动consumer消费消息，关闭其中一个master，
producer生产消息和consumer消费消息均正常，但是此时存在consumer消费slave从master同步过来的所有数据，即重复消费。
结论：消息持久化，master宕机后slave还可以读，在异步刷盘模式中，存在master宕机后极少量的消息丢失，同步刷盘模式中不会丢失数据。
master宕机导致consumer从slave上重复消费master宕机前同步到slave的消息。若master宕机后无法恢复，此时可以重建master，然后将slave的数据拷贝到master的数据目录下重启恢复数据，
此时，在master恢复后其对应的slave可能需要重建。

2) namesrv宕机是否会影响生产和消费？
测试：producer生产消息，关闭namesrv，已经连接的producer没有影响，启动consumer不会消费数据，启动namesrc,consumer需等待最多30秒可以开始消费数据。
namesrv之间是没有通信的，独立的，宕机其中任何一台都不会影响集群的使用。
结论：只要namesrc不全宕机，集群就可用；若都宕机，则已经建立连接的生产者和消费者不受影响。

3）如果topic只在一个master上，宕机后还能写吗？
测试：不管配置文件是否开启autoCreateTopicEnable，在控制台手动创建topic，只指定一个master的情况下，producer生产消息，consumer消费消息，在关闭指定的master后，
生产和消费消息均正常。
结论：topic的建立是全局的，不会因为某个master或者namesrv宕机而不可用。

4）slave宕机会影响生产和消费吗？
结论：在master正常的情况下，slave只和master建立长连接同步数据，不做读写功能；只有master异常或者master消费压力过大（一般会选择brokerID=1的slave提供读）时，
slave才提供读的功能。所以slave宕机不会影响生产和消费。

5）加入新的namesrv，master重启会有什么影响？
结论：原有集群的broker添加新的namesrv后，逐一重启master和slave不会对生产和消费数据有影响，一个master重启后最多要30秒才能被producer再次更新连接上。
机制和master宕机是一样的，异步刷盘模式中可能存在极少量数据丢失的情况。但是已有的topic的路由信息不会更新添加新的broker的路由信息，
需要重建或者修改topic才行（若其中一个主broker宕机前删除了某个topic，这个broker宕机了，这时重新创建这个topic是不会有宕机的broker的路由信息的，
当broker恢复后，另一个broker发生宕机后这个topic将不可写了，因为路由信息没有更新，导致该topic不能在双master中高可用，目前版本只能手工使用命令：

2.JAVA程序如下：

使用InterliJ IDEA创建maven项目，导入以下依赖包和配置mvn的pom.xml处理依赖：

rocketmq-clinet-4.2.0.jar
rocketmq-common-4.2.0.jar
rocketmq-remoting-4.5.1.jar


项目的pom.xml依赖文件配置：

生产者生产消息：

消费者消费消息 — Push模式：

消费者消费消息 — Pull模式：

其他问题：

1、主，从服务器都在运行过程中，消息消费者是从主拉取消息还是从从拉取？
答：默认情况下，RocketMQ 消息消费者从主服务器拉取，当主服务器积压的消息超过了物理内存的40%，则建议从从服务器拉取。但如果slaveReadEnable为false，表示从服务器不可读，
从服务器也不会接管消息拉取。

2、当消息消费者向从服务器拉取消息后，会一直从从服务器拉取？
答：不是的。分如下情况：
如果从服务器的 slaveReadEnable 设置为 false，则下次拉取，从主服务器拉取。
如果从服务器允许读取并且从服务器积压的消息未超过其物理内存的40%，下次拉取使用的Broker 为订阅组的 brokerId 指定的 Broker 服务器，该值默认为0，代表主服务器。
如果从服务器允许读取并且从服务器积压的消息超过了其物理内存的40%，下次拉取使用的Broker 为订阅组的 whichBrokerWhenConsumeSlowly 指定的 Broker服务器，该值默认为1，代表从服务器。

3、主从服务消息消费进是如何同步的？
答：消息消费进度的同步时单向的，从服务器开启一个定时任务，定时从主服务器同步消息消费进度；无论消息消费者是从主服务器拉的消息还是从从服务器拉取的消息，在向Broker反馈消息消费进度时，
优先向主服务器汇报；消息消费者向主服务器拉取消息时，如果消息消费者内存中存在消息消费进度时，主会尝试跟新消息消费进度。

4、读写分离的正确使用姿势：
1)主从Broker服务器的slaveReadEnable设置为true。
2)通过 updateSubGroup 命令更新消息组 whichBrokerWhenConsumeSlowly、brokerId，特别是其 brokerId 不要设置为0，不然从从服务器拉取一次后，下一次拉取还是可能会从主去拉取。