在服務(wù)開發(fā)中，單機會有單點故障，如果服務(wù)部署在服務(wù)器上，一旦服務(wù)器宕機，服務(wù)將不可用。因此，為了使服務(wù)高可用，出現(xiàn)了分布式服務(wù)。同一個服務(wù)部署在多臺機器上，即使多臺服務(wù)器宕機一致性hash算法php開源，只要一臺服務(wù)器可用，服務(wù)就可用。

同樣如此。為了解決單機故障，引入了主從模式，但是主從模式存在一個問題：節(jié)點出現(xiàn)故障后，需要手動切換服務(wù)到節(jié)點才能服務(wù)恢復(fù)。為了解決這個問題，引入了哨兵模式。哨兵模式可以在節(jié)點故障后自動將節(jié)點升級為節(jié)點，無需人工干預(yù)即可恢復(fù)服務(wù)。

但是，主從模式和哨兵模式還沒有達(dá)到真正的數(shù)據(jù)存儲，每個實例都存儲了全量的數(shù)據(jù)，因此誕生并實現(xiàn)了真正的數(shù)據(jù)分片存儲。不過由于發(fā)布比較晚（2015年正式版發(fā)布），各大廠迫不及待，紛紛開發(fā)了自己的數(shù)據(jù)分片集群模型，如：等。

1.主從模式

雖然單個節(jié)點可以通過RDB和AOF的持久化機制將數(shù)據(jù)持久化到硬盤，但是數(shù)據(jù)是存儲在服務(wù)器上的。如果服務(wù)器出現(xiàn)硬盤故障或其他問題，將導(dǎo)致數(shù)據(jù)不可用，讀寫無法分離，讀寫都在同一臺服務(wù)器上。當(dāng)請求量很大時，就會出現(xiàn) I/O 瓶頸。

為了避免單點故障和讀寫不分離，提供()函數(shù)，實現(xiàn)數(shù)據(jù)庫中數(shù)據(jù)更新后，更新后的數(shù)據(jù)會自動同步到其他數(shù)據(jù)庫。

以上主從結(jié)構(gòu)特點：一個可以有多個節(jié)點；節(jié)點可以有節(jié)點，從節(jié)點是級聯(lián)結(jié)構(gòu)。

主從模式的優(yōu)缺點

優(yōu)點：主從結(jié)構(gòu)具有讀寫分離、提高效率、數(shù)據(jù)備份、提供多副本等優(yōu)點。

不足：最大的缺點是主從模式?jīng)]有自動容錯和恢復(fù)功能。如果主節(jié)點出現(xiàn)故障，集群就無法工作，可用性比較低。從節(jié)點升級為主節(jié)點需要人工干預(yù)。

普通主從模式，當(dāng)主庫崩潰時，需要手動切換從庫成為主庫：

在從庫中使用NO ONE命令將數(shù)據(jù)庫提升到主庫繼續(xù)服務(wù)。

啟動之前崩潰的主庫，然后使用命令將其設(shè)置為新主庫的從庫進(jìn)行數(shù)據(jù)同步。

2.哨兵模式

第一種主從同步/復(fù)制模式，當(dāng)主服務(wù)器宕機時，需要手動將一臺從服務(wù)器切換為主服務(wù)器，需要人工干預(yù)，費力費力，而且會導(dǎo)致服務(wù)在一段時間內(nèi)無法使用。 ,這時候就需要哨兵模式了。

哨兵模式是從2.6版本開始提供的，但是當(dāng)時這個版本的模式不穩(wěn)定，直到2.8版本才穩(wěn)定。

哨兵模式的核心還是主從復(fù)制，但是在主節(jié)點宕機無法寫入的情況下，相比主從模式，多了一個選舉機制：一個新的主節(jié)點從所有從節(jié)點中選出。選舉機制的實現(xiàn)依賴于在系統(tǒng)中啟動一個進(jìn)程。

如上圖所示，本身也存在單點故障的問題，所以在一個主多從的系統(tǒng)中，可以使用多個進(jìn)行監(jiān)控。監(jiān)視器。每個哨兵都是一個獨立的進(jìn)程，作為一個進(jìn)程，它會獨立運行。

