Redis知識點（1）

Redis

Redis和MySQL的區別

Redis的高可用方案

Redis可以用來做什么

Redis的數據類型

字符串

列表

哈希

集合

有序集合

Bitmap

Redis為什么快呢？

I/O多路復用

說說select,poll,epoll,kqueue,IOCP的區別

Redis為什么早期選擇單線程？

Redis6.0的多線程

Redis的常用命令

set命令

sadd命令的時間復雜度

incr命令

單線程的RedisQPS能到多少？

持久化

Redis的持久化方式有哪些

RDB

bgsave 命令會在后臺 fork 一個子進程來執行 RDB 持久化操作，主進程不會被阻塞。

什么情況下會觸發？

AOF

AOF的刷盤策略

AOF的重寫機制

AOF文件存儲的是什么類型的數據

RDB和AOF的各自優缺點

RDB和AOF如何選擇

Redis如何恢復數據？

?Redis的混合持久化

高可用

主從復制

主從復制的主要作用

什么情況出現主從復制數據不一樣？

解決方案

Redis主從有幾種常見的拓撲結構

Redis的主從復制原理

全量同步和增量同步

主從復制存在哪些問題？

腦裂問題

Redis哨兵機制

Redis哨兵的工作原理

Redis的集群

Redis Cluster

集群中數據如何分區？

Redis集群的原理

部署Redis集群至少需要3個物理節點

Redis集群的動態伸縮

Redis

redis是一種鍵值對的NoSQL數據庫。

主要是把數據放在內存當中，相比直接訪問磁盤的關系型數據庫，讀寫速度會快很多，基本上能達到微妙級的響應。

所以在一些性能要求很高的場景，比如緩存熱點數據，防止接口爆刷，都會用到Redis.

不僅如此，Redis還可支持持久化，可以將內存中的數據異步落盤，以便服務宕機重啟后能恢復數據。

Redis和MySQL的區別

Redis屬于非關系型數據庫，數據是通過鍵值對的形式放在內存當中的；MySQL屬于關系型數據庫，數據以行和列的形式存儲在磁盤當中。

實際開發中，會將 MySQL 作為主存儲，Redis 作為緩存，通過先查 Redis，未命中再查 MySQL 并寫回Redis 的方式來提高系統的整體性能。

Redis的高可用方案

哨兵機制，這是一個相對成熟的高可用的解決方案，我們生產環境部署的是一主兩從的Redis實例，再加上三個Sentinel節點監控它們。Sentinel的配置相對簡單，主要設置了故障轉移的判定條件和超時閾值。

Redis Cluster 集群方案該項目數據量大且增長快，需要水平擴展能力。我們部署了 6 個主節點，每個主節點配備一個從節點，形成了一個 3主3從的初始集群。Redis Cluster 的設置比 Sentinel 復雜一些，需要正確配置集群節點間通信、分片映射等。

Redis Cluster 最大的優勢是數據自動分片，我們可以通過簡單地增加節點來擴展集群容量。此外，它的故障轉移也很快，通常在幾秒內就能完成。

Redis可以用來做什么

Redis可以用來做緩存，比如把高頻訪問的文章詳情，商品信息，用戶信息放入Redis當中，并通過設置過期時間來保證數據的一致性，這樣可以減輕數據庫的訪問壓力。

?Redis 的 Zset 還可以用來實現積分榜、熱搜榜，通過 score 字段進行排序，然后取前 N 個元素，就能實現 TOPN 的榜單功能。

利于Redis的SETNX命令或者Redission號可以實現分布式鎖，確保同一時間只有一個節點可以持有鎖；為了防止出現死鎖，可以給鎖設置一個超時時間，到期后自動釋放；并且最好開啟一個監聽線程，當任務尚未完成時給鎖自動續期。

如果是秒殺接口，還可以使用 Lua 腳本來實現令牌桶算法，限制每秒只能處理 N 個請求。

Redis的數據類型

Redis支持五種基本類型。分別是字符串，列表，哈希，集合和有序集合。

字符串

字符串是基本的數據類型，可以存儲文本，數字或者二進制數據，最大容量是512MB。

適合緩存單個對象，比如驗證碼、token、計數器等。

列表

列表是一個有序的元素集合，支持從頭部或尾部插入/刪除元素，常用于消息隊列或任務列表。

哈希

