为什么不能直接下线

broker主从同步包括同步双写和异步复制，其实这两种都是使用相同的方式传输的，同步双写只是在主线程上阻塞了一段时间，等待传输结果，返回给producer。

本篇不讨论主从同步的机制，主要研究下master优雅下线！

如果直接下线master，由于主从异步复制，可能导致部分消息来不及复制到slave造成消息丢失。所以不可行。

另一种方案选择：关闭该broker的写入权限，待该broker不再有写入和消费时，再下线该节点。

操作流程

关闭broker写权限

2表示只写权限，4表示只读权限，6表示读写权限

sh mqadmin updateBrokerConfig -b 172.16.xx.xx:10911 -n 172.16.xx.xx:9876 -k brokerPermission -v 4

观察节点流量

 sh mqadmin clusterlist -n 172.16.xx.xx:9876 

#Cluster Name     #Broker Name            #BID  #Addr                  #Version                #InTPS(LOAD)       #OutTPS(LOAD) #PCWait(ms) #Hour #SPACE
first-cluster     first-broker            0     172.16.xx.xx:10911    V4_2_0_SNAPSHOT          0.00(0,0ms)         0.00(0,0ms)          0 79.06 0.3425

观察InTPS和OutTPS，理想情况都为零时，并不再变化时，则该节点可下线了。

然而，在实际过程中并没有出现为零的情况，InTPS和OutTPS总是有值，有时个位数字有时是两位数字，大部分时间在20多的值。此刻要分析下broker目前的消费状态。

sh bin/mqadmin brokerConsumeStats -b 172.16.xx.xx:10911 -n 172.16.xx.xx:9876 > brokerConsumeStats.tmp 

less brokerConsumeStats.tmp 

#Topic                            #Group                            #Broker Name                      #QID  #Broker Offset        #Consumer Offset      #Diff                 #LastTime
xxQueue                xxGroup              first-broker                      1     2798                  2798                  0                     2020-03-31 18:33:09

查看brokerConsumeStats.tmp，主要查看#LastTime和#Diff。发现%RETRY%重试类队列#Diff有很微小（1或者3）的数据，而其他topic均为0. LastTime时间最新也是发生在%RETRY%队列中。此时可以让该节点下线操作。

恢复写权限

sh mqadmin updateBrokerConfig -b 172.16.xx.xx:10911 -n 172.16.xx.xx:9876 -k brokerPermission -v 6

观察节点流量是否正常

sh mqadmin clusterlist -n 172.16.xx.xx:9876 

#Cluster Name     #Broker Name            #BID  #Addr                  #Version                #InTPS(LOAD)       #OutTPS(LOAD) #PCWait(ms) #Hour #SPACE
first-cluster     first-broker            0     172.16.xx.xx:10911    V4_2_0_SNAPSHOT          2.50(0,0ms)         3.90(0,0ms)          0 79.20 0.3426

参考：RocketMQ集群生产环境节点下线操作--【实战笔记】