一致性哈希和分庫分表有毛關(guān)系？
“開局一問：分庫分表行為中，一致性哈希到底用處大不大？
現(xiàn)在是大數(shù)據(jù)的時(shí)代，其中一個(gè)體現(xiàn)就是數(shù)據(jù)量非常龐大。當(dāng)然大數(shù)據(jù)的概念絕非是數(shù)據(jù)量就可以定義的，我自己給大數(shù)據(jù)下的定義是：無處不在的大量數(shù)據(jù)，這些數(shù)據(jù)是要經(jīng)過收集，加工，轉(zhuǎn)化，然后輸出具有業(yè)務(wù)意義的數(shù)據(jù)，比如：現(xiàn)在人物畫像。
回歸主題，那到底什么樣的場景下才開始分庫分表呢：
數(shù)據(jù)量大 存儲(chǔ)壓力大 提高寫操作IO 提高讀操作IO
“這里多啰嗦一句，如果你的分庫分表存儲(chǔ)最終還是落在一個(gè)物理磁盤上，其實(shí)整體IO的提高并不明顯，應(yīng)該把分出的庫（分區(qū)表）散落在多個(gè)物理磁盤，利用并行IO來提高性能。
設(shè)計(jì)到分庫分表策略，我建議選擇有業(yè)務(wù)意義的鍵值作為分的依據(jù)。舉個(gè)例子，拿用戶信息來說，如果業(yè)務(wù)中多數(shù)是根據(jù)用戶ID來取用戶信息的場景，那應(yīng)該利用用戶id作為分的策略主鍵。
接下來的部分就以用戶信息的場景來舉例說明。
分庫分表行為屬于變動(dòng)性行為，因?yàn)?，隨著數(shù)據(jù)量的不斷增大，分庫分表的策略會(huì)隨著改變，最簡單的例子，現(xiàn)在分了10個(gè)表，當(dāng)數(shù)據(jù)量到達(dá)10個(gè)表的巔峰容量時(shí)候，就需要繼續(xù)分，這就是變動(dòng)因子。最致命的是這個(gè)變動(dòng)因子會(huì)影響已有數(shù)據(jù)的定位。
現(xiàn)在有很多緩存的應(yīng)用場景和分庫分表思想類似，但是卻又有本質(zhì)的區(qū)別，因?yàn)榫彺鏀?shù)據(jù)不需要持久化，所以就算是定位錯(cuò)了，重新加載即可，數(shù)據(jù)庫可就不一樣了
簡單哈希有用嗎？
分庫分表最簡單的策略就是對(duì)業(yè)務(wù)數(shù)據(jù)鍵取模（%），以余數(shù)來作為導(dǎo)向。帶來的問題也顯而易見：
數(shù)據(jù)很有可能分布不均勻 數(shù)據(jù)量遷移量大
所以真實(shí)的落地項(xiàng)目中，用簡單哈希分庫分表的很少，這就誕生了簡單哈希無用論。
一致性哈希
一致性哈希算法在1997年由麻省理工學(xué)院提出的一種分布式哈希（DHT）實(shí)現(xiàn)算法，設(shè)計(jì)目標(biāo)是為了解決因特網(wǎng)中的熱點(diǎn)(Hot spot)問題。一致性hash算法提出了在動(dòng)態(tài)變化的Cache環(huán)境中，斷定哈希算法好壞的四個(gè)定義：
平衡性(Balance)：平衡性是指哈希的結(jié)果可以盡量分布到全部的緩沖中去，這樣可使得全部的緩沖空間都獲得利用。不少哈希算法都可以知足這一條件。 單調(diào)性(Monotonicity)：單調(diào)性是指若是已經(jīng)有一些內(nèi)容經(jīng)過哈希分派到了相應(yīng)的緩沖中，又有新的緩沖加入到系統(tǒng)中。哈希的結(jié)果應(yīng)可以保證原有已分配的內(nèi)容能夠被映射到原有的或者新的緩沖中去，而不會(huì)被映射到舊的緩沖集合中的其余緩沖區(qū)。 分散性(Spread)：在分布式環(huán)境中，終端有可能看不到全部的緩沖，而是只能看到其中的一部分。當(dāng)終端但愿經(jīng)過哈希過程將內(nèi)容映射到緩沖上時(shí)，因?yàn)椴灰粯咏K端所見的緩沖范圍有可能不一樣，從而致使哈希的結(jié)果不一致，最終的結(jié)果是相同的內(nèi)容被不一樣的終端映射到不一樣的緩沖區(qū)中。這種狀況顯然是應(yīng)該避免的，由于它致使相同內(nèi)容被存儲(chǔ)到不一樣緩沖中去，下降了系統(tǒng)存儲(chǔ)的效率。分散性的定義就是上述狀況發(fā)生的嚴(yán)重程度。好的哈希算法應(yīng)可以盡可能避免不一致的狀況發(fā)生，也就是盡可能下降分散性。 負(fù)載(Load)：負(fù)載問題其實(shí)是從另外一個(gè)角度看待分散性問題。既然不一樣的終端可能將相同的內(nèi)容映射到不一樣的緩沖區(qū)中，那么對(duì)于一個(gè)特定的緩沖區(qū)而言，也可能被不一樣的用戶映射為不一樣 的內(nèi)容。與分散性同樣，這種狀況也是應(yīng)當(dāng)避免的，所以好的哈希算法應(yīng)可以盡可能下降緩沖的負(fù)荷。
看完上邊這幾條比較官方的介紹應(yīng)該大體了解了一致性哈希的特性，用作分庫分表場景下也無可厚非，對(duì)比簡單哈希，它要好很多。
其實(shí)，一致性哈希算法也是使用取模的方法，但是它把分母擴(kuò)大到了2^32，縱觀所有的業(yè)務(wù)場景，能把數(shù)據(jù)庫（表）分到2的32次方個(gè)的也是個(gè)“人才”了。一致性哈希把2的32次方想象成一個(gè)圓形，這個(gè)圓形上有2^32個(gè)點(diǎn)。具體的一致性哈希請(qǐng)移步這里
“
一致性哈希雖然解決了一些問題，但是數(shù)據(jù)傾斜問題依然存在，為了使數(shù)據(jù)最大程度上平均分布，所以引入了虛擬哈希節(jié)點(diǎn)的玩法：對(duì)同一個(gè)物理服務(wù)器節(jié)點(diǎn)，通過不同的哈希算法或者其他手段得到多個(gè)不同的哈希值，均勻分布在哈希環(huán)上。
“其實(shí)一致性哈希環(huán)點(diǎn)的個(gè)數(shù)沒有必要是2的32次方個(gè)，我覺得只要足夠大得支撐將來業(yè)務(wù)的擴(kuò)展即可，同時(shí)能滿足最大平均分配的原則。
共識(shí)算法
共識(shí)算法在分庫分表的場景中很少有人提出，它現(xiàn)在廣泛用于分布式系統(tǒng)中，像喜聞樂見的Paxis，Raft都屬于共識(shí)算法。
分庫分表業(yè)務(wù)場景下，就算了一致性哈希做到極致，當(dāng)服務(wù)器節(jié)點(diǎn)增加或者減少的時(shí)候，總有需要數(shù)據(jù)需要遷移，只不過是多少的問題。那有沒有辦法不用遷移數(shù)據(jù)呢？
首先說明一點(diǎn)：數(shù)據(jù)庫不像緩存服務(wù)一樣，可以隨時(shí)減少節(jié)點(diǎn)。數(shù)據(jù)庫是有狀態(tài)的，一般只增不減。
利用共識(shí)算法，我認(rèn)為在只增加節(jié)點(diǎn)的情況下是可以做到不遷移數(shù)據(jù)的。因?yàn)楣沧R(shí)算法的特性就是：一個(gè)值達(dá)成一致之后，這個(gè)值就不會(huì)變化了。
假設(shè)：現(xiàn)在對(duì)用戶信息表已經(jīng)分了5張表，用戶id為1的會(huì)落在表1，id為2的會(huì)落在表2.....依此類推（這里可以先不考慮一致性哈希虛擬節(jié)點(diǎn)，因?yàn)樵眍愃疲?，?dāng)增加分表6的時(shí)候，按照簡單哈希原則，id為6的用戶信息應(yīng)該在表6中，但是現(xiàn)實(shí)情況是在表1中，按照以往的經(jīng)驗(yàn)，這條數(shù)據(jù)是需要遷移的。
但是引入了共識(shí)算法之后，id為6的用戶數(shù)據(jù)被算法認(rèn)為仍然在表1中，因?yàn)橐呀?jīng)達(dá)成了共識(shí)。前提是你需要開發(fā)一套共識(shí)算法服務(wù)來保證，為什么很少有人這么用呢，也許是共識(shí)算法門檻過高的原因，但是它卻能真正的解決我們的問題。
自增型數(shù)據(jù)
以上的說明都是針對(duì)散亂型數(shù)據(jù)而言，其實(shí)還有一種log型數(shù)據(jù)，簡單來說就一直追加型的數(shù)據(jù)，比如操作日志，這種數(shù)據(jù)的典型特點(diǎn)就是時(shí)間有序，這樣的數(shù)據(jù)進(jìn)行分庫分表，完全可以按照時(shí)間維度來進(jìn)行的，比如：可以設(shè)計(jì)一個(gè)月為一個(gè)表，類似table_202109
寫在最后
無論哪種分表方式，都避免不了熱點(diǎn)問題，就像微博，一個(gè)明星出軌了，這條數(shù)據(jù)就會(huì)成為熱點(diǎn)，而這一條數(shù)據(jù)只能存儲(chǔ)于一個(gè)表中。解決這種熱點(diǎn)問題從來都不能依靠數(shù)據(jù)庫，像緩存，CDN等解決方案才是正解。
