Redis 的元數(shù)據(jù)被存放在 ConfigDB 中。元數(shù)據(jù)包括 Redis 實例的狀態(tài)信息，以及對應(yīng)的 IP 地址和端口信息等。前端可以通過頁面對元數(shù)據(jù)進(jìn)行調(diào)整，如設(shè)置某個實例不可用或不可讀等。服務(wù)是通過 Config Service 實現(xiàn)的。服務(wù)會從 ConfigDB 中拉取配置，應(yīng)用會定期調(diào)用 Config Service 服務(wù)，獲得實例元數(shù)據(jù)信息，實現(xiàn)對 Redis 群集的實際訪問。

我們通過一致性哈希算法對 Redis 進(jìn)行分片。每一個分片都被稱為組。在每一個組中，有讀寫實例和只讀實例，它們會通過復(fù)制關(guān)系來傳遞數(shù)據(jù)。在部署時，我們盡量把實例分散到不同的服務(wù)器上。一旦服務(wù)器發(fā)生故障，則只會影響部分分片，不會嚴(yán)重影響后端數(shù)據(jù)庫。我們應(yīng)當(dāng)盡量控制 Redis 緩存的每一個實例為 10GB 左右。如果超過 10GB，則可能需要確定是否可以進(jìn)行拆分。若需要重新進(jìn)行分組，則多拆分出幾個組。

Redis 由哨兵來監(jiān)控 Redis 實例的運行狀態(tài)。我們啟用了5個哨兵來同時監(jiān)聽。哨兵的主要功能為：

• 監(jiān)控所有實例是否在正常運行；

• 當(dāng) Slave 出現(xiàn)故障時，通過消息通知機(jī)制把該 Slave 拉出，并將其設(shè)置為不可用，同時把 Master 設(shè)置為可讀、可寫；

• 當(dāng) Master 出現(xiàn)故障時，通過自動投票機(jī)制從 Slave 節(jié)點中選舉新的 Master，實現(xiàn) Redis 的自動切換。

哨兵實際上是一個運行在特殊模式下的 Redis 服務(wù)，我們可以通過在啟動命令參數(shù)中指定 sentinel 選項，來標(biāo)識該 Redis 服務(wù)是哨兵。每一個哨兵會向其他哨兵，即 Master 和 Slave 定時發(fā)送消息，以確認(rèn)對方是否正常運行，如果發(fā)現(xiàn)對方在指定時間內(nèi)未回應(yīng)，則暫時認(rèn)為對方主觀掛機(jī) ( Subjective Down，簡稱 SDOWN )。如果哨兵群中的多數(shù)哨兵都報告某個 Master 沒響應(yīng)，系統(tǒng)就會認(rèn)為該 Master 客觀掛機(jī) ( Objective Down，簡稱 ODOWN )。

通過 Redis 的運行機(jī)制可以看出，Config Service 的狀態(tài)信息需要和 Redis 實例的實際狀態(tài)信息保持一致，否則在訪問應(yīng)用時會發(fā)生異常，比如，當(dāng)只讀實例發(fā)生故障，在重新向 Master 節(jié)點全量同步數(shù)據(jù)期間，如果該實例還是配置可讀，在訪問應(yīng)用時就會報錯。當(dāng)有故障發(fā)生時，Redis 需要具備快速自動恢復(fù)的能力，減少人工干預(yù)。我們應(yīng)當(dāng)盡量從哨兵處獲得信息，如果超過半數(shù)的哨兵發(fā)生故障，則直連 Redis 實例來獲得物理狀態(tài)。

對于 Redis 異地機(jī)房容災(zāi)而言，我們需要考慮跨機(jī)房全量同步為網(wǎng)絡(luò)帶來的開銷，以及可能存在的網(wǎng)絡(luò)不穩(wěn)定因素。因此，我們采用了一個中間層，即 Keeper 來對數(shù)據(jù)進(jìn)行緩沖。在本質(zhì)上，Keeper 是偽 Slave，即實現(xiàn) Redis 協(xié)議，偽裝成 Slave，讓 Master 推送數(shù)據(jù)到 Keeper 中。受限于篇幅，對于 Redis 異地機(jī)房容災(zāi)及切換，這里就不介紹了，謝謝大家。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
																																					

																																						

長按訂閱更多精彩▼
																																					

																																						
如有收獲，點個在看，誠摯感謝