首頁猿問一致性哈希的實際應(yīng)用

一致性哈希的實際應(yīng)用

JavaScript

暮色呼如 2019-04-08 11:16:47

前言今天重看了一下一致性哈希的論文，心里有幾處不清楚的地方，求指導(dǎo)場景四臺server服務(wù)器（192.168.1.1-4），redis數(shù)據(jù)庫，存儲key-value鍵值對問題1首先，redis的key-value數(shù)據(jù)一般需要3份備份，對應(yīng)到一致性哈希的場景，可以說有一臺主服務(wù)器，和2臺從服務(wù)器。問題：從服務(wù)器的選取是一致性哈希代碼里選取三個不同的server，還是選取一個server，然后給這個server再配上兩臺從服務(wù)器呢（這樣服務(wù)器從原先的4臺，增加到4+2*4=12臺），我考慮用memcache記錄key、主、從分布表問題2如果冗余到其他兩臺服務(wù)器，假設(shè)是A\B\C\D四臺服務(wù)器，key的主庫是A，備份庫在BC上，那當(dāng)A單點故障，BC之間如何選擇，BC上針對A節(jié)點的增刪改數(shù)據(jù)如何再恢復(fù)給A節(jié)點嗎？我看了NRW模型，但是沒能完全理解解答1群里有人提示，服務(wù)器端可以用HAproxy+Keepalived實現(xiàn)每個機器主備模式，其實相當(dāng)于一致性哈希的環(huán)上真正只有4個可用的target，卻需要8臺服務(wù)器來完成

查看完整描述

2 回答

精慕HU

TA貢獻1845條經(jīng)驗獲得超8個贊

根據(jù)樓主想要使用一致性哈希算法來看，基本上是把redis當(dāng)做緩存使用，而不是數(shù)據(jù)庫；而使用一致性哈希的主要目的通常都是：當(dāng)集群中機器數(shù)量發(fā)生變化時，減少緩存失效范圍，防止“雪崩”；在這種情況下，我想到了另一個問題：是不是一定要用哈希一致性算法？按照我的想法，根據(jù)redis目前提供的一些特性，或許使用下面這種常見架構(gòu)，就能解決剛才的問題;1臺master，n臺slave，然后采取讀寫分離的方式，master處理寫請求，slave負責(zé)處理讀請求（負載均衡）這種部署方式有什么優(yōu)勢？當(dāng)業(yè)務(wù)訪問量猛增時，我們可以快速新增一臺redis機器，連上master，當(dāng)完成主從復(fù)制后，放入到slave集群，開始對外提供服務(wù)；當(dāng)slave集群中有一臺機器掛掉后，可以通過某種機制被識別（借鑒sentinel），并將它從slave集群中踢出；這樣子無論slave集群如何變化，都不會出現(xiàn)cache失效或者部分失效問題;這種部署方式有什么劣勢？redis目前主從復(fù)制過程有個很不好的地方就是：當(dāng)slave和master在同步過程中，網(wǎng)絡(luò)出現(xiàn)問題，這時候slave要求master重傳而不是續(xù)傳（重新生成一份RDB文件然后傳輸）；這樣當(dāng)master中數(shù)據(jù)很多的時候，影響會很大，所以一個master下掛多個slave穩(wěn)定性會下降；以上僅為個人一點想法，拿出來和樓主探討

反對回復(fù) 2019-04-08

慕桂英3389331

TA貢獻2036條經(jīng)驗獲得超8個贊

這兩天看了一點架構(gòu)的東西，這個問題基本可以關(guān)閉了解決方案還是采用8個server，主備的方式，采用一致性哈希算法增加節(jié)點服務(wù)器可以通過虛擬節(jié)點和權(quán)重來防止數(shù)據(jù)偏移，這里的節(jié)點服務(wù)器可以用VIP來標識主備服務(wù)器之間可以采用keepalived方案，對外提供的是虛擬ip，自動故障轉(zhuǎn)移，至于主備服務(wù)器的數(shù)據(jù)庫同步，可以用redis提供的主從機制，也可以自己crontab+aof日志，可以再redis數(shù)據(jù)庫上再封裝一層insert或者update操作，對外提供api接口，需要操作時訪問該接口即可

反對回復(fù) 2019-04-08