哈希是一個鍵值對集合，適合存儲對象，如商品信息、用戶信息等。

集合

集合是無序且不重復的，支持交集，并集操作，查詢效率能達到O（1）級別，主要用于去重，標簽，共同好友等場景。

有序集合

有序集合的元素安裝分數進行排序，支持范圍查詢，適用于排行榜或優先級隊列

Bitmap

Bitmap 可以把一組二進制位緊湊地存儲在一塊連續內存中，每一位代表一個對象的狀態，比如是否簽到、是否活躍等。

比如用戶 0 的已簽到 1、用戶 1 未簽到 0、用戶 2 已簽到，Redis 就會把這些狀態放進一個連續的二進制串?101，1 億用戶簽到僅需?100,000,000 / 8 / 1024 ≈ 12MB?的空間，真的省到離譜。

Redis為什么快呢？

第一，Redis 的所有數據都放在內存中，而內存的讀寫速度本身就比磁盤快幾個數量級。

第二，Redis 采用了基于 IO 多路復用技術的事件驅動模型來處理客戶端請求和執行 Redis 命令。

其中的 IO 多路復用技術可以在只有一個線程的情況下，同時監聽成千上萬個客戶端連接，解決傳統 IO 模型中每個連接都需要一個獨立線程帶來的性能開銷。IO 多路復用會持續監聽請求，然后把準備好的請求壓入到一個隊列當中，并將其有序地傳遞給文件事件分派器，最后由事件處理器來執行對應的 accept、read 和 write 請求。

第三，Redis 對底層數據結構做了極致的優化，比如說 String 的底層數據結構動態字符串支持動態擴容、預分配冗余空間，能夠減少內存碎片和內存分配的開銷。

I/O多路復用

IO 多路復用是一種允許單個進程同時監視多個文件描述符的技術，使得程序能夠高效處理多個并發連接而無需創建大量線程。

I/O多路復用的核心：讓單個線程可以等待多個文件描述符就緒，然后對就緒的描述符進行操作。這樣可以在不使用多線程或多進程的情況下處理并發連接。

說說select,poll,epoll,kqueue,IOCP的區別

select 的缺點是單個進程能監視的文件描述符數量有限，一般為1024個，且每次調用都需要將文件描述符集合從用戶態復制到內核態，然后遍歷找出就緒的描述符，性能較差

poll的優點是沒有最大文件描述符數量的限制，但是每次調用仍然需要將文件描述符集合從用戶態復制到內核態，依然需要遍歷，性能仍然較差。

epoll 是 Linux 特有的 IO 多路復用機制，支持大規模并發連接，使用事件驅動模型，性能更高。其工作原理是將文件描述符注冊到內核中，然后通過事件通知機制來處理就緒的文件描述符，不需要輪詢，也不需要數據拷貝，更沒有數量限制，所以性能非常高。

kqueue 是 BSD/macOS 系統下的 IO 多路復用機制，類似于 epoll，支持大規模并發連接，使用事件驅動模型。

IOCP 是 Windows 系統下的 IO 多路復用機制，使用使用完成端口模型而非事件通知。

Redis為什么早期選擇單線程？

第一，單線程模型不需要考慮復雜的鎖機制，不存在多線程下的死鎖，競態條件等問題，開發起來更快，也更容易維護。

第二，Redis是IO密集型而非CPU密集型，主要受內存和網絡IO限制，非CPU的計算能力，單線程可以避免上下文切換的開銷。

第三單線程可以保證命令執行的原子性，無需額外的同步機制。

Redis6.0的多線程

Redis 6.0 的多線程僅用于處理網絡 IO，包括網絡數據的讀取、寫入，以及請求解析。

而命令的執行依然是單線程，這種設計被稱為IO線程化，能夠在高負載的情況下，最大限度地提升Redis的響應速度。

Redis的常用命令

?操作字符串可以用Set/get/incr，操作哈希可以用hset,hget,hgetall，操作列表可以用?LPUSH/LPOP/LRANGE，操作集合可以用?SADD/SISMEMBER，操作有序集合可以用?ZADD/ZRANGE/ZINCRBY等，通用命令有?EXPIRE/DEL/KEYS?等。

set命令

set命令用于設置字符串的key,支持過期時間和條件寫入，常用于設置緩存、實現分布式鎖、延長 Session 等場景。

sadd命令的時間復雜度

