快捷導(dǎo)航

Redis分片集群、數(shù)據(jù)讀寫規(guī)則問題小結(jié)

更新時(shí)間：2025年06月20日 15:05:50 作者：崎嶇Qiu

本文介紹了Redis分片集群的原理,通過數(shù)據(jù)分片和哈希槽機(jī)制解決單機(jī)內(nèi)存限制與寫瓶頸問題,實(shí)現(xiàn)分布式存儲(chǔ)和高并發(fā)處理,但存在通信開銷大、維護(hù)復(fù)雜及對(duì)事務(wù)支持不足等局限性,感興趣的朋友跟隨小編一起看看吧

一、分片集群解決的問題

盡管主從復(fù)制和哨兵模式解決了 Redis 的高可用和高并發(fā)讀的問題，但它們?nèi)匀淮嬖趦蓚€(gè)主要限制：

海量數(shù)據(jù)存儲(chǔ)問題：所有數(shù)據(jù)都存儲(chǔ)在一個(gè) Master 節(jié)點(diǎn)上，單個(gè)節(jié)點(diǎn)的內(nèi)存容量是有限的。當(dāng)數(shù)據(jù)量非常大時(shí)，一個(gè) Master 節(jié)點(diǎn)無法承載。
高并發(fā)寫的問題：所有的寫操作都集中在 Master 節(jié)點(diǎn)上，單個(gè) Master 節(jié)點(diǎn)的寫能力是有限的。當(dāng)寫請(qǐng)求非常多時(shí)，Master 節(jié)點(diǎn)可能會(huì)成為瓶頸。

分片集群就是為了正是為了突破解決高并發(fā)寫和海量數(shù)據(jù)存儲(chǔ)上的瓶頸。

二、分片集群圖解

分片集群特征

集群中有多個(gè)master，每個(gè)master保存不同數(shù)據(jù)（每個(gè)分片數(shù)據(jù)是不同的，分片內(nèi)主從數(shù)據(jù)是相同的）
（分片內(nèi)）每個(gè)master都可以有多個(gè)slave節(jié)點(diǎn)
（不同分片間）master之間通過ping監(jiān)測(cè)彼此健康狀態(tài)
客戶端請(qǐng)求可以訪問集群任意節(jié)點(diǎn)，最終都會(huì)被轉(zhuǎn)發(fā)到正確節(jié)點(diǎn)

如何解決的上述問題？（與哨兵模式對(duì)比）

特征	分片集群	哨兵模式
數(shù)據(jù)分布	數(shù)據(jù)分散在多個(gè) Master 節(jié)點(diǎn)（數(shù)據(jù)分片）	所有數(shù)據(jù)在一個(gè) Master 節(jié)點(diǎn)（全量復(fù)制）
解決問題	海量數(shù)據(jù)存儲(chǔ)、高并發(fā)寫	高可用、高并發(fā)讀
高可用實(shí)現(xiàn)	集群內(nèi)部 Master 節(jié)點(diǎn)互相協(xié)商故障轉(zhuǎn)移	外部獨(dú)立 Sentinel 集群負(fù)責(zé)故障轉(zhuǎn)移
健康監(jiān)測(cè)	Master 節(jié)點(diǎn)之間互相監(jiān)測(cè)	Sentinel 監(jiān)測(cè) Master/Slave
節(jié)點(diǎn)間通信	Master 之間通過集群總線，Master 與 Slave 數(shù)據(jù)同步	Sentinel 與 Redis 節(jié)點(diǎn)，Sentinel 之間
客戶端連接	連接任意節(jié)點(diǎn)，通過重定向找到正確節(jié)點(diǎn)	通過 Sentinel 獲取 Master 地址，直接連接 Master
復(fù)雜性	相對(duì)復(fù)雜（數(shù)據(jù)分片、槽管理、數(shù)據(jù)遷移等）	相對(duì)簡單

使用場景

例如，在電商、在線課程等類型項(xiàng)目中，如果課程數(shù)量、用戶數(shù)量或活動(dòng)數(shù)據(jù)量非常龐大，單個(gè) Redis 實(shí)例無法承載時(shí)，可以考慮使用分片集群：

存儲(chǔ)海量課程信息：將不同的課程信息分散到不同的 Master 節(jié)點(diǎn)上，例如按照課程ID的哈希值進(jìn)行分片。
處理高并發(fā)的寫操作：例如在大型促銷活動(dòng)中，用戶頻繁修改個(gè)人信息、購物車等，這些寫操作可以分散到不同的 Master 節(jié)點(diǎn)上處理，提高整體的處理能力。

三、分片集群下的數(shù)據(jù)讀寫

面試官：你提到分片集群解決了海量數(shù)據(jù)存儲(chǔ)和高并發(fā)寫的問題，那么它是如何決定一個(gè)key應(yīng)該存儲(chǔ)在哪個(gè)Master節(jié)點(diǎn)上的呢？

答：Redis 分片集群采用哈希槽 (Hash Slot) 的方式來管理數(shù)據(jù)。整個(gè)集群共有 16384 個(gè)哈希槽。每個(gè) key 在存儲(chǔ)時(shí)，會(huì)根據(jù)其 key 的哈希值計(jì)算出一個(gè)槽號(hào)（通常是 CRC16(key) % 16384）。

集群中的每個(gè) Master 節(jié)點(diǎn)負(fù)責(zé)管理一部分哈希槽。客戶端根據(jù) key 計(jì)算出槽號(hào)后，就知道應(yīng)該去哪個(gè) Master 節(jié)點(diǎn)操作這個(gè) key。

圖示key的存儲(chǔ)過程

四、總結(jié)及缺點(diǎn)

分片集群（Redis Cluster） ：是一種分布式解決方案，它通過將數(shù)據(jù)分散存儲(chǔ)在多個(gè) Master 節(jié)點(diǎn)上，來解決海量數(shù)據(jù)存儲(chǔ)和高并發(fā)寫的問題。每個(gè) Master 節(jié)點(diǎn)負(fù)責(zé)一部分?jǐn)?shù)據(jù)（通過哈希槽分配），并且可以有自己的 Slave 節(jié)點(diǎn)來保證高可用。

缺點(diǎn)和局限性：

集群間通信開銷：集群之間的心跳檢測(cè)和數(shù)據(jù)通信會(huì)消耗大量的網(wǎng)絡(luò)帶寬

對(duì) Lua 腳本和事務(wù)支持有限：Redis 的 Lua 腳本和事務(wù)通常要求操作的 key 都在同一個(gè)節(jié)點(diǎn)上；在分片集群中，如果一個(gè) Lua 腳本或事務(wù)需要操作分布在不同 Master 節(jié)點(diǎn)上的 key，將無法執(zhí)行

維護(hù)復(fù)雜

數(shù)據(jù)遷移復(fù)雜

客戶端復(fù)雜

到此這篇關(guān)于Redis分片集群、數(shù)據(jù)讀寫規(guī)則問題小結(jié)的文章就介紹到這了,更多相關(guān)redis分片集群內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: