? ? ? ?之前看rocketmq躬窜，然后在想一個問題，就是一主一從的集群結構中炕置，如果master宕機了荣挨，consumer這邊是怎么選擇的，按照官方說明中朴摊，master掛了垦沉，但是slave得消息仍然可以被消費到。原因是master和slave是一直有連接的仍劈，所以master上面的消息是可以及時同步到slave厕倍，但是終究是有一部分留在master（異步復制）的時候。
? ? ? ?那么問題來了贩疙，consumer是怎么從master上面切換到slave上繼續(xù)消費消息呢讹弯？首先明確一點，master宕機这溅，就意味著這個broker不再寫入组民，但是因為slave還在，所以還可以繼續(xù)讀悲靴。所以我們看一下consumer是怎么選擇的臭胜？
從Pullconsumer 進去，調用pullBlockIfNotFound方法癞尚，一直進去仪壮，最后到：DefaultMQPullConsumerImpl的pullSyncImpl? 方法积锅，最后看到這段：
PullResult pullResult =this.pullAPIWrapper.pullKernelImpl(mq,su?bscriptionData.getSubString(),0L,offset,maxNums,sysFlag,0,this.defaultMQPullConsumer.getBrokerSuspendMaxTimeMillis(),timeoutMillis,CommunicationMode.SYNC,null);
進去看一下實現(xiàn)：
FindBrokerResult findBrokerResult =
this.mQClientFactory.findBrokerAddressInSubscribe(mq.getBrokerName(),
this.recalculatePullFromWhichNode(mq),false);
其實這段也很好理解缚陷，就是先根據(jù)訂閱的關系找到broker。是根據(jù)broker的名字和id共同起作用的匙瘪。broker的名字肯定能夠拿到一堆broker的id蝶缀，一般都是一主多從，那這個怎么選呢碍论？
進去看看就知道了：
HashMap map =this.brokerAddrTable.get(brokerName);
if(map !=null&& !map.isEmpty()) {
brokerAddr = map.get(brokerId);
slave = brokerId != MixAll.MASTER_ID;
found = brokerAddr !=null;
if(!found && !onlyThisBroker) {
Entry entry = map.entrySet().iterator().next();
brokerAddr = entry.getValue();
slave = entry.getKey() != MixAll.MASTER_ID;
found =true;
}
}
先拿到broker的緩存，其實就是存在本地的hashmap藏研，然后根據(jù)broker的id查找蠢挡，如果找到了业踏，判斷下是不是slave角色返回，找不到的情況下就根據(jù)那拿到的列表迭代一個出來伤提，考慮到時無序的肿男，所以就可以理解為隨機拿一個出來了舶沛，再判定角色。
所以傳進來的brokerId非常重要骤竹，如果這臺機器沒有宕機的情況下往毡，就是返回這個broker的地址了，否則就是從剩下的機器進行隨機一個。
那傳進去的brokerId是怎么產生的呢苍狰？
public longrecalculatePullFromWhichNode(finalMessageQueue mq) {
if(this.isConnectBrokerByUser()) {
return this.defaultBrokerId;
}
AtomicLong suggest =this.pullFromWhichNodeTable.get(mq);
if(suggest !=null) {
returnsuggest.get();
}
returnMixAll.MASTER_ID;
}
傳入的mq是負載均衡服務分配給當前consumer消費的隊列，它必然是屬于一個brokername唯一的拓撲結構中响牛，即一主多從的幾臺機器中玷禽，從哪個機器選就很重要了，因為都可以選的呀打。
1.先看isConnectBrokerByUser 是否設置矢赁，如果設置，返回默認的贬丛，即0.
2.看緩存中是否已經存了建議值撩银，如果存了，直接返回
3.返回master的豺憔，即0.
那到這里额获，我們看一下怎么解釋一下宕機時主從切換過程够庙，consumer時如何從主上面切換到從上面的？
1.一開始時正常的抄邀，因為沒有緩存耘眨，也沒有特別設置，所以境肾，進入3 返回master剔难。
2.master 寫入緩存，后面都讀取到緩存奥喻，在上面的步驟2中返回偶宫。
master宕機了，然后nameserver中不再收到心跳环鲤，然后master機器剔除掉纯趋。所以consumer雖然選到了master，但是因為在地址中找不到broker'id=0的數(shù)據(jù)楔绞，于是進入隨機過程结闸，然后這樣就切到了slave，然后slave寫入到緩存酒朵。后面一直讀到緩存中的slave桦锄。
問題來了：master起來后，建議值的緩存也沒有更新蔫耽，那怎么切回到master结耀，畢竟我們是因為宕機產生地址找不到的時候，才能完成切換的匙铡，這解釋不通图甜。
后來debug了一發(fā)，發(fā)現(xiàn)這個suggest值并不是consumer端決定的鳖眼，而是broker決定的黑毅。啥意思，即使你是拉去slave上面的數(shù)據(jù)钦讳，slave上面返回的結果中的suggest值也可能是0矿瘦，然后0就寫進緩存中，下一次愿卒，你還是優(yōu)先訪問master缚去，然后master沒有地址，訪問slave琼开。
這個意思就是易结，consumer端是根據(jù)緩存中的suggest值優(yōu)先選機器。但是呢這個suggest是通過broker傳回來的。所以即使是訪問slave搞动，傳回來的suggest值仍然是master躏精，只不過客戶端沒有master的映射關系，所以繼續(xù)訪問slave滋尉。這就能解釋為什么master從宕機起來后玉控，consumer能夠切回master飞主，因為地址映射表得到更新了狮惜，nameserver中有了master的信息了。
那么重點來了：
什么時候碌识，broker返回的建議值是0碾篡？
什么時候，broker返回的建議值是其他值筏餐？
1.如果master中的堆積信息過多开泽，默認返回consumerslow配置，默認是1.（所以機器的brokerId真的不能亂用）魁瞪，這個時候就切到slave了穆律。
2.
未完待續(xù)~