SADD 支持一次添加多個元素，返回值為實際添加成功的元素數量，時間復雜度為 O(N)。

incr命令

INCR 是一個原子命令，可以將指定鍵的值加 1，如果 key 不存在，會先將其設置為 0，再執行加 1 操作。

單線程的RedisQPS能到多少？

一個普通服務器的 Redis 實例通常可以達到每秒十萬左右的 QPS。

持久化

Redis的持久化方式有哪些

主要有兩種，RDB 和 AOF。RDB 通過創建時間點快照來實現持久化，AOF 通過記錄每個寫操作命令來實現持久化。

這兩種方式可以單獨使用，也可以同時使用。這樣就可以保證 Redis 服務器在重啟后不丟失數據，通過 RDB 和 AOF 文件來恢復內存中原有的數據。

RDB

RDB持久化機制可以在指定的時間間隔內將Redis某一時刻的數據保存到磁盤上的RDB文件中，當Redis重啟，可以通過加載這個RDB文件來恢復數據。

RDB 持久化可以通過 save 和 bgsave 命令手動觸發，也可以通過配置文件中的 save 指令自動觸發。

save 命令會阻塞 Redis 進程，直到 RDB 文件創建完成。

bgsave 命令會在后臺 fork 一個子進程來執行 RDB 持久化操作，主進程不會被阻塞。

什么情況下會觸發？

第一種，在 Redis 配置文件中設置 RDB 持久化參數?save <seconds> <changes>，表示在指定時間間隔內，如果有指定數量的鍵發生變化，就會自動觸發 RDB 持久化。

第二種，主從復制時，當從節點第一次連接到主節點時，主節點會自動執行 bgsave 生成 RDB 文件，并將其發送給從節點。

第三種，如果沒有開啟 AOF，執行 shutdown 命令時，Redis 會自動保存一次 RDB 文件，以確保數據不會丟失。

AOF

AOF 通過記錄每個寫操作命令，并將其追加到 AOF 文件來實現持久化，Redis 服務器宕機后可以通過重新執行這些命令來恢復數據。

當 Redis 執行寫操作時，會將寫命令追加到 AOF 緩沖區；Redis 會根據同步策略將緩沖區的數據寫入到 AOF 文件。

當 AOF 文件過大時，Redis 會自動進行 AOF 重寫，剔除多余的命令，比如說多次對同一個 key 的 set 和 del，生成一個新的 AOF 文件；當 Redis 重啟時，讀取 AOF 文件中的命令并重新執行，以恢復數據。

AOF的刷盤策略

Redis 將 AOF 緩沖區的數據寫入到 AOF 文件時，涉及兩個系統調用：write 將數據寫入到操作系統的緩沖區，fsync 將 OS 緩沖區的數據刷新到磁盤。

這里的刷盤涉及到三種策略：always、everysec 和 no。

always：每次寫命令執行完，立即調用 fsync 同步到磁盤，這樣可以保證數據不丟失，但性能較差。
everysec：每秒調用一次 fsync，將多條命令一次性同步到磁盤，性能較好，數據丟失的時間窗口為 1 秒。
no：不主動調用 fsync，由操作系統決定，性能最好，但數據丟失的時間窗口不確定，依賴于操作系統的緩存策略，可能會丟失大量數據。

AOF的重寫機制

由于 AOF 文件會隨著寫操作的增加而不斷增長，為了解決這個問題， Redis 提供了重寫機制來對 AOF 文件進行壓縮和優化。

AOF 重寫可以通過兩種方式觸發，第一種是手動執行?BGREWRITEAOF?命令，適用于需要立即減小AOF文件大小的場景。

第二種是在 Redis 配置文件中設置自動重寫參數，比如說?auto-aof-rewrite-percentage?和?auto-aof-rewrite-min-size，表示當 AOF 文件大小超過指定值時，自動觸發重寫。

AOF文件存儲的是什么類型的數據

AOF存儲的是Redis服務器接受到的寫命令數據，以Redis協議格式保存。

RDB和AOF的各自優缺點

RDB 通過 fork 子進程在特定時間點對內存數據進行全量備份，生成二進制格式的快照文件。其最大優勢在于備份恢復效率高，文件緊湊，恢復速度快，適合大規模數據的備份和遷移場景。

缺點是可能丟失兩次快照期間的所有數據變更。

