消息隊(duì)列實(shí)現(xiàn)復(fù)制的最佳實(shí)踐
對(duì)于MQ
在Pro、Con客戶端，依靠業(yè)務(wù)代碼，配合請(qǐng)求確認(rèn)機(jī)制保證不會(huì)丟消息。
在服務(wù)端，一般采用持久化和復(fù)制做保證。
把消息復(fù)制到多個(gè)節(jié)點(diǎn)，不僅可解決丟消息問(wèn)題，還可保證消息服務(wù)的HA。所以都會(huì)把MQ配置集群模式，并開啟消息復(fù)制保證系統(tǒng)。
那么消息復(fù)制需要解決哪些問(wèn)題呢？
1 消息復(fù)制的指標(biāo)
我們希望MQ兼具高性能、高可用并且還能提供數(shù)據(jù)一致性。雖然很多MQ宣稱三個(gè)特性全都支持，但這都是有前置條件的。
1.1 性能
首先明確數(shù)據(jù)的寫性能一定不如單節(jié)點(diǎn)。因?yàn)闊o(wú)論采用哪種復(fù)制，都需數(shù)據(jù)被寫到多節(jié)點(diǎn)后再返回，性能一定不如只寫入一個(gè)節(jié)點(diǎn)。
需要寫入節(jié)點(diǎn)越多，可用性和數(shù)據(jù)可靠性越好，但寫性能就越低。
不過(guò)，復(fù)制對(duì)消費(fèi)的性能影響不大，不管采用哪種復(fù)制方式，消費(fèi)消息的時(shí)候，都只是選擇多副本中一個(gè)節(jié)點(diǎn)去讀數(shù)據(jù)，和單節(jié)點(diǎn)消費(fèi)無(wú)異。
1.2 一致性
MQ對(duì)數(shù)據(jù)一致性要求，既包括“不丟消息”，也包括“嚴(yán)格順序”。
若要確保數(shù)據(jù)一致性，必須采用主從復(fù)制。
這個(gè)結(jié)論有嚴(yán)格數(shù)學(xué)論證。
主從模式下，數(shù)據(jù)先寫到主節(jié)點(diǎn)，從節(jié)點(diǎn)只從主節(jié)點(diǎn)上復(fù)制，若出現(xiàn)主從數(shù)據(jù)不一致，須以主節(jié)點(diǎn)數(shù)據(jù)為準(zhǔn)。
這里的主節(jié)點(diǎn)并非不可變，在很多復(fù)制實(shí)現(xiàn)中，當(dāng)主節(jié)點(diǎn)出現(xiàn)問(wèn)題，其他節(jié)點(diǎn)可通過(guò)選舉，變成主節(jié)點(diǎn)。只要保證，在任一時(shí)刻，集群的主節(jié)點(diǎn)數(shù)不能超過(guò)1個(gè)，就可確保數(shù)據(jù)一致性。
1.3 高可用
須采用主從復(fù)制，高可用需解決的就是，當(dāng)某個(gè)主節(jié)點(diǎn)宕機(jī)，盡快再選個(gè)主節(jié)點(diǎn)來(lái)繼位。
比較快速的實(shí)現(xiàn)方式是，使用一個(gè)第三方服務(wù)來(lái)管理這些節(jié)點(diǎn)，發(fā)現(xiàn)某主節(jié)點(diǎn)宕機(jī)，由管理服務(wù)指定一個(gè)新的主節(jié)點(diǎn)。
但引入管理服務(wù)會(huì)帶來(lái)一系列問(wèn)題，比如管理服務(wù)本身的高可用、數(shù)據(jù)一致性如何保證？就如 redis 哨兵機(jī)制。
有的MQ選擇自選舉，由還存活的這些節(jié)點(diǎn)通過(guò)投票，來(lái)選個(gè)新主節(jié)點(diǎn)。
優(yōu)點(diǎn)
沒(méi)有外部依賴，可以實(shí)現(xiàn)自我管理缺點(diǎn)
投票的實(shí)現(xiàn)都比較復(fù)雜，并且選舉過(guò)程是比較慢的，幾秒至幾十秒都可能，在選出新的主節(jié)點(diǎn)前，服務(wù)一直不可用。
大部分復(fù)制的實(shí)現(xiàn)，都不會(huì)選擇把消息寫入全部副本再返回確認(rèn)，因?yàn)檫@樣雖然可以保證數(shù)據(jù)一致性，但是，一旦這些副本中有任何一個(gè)副本宕機(jī)，寫入就會(huì)卡死了。如果只把消息寫入到一部分副本就認(rèn)為寫入成功并返回確認(rèn)，就可以解決卡死的問(wèn)題，并且性能也會(huì)比寫全部副本好很多。
到底寫入多少個(gè)副本算寫入成功呢？這又是一個(gè)非常難抉擇的問(wèn)題。
假設(shè)集群采用“一主二從三副本”的模式，如果只要消息寫入到兩個(gè)副本就算是寫入成功了，那這三個(gè)節(jié)點(diǎn)最多允許宕機(jī)一個(gè)節(jié)點(diǎn)，否則就沒(méi)法提供服務(wù)了。如果說(shuō)我們把要求寫入的副本數(shù)量降到1，只要消息寫入到主節(jié)點(diǎn)就算成功了，那三個(gè)節(jié)點(diǎn)中，可以允許宕機(jī)兩個(gè)節(jié)點(diǎn)，系統(tǒng)依然可以提供服務(wù)，這個(gè)可用性就更好一些。但是，有可能出現(xiàn)一種情況：主節(jié)點(diǎn)有一部分消息還沒(méi)來(lái)得復(fù)制到任何一個(gè)從節(jié)點(diǎn)上，主節(jié)點(diǎn)就宕機(jī)了，這時(shí)候就會(huì)丟消息，數(shù)據(jù)一致性又沒(méi)有辦法保證了。
以上還沒(méi)涉及任何復(fù)制或者選舉的方法和算法，都是最基本的分布式原理。里面是有很多固有矛盾，所以，并沒(méi)有一種完美實(shí)現(xiàn)方案能夠兼顧高性能、高可用和一致性。
不同MQ選擇了不同的復(fù)制實(shí)現(xiàn)方式，有各自的優(yōu)缺點(diǎn)，在高性能、高可用和一致性方面提供的能力也是各有高低。
接下來(lái)我們對(duì)比RocketMQ和Kafka實(shí)現(xiàn)復(fù)制。
2 RocketMQ復(fù)制
2.1 傳統(tǒng)復(fù)制
在RocketMQ中，復(fù)制的基本單位是Broker，服務(wù)端進(jìn)程。采用主從復(fù)制，通常配置成一主一從，也支持一主多從。
RocketMQ提供兩種
復(fù)制方式
異步復(fù)制
消息先發(fā)送到主節(jié)點(diǎn)，就返回“寫入成功”，然后消息再異步復(fù)制到從節(jié)點(diǎn)。
同步雙寫
消息同步雙寫到主從節(jié)點(diǎn)，主從都寫成功，才返回“寫入成功”。
這兩種方式本質(zhì)上的區(qū)別是，寫入多少個(gè)副本再返回“寫入成功”的問(wèn)題，異步復(fù)制需要的副本數(shù)是1，同步雙寫需要的副本數(shù)是2。
如果在返回“寫入成功”前，需要寫入的副本數(shù)不夠多，那就會(huì)丟消息。
對(duì)RocketMQ來(lái)說(shuō)，如果采用異步復(fù)制的方式會(huì)不會(huì)丟消息呢？不會(huì)丟。
為什么不會(huì)丟消息
RocketMQ的Broker的主從關(guān)系是通過(guò)配置固定，不支持動(dòng)態(tài)切換。
如果主節(jié)點(diǎn)宕機(jī)，生產(chǎn)者就不能再生產(chǎn)消息，消費(fèi)者可自動(dòng)切換到從節(jié)點(diǎn)繼續(xù)進(jìn)行消費(fèi)。
這時(shí)候，即使有一些消息沒(méi)有來(lái)得及復(fù)制到從節(jié)點(diǎn)上，這些消息依然躺在主節(jié)點(diǎn)的磁盤，除非是主節(jié)點(diǎn)的磁盤壞了，否則等主節(jié)點(diǎn)重新恢復(fù)服務(wù)的時(shí)候，這些消息依然可以繼續(xù)復(fù)制到從節(jié)點(diǎn)上，也可以繼續(xù)消費(fèi)，不會(huì)丟消息，消息順序也沒(méi)有問(wèn)題。
這種主從復(fù)制方式，犧牲可用性，得到較好性能和數(shù)據(jù)一致性。
可用性
一對(duì)主從節(jié)點(diǎn)可用性不行，那就多對(duì)。
功能
RocketMQ支持把一個(gè)主題分布到多對(duì)主從節(jié)點(diǎn)，每對(duì)主從節(jié)點(diǎn)中承擔(dān)主題中的一部分隊(duì)列。表現(xiàn)
若某主節(jié)點(diǎn)宕機(jī)，自動(dòng)切換到其他主節(jié)點(diǎn)繼續(xù)發(fā)消息。解決如下問(wèn)題：
可用性
還可通過(guò)水平擴(kuò)容提升Topic性能
舊復(fù)制缺陷
由于topic層無(wú)法保證嚴(yán)格順序，必須指定隊(duì)列發(fā)消息，對(duì)任一隊(duì)列，一定是落在一組特定主從節(jié)點(diǎn)，若該主節(jié)點(diǎn)宕機(jī)，其他主節(jié)點(diǎn)無(wú)法替代這主節(jié)點(diǎn)，否則就無(wú)法保證嚴(yán)格順序。
因此這種復(fù)制模式的嚴(yán)格順序和高可用只能選其一。
2.2 新復(fù)制
2018年底引入Deldger，一種全新復(fù)制方式。
Dledger在寫入消息時(shí)，要求至少消息復(fù)制到半數(shù)以上節(jié)點(diǎn)后，才給客戶端返回寫成功，且支持選舉動(dòng)態(tài)切換主節(jié)點(diǎn)。
執(zhí)行原理
3節(jié)點(diǎn)為例。當(dāng)主節(jié)點(diǎn)宕機(jī)，2個(gè)從節(jié)點(diǎn)會(huì)通過(guò)投票選出一個(gè)新主節(jié)點(diǎn)，相比主從復(fù)制，解決了可用性問(wèn)題。
由于消息要至少?gòu)?fù)制到2個(gè)節(jié)點(diǎn)上才返回寫成功，即使主節(jié)點(diǎn)宕機(jī)，也至少有一節(jié)點(diǎn)消息是和主節(jié)點(diǎn)一致。選舉時(shí)，總會(huì)把數(shù)據(jù)和主節(jié)點(diǎn)一樣的從節(jié)點(diǎn)選為新主，保證了數(shù)據(jù)一致性，既不會(huì)丟消息，還可保證嚴(yán)格順序。
新復(fù)制的缺陷
選舉過(guò)程中不能提供服務(wù)。最少需要3節(jié)點(diǎn)才能保證數(shù)據(jù)一致性。
3節(jié)點(diǎn)時(shí)，只能保證1個(gè)節(jié)點(diǎn)宕機(jī)時(shí)可用，如果2個(gè)節(jié)點(diǎn)同時(shí)宕機(jī)，即使還有1個(gè)節(jié)點(diǎn)存活也無(wú)法提供服務(wù)，資源利用率較低。
由于至少要復(fù)制到半數(shù)以上的節(jié)點(diǎn)才返回寫入成功，不如主從異步復(fù)制快。
3 Kafka 復(fù)制
復(fù)制的基本單位是分區(qū)。每個(gè)分區(qū)的幾個(gè)副本間，構(gòu)成一個(gè)小的復(fù)制集群。
Broker只是這些分區(qū)副本的容器，所以Kafka的Broker是不分主從的。
分區(qū)的多個(gè)副本中采用一主多從。
寫入消息時(shí)，采用異步復(fù)制。消息在寫到主節(jié)點(diǎn)后，并不會(huì)馬上返回寫入成功，而是等待足夠多的節(jié)點(diǎn)都復(fù)制成功后再返回。這個(gè)“足夠多”由用戶定。對(duì)應(yīng)：ISR（In Sync Replicas)，“保持?jǐn)?shù)據(jù)同步的副本”。ISR的數(shù)量可配，ISR中包含主節(jié)點(diǎn)。
Kafka使用ZooKeeper監(jiān)控每個(gè)分區(qū)的多個(gè)節(jié)點(diǎn)，如果發(fā)現(xiàn)某個(gè)分區(qū)主節(jié)點(diǎn)宕機(jī)：
Kafka會(huì)利用ZooKeeper選個(gè)新主節(jié)點(diǎn)，這解決可用性
選舉時(shí)，會(huì)從所有ISR節(jié)點(diǎn)選新主節(jié)點(diǎn)，這保證數(shù)據(jù)一致性
默認(rèn)如果所有ISR宕機(jī)，分區(qū)就無(wú)法提供服務(wù)。也可以選擇配置成讓分區(qū)繼續(xù)提供服務(wù)，這樣只要有一個(gè)節(jié)點(diǎn)活，就可提供服務(wù)，代價(jià)是無(wú)法保證數(shù)據(jù)一致性，會(huì)丟消息。
Kafka的這種高度可配置的復(fù)制方式
優(yōu)點(diǎn)
非常靈活，可自定義配置這些復(fù)制參數(shù)，在可用性、性能和一致性這幾方面做業(yè)務(wù)取舍缺點(diǎn)
學(xué)習(xí)成本較高
4 總結(jié)
沒(méi)有完美的復(fù)制方案，可同時(shí)兼顧高性能、高可用和一致性。要根據(jù)業(yè)務(wù)需求，做出取舍，再去配置。
參考
https://blog.51cto.com/14799494/2507807