(1)哨兵模式的作用：

監(jiān)控所有服務(wù)器是否正常運行：發(fā)送命令返回監(jiān)控服務(wù)器運行狀態(tài)，主從服務(wù)器進(jìn)程監(jiān)控，哨兵之間相互監(jiān)控。

：當(dāng)哨兵檢測到宕機時，會自動切換到它，然后通過發(fā)布-訂閱的方式通知其他從服務(wù)器，修改配置文件，讓他們切換。同時，有問題的老主人也會成為新主人的奴隸，也就是說，當(dāng)老主人恢復(fù)時，它不會恢復(fù)原來的主人身份，而是會充當(dāng)新主人的奴隸。 .

(2)哨兵實現(xiàn)原理

哨兵啟動進(jìn)程時，會讀取配置文件的內(nèi)容，通過如下配置找到要監(jiān)控的主庫：

-name ip 端口

#-name 是主數(shù)據(jù)庫的名稱

#ip和port是當(dāng)前主庫地址和端口號

# 表示在執(zhí)行故障轉(zhuǎn)移操作之前需要多少個哨兵節(jié)點同意。

這里之所以只需要連接主節(jié)點，是通過主節(jié)點的info命令獲取從節(jié)點信息，從而與從節(jié)點建立連接，同時，通過主節(jié)點的info信息可以知道新的從節(jié)點的信息。 .

一個哨兵節(jié)點可以監(jiān)控多個主節(jié)點，但不建議這樣做，因為當(dāng)一個哨兵節(jié)點崩潰時，多個集群切換會同時失效。 啟動后，與主數(shù)據(jù)庫建立兩個連接。

訂閱主數(shù)據(jù)庫：獲取有關(guān)監(jiān)視數(shù)據(jù)庫的哨兵節(jié)點信息的通道

定期向數(shù)據(jù)庫發(fā)送info命令，獲取數(shù)據(jù)庫本身的信息。

與主庫建立連接后，會定期執(zhí)行以下三個操作：