AOF 會記錄每一條修改數據的寫命令。這種日志追加的方式讓 AOF 能夠提供接近實時的數據備份，數據丟失風險可以控制在 1 秒內甚至完全避免。

缺點是文件體積較大，恢復速度慢。

RDB和AOF如何選擇

如果是緩存場景，可以接受一定程度的數據丟失，我會傾向于選擇 RDB 或者完全不使用持久化。RDB 的快照方式對性能影響小，而且恢復速度快，非常適合這類場景。

但如果是處理訂單或者支付這樣的核心業務，數據丟失將造成嚴重后果，那么 AOF 就成為必然選擇。通過配置每秒同步一次，可以將潛在的數據丟失風險限制在可接受范圍內。

在實際的項目當中，我更偏向于使用 RDB + AOF 的混合模式。

Redis如何恢復數據？

當 Redis 服務重啟時，它會優先查找 AOF 文件，如果存在就通過重放其中的命令來恢復數據；如果不存在或未啟用 AOF，則會嘗試加載 RDB 文件，直接將二進制數據載入內存來恢復。

?Redis的混合持久化

混合持久化結合了 RDB 和 AOF 兩種方式的優點，解決了它們各自的不足。在 Redis 4.0 之前，我們要么面臨 RDB 可能丟失數據的風險，要么承受 AOF 恢復慢的問題，很難兩全其美。

混合持久化的工作原理非常巧妙：在 AOF 重寫期間，先以 RDB 格式將內存中的數據快照保存到 AOF 文件的開頭，再將重寫期間的命令以 AOF 格式追加到文件末尾。

這樣，當需要恢復數據時，Redis 先加載 RDB 格式的數據來快速恢復大部分的數據，然后通過重放命令恢復最近的數據，這樣就能在保證數據完整性的同時，提升恢復速度。

高可用

主從復制

主從復制允許從節點維護主節點的數據副本。在這種架構中，一個主節點可以連接多個從節點，從而形成一主多從的結構。主節點負責處理寫操作，從節點自動同步主節點的數據變更，并處理讀請求，從而實現讀寫分離。

主從復制的主要作用

第一，主節點負責處理寫請求，從節點負責處理讀請求，從而實現讀寫分離，減輕主節點壓力的同時提升系統的并發能力

第二從節點可以作為主節點的數據備份，當主節點發生故障時，可以快速將從節點提升為新的主節點，從而保證系統的高可用

什么情況出現主從復制數據不一樣？

Redis的主從復制是異步進行的，因此在主節點宕機，網絡波動或復制延遲較高時會出現從節點數據不同步的情況

?比如主節點寫入數據后宕機，但從節點還未來得及復制，就會出現數據不一致。

另一個容易被忽視的因素是主節點內存壓力。當主節點內存接近上限并啟用了淘汰策略時，某些鍵可能被自動刪除，而這些刪除操作如果未能及時同步，就會造成從節點保留了主節點已經不存在的數據。

解決方案

首先是網絡層面的優化，理想情況下，主從節點應該部署在同一個網絡區域內，避免跨區域的網絡延遲。

其次是配置層面的調整，比如說適當增大復制積壓緩沖區的大小和存活時間，以便從節點重連后進行增量同步而不是全量同步，以最大程度減少主從同步的延遲。

第三是引入監控和自動修復機制，定期檢查主從節點的數據一致性。

Redis主從有幾種常見的拓撲結構

主要有三種

最最基礎的是一主一從，這種模式適合小型項目。一個主節點負責寫入，一個從節點負責讀和數據備份。

一主多從

隨著業務增長，讀請求增多，主節點負責寫入，多個從節點還可以分攤壓力。

樹狀主從

在跨地域部署場景中，樹狀主從結構可以有效降低主節點負載和需要傳送給從節點的數據量。通過引入復制中間層，從節點不僅可以復制主節點數據，同時可以作為其他從節點的主節點繼續向下層復制。

Redis的主從復制原理

Redis的主從復制是指通過異步復制將主節點的數據變更到從節點，從而實現數據備份和讀寫分離，這個過程大致可以分為三個階段：建立連接、同步數據和傳播命令。

在建立連接階段，從節點通過執行?replicaof?命令連接到主節點。連接建立后，從節點向主節點發送?psync?命令，請求數據同步。這時主節點會為該從節點創建一個連接和復制緩沖區。

