攜程數(shù)據(jù)庫(kù)高可用架構(gòu)實(shí)踐

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

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

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

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

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

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

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

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

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

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

																																						

長(zhǎng)按訂閱更多精彩▼
																																					

																																						
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