(1）每隔10s發(fā)送一次info命令，作用是獲取當(dāng)前數(shù)據(jù)庫信息，比如發(fā)現(xiàn)新的節(jié)點時，會建立連接并加入監(jiān)控列表.當(dāng)主從數(shù)據(jù)庫的角色發(fā)生變化時更新信息。

(2）每隔2s發(fā)送自己的信息到主從數(shù)據(jù)庫的。作用是把自己的監(jiān)控數(shù)據(jù)分享給。每個都會訂閱: ，當(dāng)其他哨兵收到消息后，會判斷該哨兵是否為新哨兵，如果是，則將其加入哨兵列表并建立連接。

(3）每隔1s向所有主從節(jié)點和所有哨兵節(jié)點發(fā)送ping命令，監(jiān)控節(jié)點是否存活。

(3)主觀客觀離線

當(dāng)哨兵節(jié)點發(fā)送ping命令時，經(jīng)過一定時間（down--），如果節(jié)點沒有回復(fù)，哨兵認(rèn)為主觀下線。主觀下線是指當(dāng)前哨兵認(rèn)為節(jié)點已經(jīng)宕機。如果節(jié)點是主庫， 會進(jìn)一步判斷故障轉(zhuǎn)移就夠了。此時會發(fā)送命令（is--down-by-addr）詢問其他哨兵節(jié)點是否主觀認(rèn)為主節(jié)點下線，當(dāng)達(dá)到指定數(shù)（）時哨兵會認(rèn)為成為一個離線的目標(biāo)。

主節(jié)點客觀下線時，需要進(jìn)行主從切換。主從切換步驟為：

哨兵選擇一個從庫后，發(fā)送no one命令升級主庫，并發(fā)送命令將其他從節(jié)點的主庫設(shè)置為新的主庫。

(4)哨兵模式的優(yōu)缺點

1.優(yōu)勢

2.不足問題

主從模式或哨兵模式存儲在每個節(jié)點中的數(shù)據(jù)是全量數(shù)據(jù)。當(dāng)數(shù)據(jù)量過大時，存儲的數(shù)據(jù)需要分片存儲在多個實例上。這就是技術(shù)發(fā)揮作用的地方。

3.各大廠群解決方案

3.0 版本之前只支持單實例模式。雖然正式版的開發(fā)者要到2015年才會發(fā)布，各大企業(yè)已經(jīng)等不及了。在3.0版本發(fā)布之前，為了解決存儲瓶頸，他們推出了自己的集群解決方案。這些方案的核心思想是將數(shù)據(jù) () 存儲在多個實例中，每個 就是一個實例。

(1)客戶端片段

客戶端分片是在客戶端實現(xiàn)分片邏輯，（例如：支持的功能，也就是），通過客戶端預(yù)定義的路由規(guī)則（使用一致性哈希），將key的訪問轉(zhuǎn)發(fā)到不同的實例，并在查詢數(shù)據(jù)時匯總返回的結(jié)果。該方案的架構(gòu)如圖所示。

客戶端分片的優(yōu)缺點：

優(yōu)點：客戶端技術(shù)使用哈希共識算法分片的優(yōu)點是所有邏輯可控，不依賴第三方分布式中間件。服務(wù)器的實例相互獨立，互不相關(guān)。每個實例都像單臺服務(wù)器一樣運行，非常容易線性擴展，系統(tǒng)非常靈活。開發(fā)者知道如何實現(xiàn)分片和路由規(guī)則，不用擔(dān)心踩坑。

1.一致性哈希算法：

是分布式系統(tǒng)中常用的算法。例如，在分布式存儲系統(tǒng)中，要將數(shù)據(jù)存儲在特定的節(jié)點上，如果使用常用的哈希方法將數(shù)據(jù)映射到特定的節(jié)點，比如mod(key,d)，key就是數(shù)據(jù)的key，d 是機器節(jié)點的數(shù)量。如果一臺機器加入或離開集群網(wǎng)站開發(fā)，所有的數(shù)據(jù)映射都是無效的。

一致性哈希算法解決了普通余數(shù)哈希算法擴展性差的問題，可以保證在服務(wù)器在線或離線時盡可能多的請求命中原路由服務(wù)器。

2.實現(xiàn)方式：一致性哈希算法，如哈希算法、算法

例如在實現(xiàn)中，使用了一致性哈希算法（ ），同時對key和節(jié)點名進(jìn)行映射匹配。使用的算法是。

使用一致性哈希而不是簡單的類似哈希的模映射的主要原因是，當(dāng)添加或減去節(jié)點時，不會有重新匹配。一致性哈希只影響相鄰節(jié)點的密鑰分布，影響量很小。

不足：

客戶端分片最大的問題之一是當(dāng)服務(wù)器實例組的拓?fù)浒l(fā)生變化時，每個客戶端都需要更新和調(diào)整。如果可以將客戶端分片模塊單獨取出，形成一個單獨的模塊（中間件），作為連接客戶端和服務(wù)端的橋梁解決這個問題，那么代理分片就出現(xiàn)了。

(2)代理片段

最常用的代理分片是開源代理。基本原理是：客戶端以中間件的形式，根據(jù)路由規(guī)則將請求發(fā)送到正確的實例，最后將結(jié)果返回給客戶端。

通過引入代理層，統(tǒng)一管理多個實例，客戶端只需要對其進(jìn)行操作，無需關(guān)心后面有多少實例，從而實現(xiàn)集群。

優(yōu)點：缺點：

作為使用最廣泛、試用最穩(wěn)定的代理，在業(yè)界被廣泛使用。

(3)

實例無法平滑添加的問題帶來了極大的不便，于是玩豆家自主研發(fā)了支持實例平滑添加的代理軟件。它基于 Go 和 C 語言開發(fā)，于 2014 年 11 月開源。

在架構(gòu)圖中，介紹了，通過指定一個和一個或多個來實現(xiàn)集群的高可用。當(dāng)一個掛掉時，不會自動將一個提升為，這涉及到數(shù)據(jù)一致性（數(shù)據(jù)同步本身采用主從異步復(fù)制，當(dāng)數(shù)據(jù)成功寫入時一致性hash算法php開源，是否已經(jīng)讀入此數(shù)據(jù)不保證），管理員需要在管理界面手動將提升為。

如果你覺得手動處理比較麻煩，玩豆家還提供了一個工具-ha，這個工具會在檢測到宕機時將它下線并提升一個 。

是預(yù)分片的形式。啟動時，會創(chuàng)建 1024 個插槽。一個插槽相當(dāng)于一個盒子。每個盒子都有一個固定的編號，范圍從 1 到 1024。插槽盒子用于存儲密鑰。至于密鑰存放在哪個盒子里，可以通過算法“(key)24”得到一個數(shù)字。這個數(shù)字的范圍必須在1到1024之間，鑰匙放在這個數(shù)字對應(yīng)的槽中。

例如，如果一個key通過算法“(key)24”得到數(shù)字5，則將其放入代碼為5的槽（box）中。一個槽只能放在一個，一個槽不能放放置在多個s中。 1 最少可以存儲1個slot，最多可以存儲1024個slot。因此，最多可以指定 1024 個。

最大的優(yōu)點是支持平滑增（減）（實例），可以安全透明地遷移數(shù)據(jù)，這也是不同于其他靜態(tài)分布式方案的。添加后，涉及到的遷移。

比如系統(tǒng)有兩個，slot對應(yīng)關(guān)系如下。

添加一個后，將重新分配插槽。有兩種分配槽的方法：

第一種：通過管理工具手動重新分配，為每一個指定對應(yīng)的slot的范圍。例如，您可以指定新的與slot之間的對應(yīng)關(guān)系，如下所示。

第二：通過管理工具的功能，slot會根據(jù)各自的內(nèi)存自動遷移，實現(xiàn)數(shù)據(jù)均衡。

4.

哨兵模式雖然可以實現(xiàn)高可用和讀寫分離，但有幾個缺點：

3.0增加了集群模式，實現(xiàn)了分布式存儲，即每個節(jié)點存儲不同的數(shù)據(jù)。為了解決單臺機器容量有限的問題小程序開發(fā)，該模式按照一定的規(guī)則將數(shù)據(jù)分配給多臺機器。內(nèi)存/QPS不限于單機，可以受益于分布式集群的高擴展性。

是一種服務(wù)器技術(shù)（分片和路由都是在服務(wù)器端實現(xiàn)的），采用多主多從，每個分區(qū)由一個主多從組成，區(qū)域相互平行。的。集群采用P2P模式，完全去中心化。

如上圖，官方建議集群部署至少需要3個節(jié)點，最好使用6個節(jié)點的3主3從模式。該集群具有以下特點：

主要針對海量數(shù)據(jù)++高可用場景，海量數(shù)據(jù)，如果你的數(shù)據(jù)量很大，建議使用，當(dāng)數(shù)據(jù)量不是很大的時候，就足夠了。性能和高可用性優(yōu)于哨兵模式。

采用虛擬哈希槽分區(qū)代替一致性哈希算法，預(yù)先分配一些卡槽，所有的key根據(jù)哈希函數(shù)映射到這些槽中，每個分區(qū)中的節(jié)點負(fù)責(zé)維護(hù)一部分槽和映射槽鍵值數(shù)據(jù)。

版權(quán)聲明：本文為CSDN博主“有言先生”原創(chuàng)文章，遵循CC4.0 BY-SA版權(quán)協(xié)議。轉(zhuǎn)載請附上原文出處鏈接和本聲明。

公眾號“Java ”發(fā)布的內(nèi)容如注明出處，版權(quán)歸原作者所有（無法核實或未注明出處的版權(quán)均來自互聯(lián)網(wǎng)，轉(zhuǎn)載為傳達(dá)更多信息的目的，版權(quán)歸原作者所有，如有侵權(quán)請聯(lián)系本人，作者會第一時間刪除！

最近很多人問有沒有讀者交流群！加入方式很簡單，公眾號Java選擇，回復(fù)“加群”，即可入群！

（微信小程序）：3000+面試題，包括Java基礎(chǔ)、并發(fā)、JVM、線程、MQ系列、、系列、、、K8s、、、架構(gòu)設(shè)計等，隨時在線！

------特別推薦-----