同步數據階段分為全量同步和增量同步。當從節點首次連接主節點時，會觸發全量同步。

在這個過程中，主節點會 fork 一個子進程生成 RDB 文件，同時將文件生成期間收到的寫命令緩存到復制緩沖區。然后將 RDB 文件發送給從節點，從節點清空自己的數據并加載這個 RDB 文件。等 RDB 傳輸完成后，主節點再將緩存的寫命令發送給從節點執行，確保數據完全一致。

主從完成全量同步后，主要依靠傳播命令階段來保持數據的增量同步。主節點會將每次執行的寫命令實時發送給所有從節點。

全量同步和增量同步

全量同步會將主節點的完整數據集傳輸給從節點，通常全量同步的代價很高，因為完整的 RDB 文件在生成時會占用大量的 CPU 和磁盤 IO；在網絡傳輸時還會消耗掉不少帶寬。全量同步會將主節點的完整數據集傳輸給從節點，通常發生在從節點首次連接主節點時。

于是 Redis 在 2.8 版本后引入了增量同步的概念，目的是在斷線重連后避免全量同步。

①、復制偏移量：主從節點分別維護一個復制偏移量，記錄傳輸的字節數。主節點每傳輸 N 個字節數據，自身的復制偏移量就會增加 N；從節點每收到 N 個字節數據，也會相應增加自己的偏移量。

②、主節點 ID：每個主節點都有一個唯一 ID，即復制 ID，用于標識主節點的數據版本。當主節點發生重啟或者角色變化時，ID 會改變。

③、復制積壓緩沖區：主節點維護的一個固定長度的先進先出隊列，默認大小為 1M。主節點在向從節點發送命令的同時，也會將命令寫入這個緩沖區。

主從復制存在哪些問題？

Redis 主從復制的最大挑戰來自于它的異步特性，主節點處理完寫命令后會立即響應客戶端，而不會等待從節點確認，這就導致在某些情況下可能出現數據不一致。

另一個常見問題是全量同步對系統的沖擊。全量同步會占用大量的 CPU 和 IO 資源，尤其是在大數據量的情況下，會導致主節點的性能下降。、

腦裂問題

在 Redis 的哨兵架構中，腦裂的典型表現為：主節點與哨兵、從節點之間的網絡發生故障了，但與客戶端的連接是正常的，就會出現兩個“主節點”同時對外提供服務。

哨兵認為主節點已經下線了，于是會將一個從節點選舉為新的主節點。但原主節點并不知情，仍然在繼續處理客戶端的請求。

等主節點網絡恢復正常了，發現已經有新的主節點了，于是原主節點會自動降級為從節點。在降級過程中，它需要與新主節點進行全量同步，此時原主節點的數據會被清空。導致客戶端在原主節點故障期間寫入的數據全部丟失。

Redis哨兵機制

Redis 中的哨兵用于監控主從集群的運行狀態，并在主節點故障時自動進行故障轉移。

?核心功能包括監控、通知和自動故障轉移。哨兵會定期檢查主從節點是否按預期工作，當檢測到主節點故障時，就在從節點中選舉出一個新的主節點，并通知客戶端連接到新的主節點。

Redis哨兵的工作原理

哨兵的工作原理可以概括為 4 個關鍵步驟：定時監控、主觀下線、領導者選舉和故障轉移。

首先，哨兵會定期向所有 Redis 節點發送 PING 命令來檢測它們是否可達。如果在指定時間內沒有收到回復，哨兵會將該節點標記為“主觀下線。

當一個哨兵判斷主節點主觀下線后，會詢問其他哨兵的意見，如果達到配置的法定人數，主節點會被標記為“客觀下線”。

然后開始故障轉移，這個過程中，哨兵會先選舉出一個領導者，領導者再從從節點中選擇一個最適合的節點作為新的主節點，選擇標準包括復制偏移量、優先級等因素。

確定新主節點后，哨兵會向其發送?SLAVEOF NO ONE?命令使其升級為主節點，然后向其他從節點發送 SLAVEOF 命令指向新主節點，最后通過發布/訂閱機制通知客戶端主節點已經發生變化。

Redis的集群

主從復制實現了讀寫分離和數據備份，哨兵機制實現了主節點故障時自動進行故障轉移。

集群架構是對前兩種方案的進一步擴展和完善，通過數據分片解決 Redis 單機內存大小的限制，當用戶基數從百萬增長到千萬級別時，我們只需簡單地向集群中添加節點，就能輕松應對不斷增長的數據量和訪問壓力。

Redis Cluster

Redis Cluster 是 Redis 官方提供的一種分布式集群解決方案。其核心理念是去中心化，采用 P2P 模式，沒有中心節點的概念。每個節點都保存著數據和整個集群的狀態，節點之間通過 gossip 協議交換信息。

在數據分片方面，Redis Cluster 使用哈希槽機制將整個集群劃分為 16384 個單元。

集群中數據如何分區？

常見的數據分區有三種：節點取余、一致性哈希和哈希槽。

節點取余分區簡單明了，通過計算鍵的哈希值，然后對節點數量取余，結果就是目標節點的索引。

缺點是增加一個新節點后，節點數量從 N 變為 N+1，幾乎所有的取余結果都會改變，導致大部分緩存失效。

為了解決節點變化導致的大規模數據遷移問題，一致性哈希分區出現了：它將整個哈希值空間想象成一個環，節點和數據都映射到這個環上。數據被分配到順時針方向上遇到的第一個節點。

這種設計的巧妙之處在于，當節點數量變化時，只有部分數據需要重新分配。比如說我們從 5 個節點擴容到 8 個節點，理論上只有約 3/8 的數據需要遷移，大大減輕了擴容時的系統壓力。

但一致性哈希仍然有一個問題：數據分布不均勻。比如說在上面的例子中，節點 1 和節點 2 的數據量差不多，但節點 3 的數據量卻遠遠小于它們。

Redis Cluster 的哈希槽分區在一致性哈希和節點取余的基礎上，做了一些改進。它將整個哈希值空間劃分為 16384 個槽位，每個節點負責一部分槽，數據通過 CRC16 算法計算后對 16384 取模，確定它屬于哪個槽。

假設系統中有 4 個節點，為其分配了 16 個槽(0-15)；

槽 0-3 位于節點 node1；
槽 4-7 位于節點 node2；
槽 8-11 位于節點 node3；
槽 12-15 位于節點 node4。

如果此時刪除?node2，只需要將槽 4-7 重新分配即可，例如將槽 4-5 分配給?node1，槽 6 分配給?node3，槽 7 分配給?node4，數據在節點上的分布仍然較為均衡。

如果此時增加 node5，也只需要將一部分槽分配給 node5 即可，比如說將槽 3、槽 7、槽 11、槽 15 遷移給 node5，節點上的其他槽位保留。

因為槽的個數剛好是 2 的 14 次方，和 HashMap 中數組的長度必須是 2 的冪次方有著異曲同工之妙。它能保證擴容后，大部分數據停留在擴容前的位置，只有少部分數據需要遷移到新的槽上。

Redis集群的原理

Redis 集群的搭建始于節點的添加和握手。每個節點通過設置?cluster-enabled yes?來開啟集群模式。然后通過?CLUSTER MEET?進行握手，將對方添加到各自的節點列表中。

這個過程設計的非常精巧：節點 A 發送 MEET 消息，節點 B 回復 PONG 并發送 PING，節點 A 回復 PONG，于是雙向的通信鏈路就建立完成了。

有趣的是，由于采用了 Gossip 協議，我們不需要讓每對節點都執行握手。在一個多節點集群的部署中，僅需要讓第一個節點與其他節點握手，其余節點就能通過信息傳播自動發現并連接彼此。

握手完成后，可以通過?CLUSTER ADDSLOTS?命令為主節點分配哈希槽。當 16384 個槽全部分配完畢，集群正式進入就緒狀態。

故障檢測和恢復是保障 Redis 集群高可用的關鍵。每秒鐘，節點會向一定數量的隨機節點發送 PING 消息，當發現某個節點長時間未響應 PING 消息，就會將其標記為主觀下線。當半數以上的主節點都認為某節點主觀下線時，這個節點就會被標記為“客觀下線”。

如果下線的是主節點，它的從節點之一將被選舉為新的主節點，接管原主節點負責的哈希槽。

部署Redis集群至少需要3個物理節點

Redis集群的動態伸縮

Redis 集群動態伸縮的核心機制是通過重新分配哈希槽實現的。當需要擴容時，首先通過?CLUSTER MEET?命令將新節點加入集群；然后使用 reshard 命令將部分哈希槽重新分配給新節點。