Java面試題中的Redis大合集，所有你想找的都在這里！

概述

• Redis 是一個開源的，基於內存的結構化數據存儲媒介，可以作為數據庫、緩存服務或消息服務使用。```

• Redis 支持多種數據結構，包括字符串、哈希表、鏈表、集合、有序集合、位圖、Hyperloglogs 等。
• Redis 具備 LRU 淘汰、事務實現、以及不同級別的硬盤持久化等能力，並且支持副本集和通過 Redis Sentinel 實現的高可用方案，同時還支持通過 Redis Cluster 實現的數據自動分片能力。

• Redis 的主要功能都基於單線程模型實現，也就是說 Redis 使用一個線程來服務所有的客戶端請求，同時 Redis 采用了非阻塞式 IO，並精細地優化各種命令的算法時間復雜度，這些信息意味着：

• Redis 是線程安全的（因為只有一個線程），其所有操作都是原子的，不會因並發產生數據異常
• Redis 的速度非常快（因為使用非阻塞式 IO，且大部分命令的算法時間復雜度都是 O (1))
• 使用高耗時的 Redis 命令是很危險的，會占用唯一的一個線程的大量處理時間，導致所有的請求都被拖慢。（例如時間復雜度為 O (N) 的 KEYS 命令，嚴格禁止在生產環境中使用

 

Redis 的數據結構和相關常用命令

完整的 Redis 命令集，或了解某個命令的詳細使用方法，請參考官方文檔：https://redis.io/commands
Key

Redis 采用 Key-Value 型的基本數據結構，任何二進制序列都可以作為 Redis 的 Key 使用（例如普通的字符串或一張 JPEG 圖片）

關於Key的一些注意事項：

• 不要使用過長的 Key。例如使用一個 1024 字節的 key 就不是一個好主意，不僅會消耗更多的內存，還會導致查找的效率降低
• Key 短到缺失了可讀性也是不好的，例如”u1000flw” 比起”user:1000:followers” 來說，節省了寥寥的存儲空間，卻引發了可讀性和可維護性上的麻煩
• 最好使用統一的規范來設計 Key，比如”object-type:id:attr”，以這一規范設計出的 Key 可能是”user:1000″或”comment:1234:reply-to”
• Redis 允許的最大 Key 長度是 512MB（對 Value 的長度限制也是 512MB）

String

String 是 Redis 的基礎數據類型，Redis 沒有 Int、Float、Boolean 等數據類型的概念，所有的基本類型在 Redis 中都以 String 體現。

與String相關的常用命令：

• SET：為一個 key 設置 value，可以配合 EX/PX 參數指定 key 的有效期，通過 NX/XX 參數針對 key 是否存在的情況進行區別操作，時間復雜度 O (1)
• GET：獲取某個 key 對應的 value，時間復雜度 O (1)
• GETSET：為一個 key 設置 value，並返回該 key 的原 value，時間復雜度 O (1)
• MSET：為多個 key 設置 value，時間復雜度 O (N)
• MSETNX：同 MSET，如果指定的 key 中有任意一個已存在，則不進行任何操作，時間復雜度 O (N)
• MGET：獲取多個 key 對應的 value，時間復雜度 O (N)

上文提到過，Redis的基本數據類型只有String，但Redis可以把String作為整型或浮點型數字來使用，主要體現在INCR、DECR類的命令上：

• INCR：將 key 對應的 value 值自增 1，並返回自增后的值。只對可以轉換為整型的 String 數據起作用。時間復雜度 O (1)
• INCRBY：將 key 對應的 value 值自增指定的整型數值，並返回自增后的值。只對可以轉換為整型的 String 數據起作用。時間復雜度 O (1)
• DECR/DECRBY：同 INCR/INCRBY，自增改為自減。
• INCR/DECR 系列命令要求操作的 value 類型為 String，並可以轉換為 64 位帶符號的整型數字，否則會返回錯誤。

也就是說，進行 INCR/DECR 系列命令的 value，必須在 [-2^63 ~ 2^63 – 1] 范圍內。
前文提到過，Redis 采用單線程模型，天然是線程安全的，這使得 INCR/DECR 命令可以非常便利的實現高並發場景下的精確控制。

例1：庫存控制

• 在高並發場景下實現庫存余量的精准校驗，確保不出現超賣的情況。
• 設置庫存總量：

  SET inv:remain "100"

• 庫存扣減 + 余量校驗：

  `DECR inv:remain`

• 當 DECR 命令返回值大於等於 0 時，說明庫存余量校驗通過，如果返回小於 0 的值，則說明庫存已耗盡。
• 假設同時有 300 個並發請求進行庫存扣減，Redis 能夠確保這 300 個請求分別得到 99 到 - 200 的返回值，每個請求得到的返回值都是唯一的，絕對不會找出現兩個請求得到一樣的返回值的情況。

例2：自增序列生成

• 實現類似於 RDBMS 的 Sequence 功能，生成一系列唯一的序列號
• 設置序列起始值：

  SET sequence "10000"

• 獲取一個序列值：

  INCR sequence

• 直接將返回值作為序列使用即可。
• 獲取一批（如 100 個）序列值：

  INCRBY sequence 100

• 假設返回值為 N，那么 [N – 99 ~ N] 的數值都是可用的序列值。
• 當多個客戶端同時向 Redis 申請自增序列時，Redis 能夠確保每個客戶端得到的序列值或序列范圍都是全局唯一的，絕對不會出現不同客戶端得到了重復的序列值的情況。

List

Redis 的 List 是鏈表型的數據結構，可以使用 LPUSH/RPUSH/LPOP/RPOP 等命令在 List 的兩端執行插入元素和彈出元素的操作。雖然 List 也支持在特定 index 上插入和讀取元素的功能，但其時間復雜度較高（O (N)），應小心使用。

與List相關的常用命令：

• LPUSH：向指定 List 的左側（即頭部）插入 1 個或多個元素，返回插入后的 List 長度。時間復雜度 O (N)，N 為插入元素的數量
• RPUSH：同 LPUSH，向指定 List 的右側（即尾部）插入 1 或多個元素
• LPOP：從指定 List 的左側（即頭部）移除一個元素並返回，時間復雜度 O (1)
• RPOP：同 LPOP，從指定 List 的右側（即尾部）移除 1 個元素並返回
• LPUSHX/RPUSHX：與 LPUSH/RPUSH 類似，區別在於，LPUSHX/RPUSHX 操作的 key 如果不存在，則不會進行任何操作
• LLEN：返回指定 List 的長度，時間復雜度 O (1)
• LRANGE：返回指定 List 中指定范圍的元素（雙端包含，即 LRANGE key 0 10 會返回 11 個元素），時間復雜度 O (N)。應盡可能控制一次獲取的元素數量，一次獲取過大范圍的 List 元素會導致延遲，同時對長度不可預知的 List，避免使用 LRANGE key 0 -1 這樣的完整遍歷操作。

應謹慎使用的List相關命令：

• LINDEX：返回指定 List 指定 index 上的元素，如果 index 越界，返回 nil。index 數值是回環的，即 - 1 代表 List 最后一個位置，-2 代表 List 倒數第二個位置。時間復雜度 O (N)
• LSET：將指定 List 指定 index 上的元素設置為 value，如果 index 越界則返回錯誤，時間復雜度 O (N)，如果操作的是頭 / 尾部的元素，則時間復雜度為 O (1)
• LINSERT：向指定 List 中指定元素之前 / 之后插入一個新元素，並返回操作后的 List 長度。如果指定的元素不存在，返回 - 1。如果指定 key 不存在，不會進行任何操作，時間復雜度 O (N)
• 由於 Redis 的 List 是鏈表結構的，上述的三個命令的算法效率較低，需要對 List 進行遍歷，命令的耗時無法預估，在 List 長度大的情況下耗時會明顯增加，應謹慎使用。
  換句話說，Redis 的 List 實際是設計來用於實現隊列，而不是用於實現類似 ArrayList 這樣的列表的。如果你不是想要實現一個雙端出入的隊列，那么請盡量不要使用 Redis 的 List 數據結構。
  為了更好支持隊列的特性，Redis 還提供了一系列阻塞式的操作命令，如 BLPOP/BRPOP 等，能夠實現類似於 BlockingQueue 的能力，即在 List 為空時，阻塞該連接，直到 List 中有對象可以出隊時再返回。針對阻塞類的命令，此處不做詳細探討，請參考官方文檔（https://redis.io/topics/data-types-intro） 中”Blocking operations on lists” 一節。

Hash

• Hash 即哈希表，Redis 的 Hash 和傳統的哈希表一樣，是一種 field-value 型的數據結構，可以理解成將 HashMap 搬入 Redis。
• Hash 非常適合用於表現對象類型的數據，用 Hash 中的 field 對應對象的 field 即可。

Hash的優點

• 可以實現二元查找，如” 查找 ID 為 1000 的用戶的年齡”
• 比起將整個對象序列化后作為 String 存儲的方法，Hash 能夠有效地減少網絡傳輸的消耗
• 當使用 Hash 維護一個集合時，提供了比 List 效率高得多的隨機訪問命令

與Hash相關的常用命令

• HSET：將 key 對應的 Hash 中的 field 設置為 value。如果該 Hash 不存在，會自動創建一個。時間復雜度 O (1)
• HGET：返回指定 Hash 中 field 字段的值，時間復雜度 O (1)
• HMSET/HMGET：同 HSET 和 HGET，可以批量操作同一個 key 下的多個 field，時間復雜度：O (N)，N 為一次操作的 field 數量
• HSETNX：同 HSET，但如 field 已經存在，HSETNX 不會進行任何操作，時間復雜度 O (1)
• HEXISTS：判斷指定 Hash 中 field 是否存在，存在返回 1，不存在返回 0，時間復雜度 O (1)
• HDEL：刪除指定 Hash 中的 field（1 個或多個），時間復雜度：O (N)，N 為操作的 field 數量
• HINCRBY：同 INCRBY 命令，對指定 Hash 中的一個 field 進行 INCRBY，時間復雜度 O (1)

應謹慎使用的Hash相關命令：

• HGETALL：返回指定 Hash 中所有的 field-value 對。返回結果為數組，數組中 field 和 value 交替出現。時間復雜度 O (N)
• HKEYS/HVALS：返回指定 Hash 中所有的 field/value，時間復雜度 O (N)

上述三個命令都會對 Hash 進行完整遍歷，Hash 中的 field 數量與命令的耗時線性相關，對於尺寸不可預知的 Hash，應嚴格避免使用上面三個命令，而改為使用 HSCAN 命令進行游標式的遍歷，具體請見 https://redis.io/commands/scan

Set

Redis Set 是無序的，不可重復的 String 集合。

與Set相關的常用命令

• SADD：向指定 Set 中添加 1 個或多個 member，如果指定 Set 不存在，會自動創建一個。時間復雜度 O (N)，N 為添加的 member 個數
• SREM：從指定 Set 中移除 1 個或多個 member，時間復雜度 O (N)，N 為移除的 member 個數
• SRANDMEMBER：從指定 Set 中隨機返回 1 個或多個 member，時間復雜度 O (N)，N 為返回的 member 個數
• SPOP：從指定 Set 中隨機移除並返回 count 個 member，時間復雜度 O (N)，N 為移除的 member 個數
• SCARD：返回指定 Set 中的 member 個數，時間復雜度 O (1)
• SISMEMBER：判斷指定的 value 是否存在於指定 Set 中，時間復雜度 O (1)
• SMOVE：將指定 member 從一個 Set 移至另一個 Set

慎用的Set相關命令：

• SMEMBERS：返回指定 Hash 中所有的 member，時間復雜度 O (N)
• SUNION/SUNIONSTORE：計算多個 Set 的並集並返回 / 存儲至另一個 Set 中，時間復雜度 O (N)，N 為參與計算的所有集合的總 member 數
• SINTER/SINTERSTORE：計算多個 Set 的交集並返回 / 存儲至另一個 Set 中，時間復雜度 O (N)，N 為參與計算的所有集合的總 member 數
• SDIFF/SDIFFSTORE：計算 1 個 Set 與 1 或多個 Set 的差集並返回 / 存儲至另一個 Set 中，時間復雜度 O (N)，N 為參與計算的所有集合的總 member 數

上述幾個命令涉及的計算量大，應謹慎使用，特別是在參與計算的 Set 尺寸不可知的情況下，應嚴格避免使用。可以考慮通過 SSCAN 命令遍歷獲取相關 Set 的全部 member（具體請見 https://redis.io/commands/scan ），如果需要做並集 / 交集 / 差集計算，可以在客戶端進行，或在不服務實時查詢請求的 Slave 上進行。

Sorted Set

• Redis Sorted Set 是有序的、不可重復的 String 集合。Sorted Set 中的每個元素都需要指派一個分數 (score)，Sorted Set 會根據 score 對元素進行升序排序。如果多個 member 擁有相同的 score，則以字典序進行升序排序。
• Sorted Set 非常適合用於實現排名。

Sorted Set的主要命令：

• ZADD：向指定 Sorted Set 中添加 1 個或多個 member，時間復雜度 O (Mlog (N))，M 為添加的 member 數量，N 為 Sorted Set 中的 member 數量
• ZREM：從指定 Sorted Set 中刪除 1 個或多個 member，時間復雜度 O (Mlog (N))，M 為刪除的 member 數量，N 為 Sorted Set 中的 member 數量
• ZCOUNT：返回指定 Sorted Set 中指定 score 范圍內的 member 數量，時間復雜度：O (log (N))
• ZCARD：返回指定 Sorted Set 中的 member 數量，時間復雜度 O (1)
• ZSCORE：返回指定 Sorted Set 中指定 member 的 score，時間復雜度 O (1)
• ZRANK/ZREVRANK：返回指定 member 在 Sorted Set 中的排名，ZRANK 返回按升序排序的排名，ZREVRANK 則返回按降序排序的排名。時間復雜度 O (log (N))
• ZINCRBY：同 INCRBY，對指定 Sorted Set 中的指定 member 的 score 進行自增，時間復雜度 O (log (N))

慎用的Sorted Set相關命令：

• ZRANGE/ZREVRANGE：返回指定 Sorted Set 中指定排名范圍內的所有 member，ZRANGE 為按 score 升序排序，ZREVRANGE 為按 score 降序排序，時間復雜度 O (log (N)+M)，M 為本次返回的 member 數
• ZRANGEBYSCORE/ZREVRANGEBYSCORE：返回指定 Sorted Set 中指定 score 范圍內的所有 member，返回結果以升序 / 降序排序，min 和 max 可以指定為 - inf 和 + inf，代表返回所有的 member。時間復雜度 O (log (N)+M)
• ZREMRANGEBYRANK/ZREMRANGEBYSCORE：移除 Sorted Set 中指定排名范圍 / 指定 score 范圍內的所有 member。時間復雜度 O (log (N)+M)

上述幾個命令，應盡量避免傳遞 [0 -1] 或 [-inf +inf] 這樣的參數，來對 Sorted Set 做一次性的完整遍歷，特別是在 Sorted Set 的尺寸不可預知的情況下。可以通過 ZSCAN 命令來進行游標式的遍歷（具體請見 https://redis.io/commands/scan ），或通過 LIMIT 參數來限制返回 member 的數量（適用於 ZRANGEBYSCORE 和 ZREVRANGEBYSCORE 命令），以實現游標式的遍歷。

Bitmap 和 HyperLogLog

• Redis 的這兩種數據結構相較之前的並不常用，在本文中只做簡要介紹，如想要詳細了解這兩種數據結構與其相關的命令，請參考官方文檔 https://redis.io/topics/data-types-intro 中的相關章節
• Bitmap 在 Redis 中不是一種實際的數據類型，而是一種將 String 作為 Bitmap 使用的方法。可以理解為將 String 轉換為 bit 數組。使用 Bitmap 來存儲 true/false 類型的簡單數據極為節省空間。
• HyperLogLogs 是一種主要用於數量統計的數據結構，它和 Set 類似，維護一個不可重復的 String 集合，但是 HyperLogLogs 並不維護具體的 member 內容，只維護 member 的個數。也就是說，HyperLogLogs 只能用於計算一個集合中不重復的元素數量，所以它比 Set 要節省很多內存空間。

其他常用命令

• EXISTS：判斷指定的 key 是否存在，返回 1 代表存在，0 代表不存在，時間復雜度 O (1)
• DEL：刪除指定的 key 及其對應的 value，時間復雜度 O (N)，N 為刪除的 key 數量
• EXPIRE/PEXPIRE：為一個 key 設置有效期，單位為秒或毫秒，時間復雜度 O (1)
• TTL/PTTL：返回一個 key 剩余的有效時間，單位為秒或毫秒，時間復雜度 O (1)
• RENAME/RENAMENX：將 key 重命名為 newkey。使用 RENAME 時，如果 newkey 已經存在，其值會被覆蓋；使用 RENAMENX 時，如果 newkey 已經存在，則不會進行任何操作，時間復雜度 O (1)
• TYPE：返回指定 key 的類型，string, list, set, zset, hash。時間復雜度 O (1)
• CONFIG GET：獲得 Redis 某配置項的當前值，可以使用 * 通配符，時間復雜度 O (1)
• CONFIG SET：為 Redis 某個配置項設置新值，時間復雜度 O (1)
• CONFIG REWRITE：讓 Redis 重新加載 redis.conf 中的配置

 

數據持久化

Redis 提供了將數據定期自動持久化至硬盤的能力，包括 RDB 和 AOF 兩種方案，兩種方案分別有其長處和短板，可以配合起來同時運行，確保數據的穩定性。

必須使用數據持久化嗎？

Redis 的數據持久化機制是可以關閉的。如果你只把 Redis 作為緩存服務使用，Redis 中存儲的所有數據都不是該數據的主體而僅僅是同步過來的備份，那么可以關閉 Redis 的數據持久化機制。

但通常來說，仍然建議至少開啟 RDB 方式的數據持久化，因為：

• RDB 方式的持久化幾乎不損耗 Redis 本身的性能，在進行 RDB 持久化時，Redis 主進程唯一需要做的事情就是 fork 出一個子進程，所有持久化工作都由子進程完成
• Redis 無論因為什么原因 crash 掉之后，重啟時能夠自動恢復到上一次 RDB 快照中記錄的數據。這省去了手工從其他數據源（如 DB）同步數據的過程，而且要比其他任何的數據恢復方式都要快
• 現在硬盤那么大，真的不缺那一點地方

RDB
采用RDB持久方式，

• Redis 會定期保存數據快照至一個 rbd 文件中，並在啟動時自動加載 rdb 文件，恢復之前保存的數據。可以在配置文件中配置 Redis 進行快照保存的時機：
• save [seconds] [changes]

• 意為在 [seconds] 秒內如果發生了 [changes] 次數據修改，則進行一次 RDB 快照保存，例如

• save 60 100
• 會讓 Redis 每 60 秒檢查一次數據變更情況，如果發生了 100 次或以上的數據變更，則進行 RDB 快照保存。
• 可以配置多條 save 指令，讓 Redis 執行多級的快照保存策略。
• Redis 默認開啟 RDB 快照，默認的 RDB 策略如下：

  save 900 1 save 300 10 save 60 10000

也可以通過BGSAVE命令手工觸發RDB快照保存。

RDB的優點：

• 對性能影響最小。如前文所述，Redis 在保存 RDB 快照時會 fork 出子進程進行，幾乎不影響 Redis 處理客戶端請求的效率。
• 每次快照會生成一個完整的數據快照文件，所以可以輔以其他手段保存多個時間點的快照（例如把每天 0 點的快照備份至其他存儲媒介中），作為非常可靠的災難恢復手段。
• 使用 RDB 文件進行數據恢復比使用 AOF 要快很多。

RDB的缺點：

• 快照是定期生成的，所以在 Redis crash 時或多或少會丟失一部分數據。
• 如果數據集非常大且 CPU 不夠強（比如單核 CPU），Redis 在 fork 子進程時可能會消耗相對較長的時間（長至 1 秒），影響這期間的客戶端請求。

AOF

• 采用 AOF 持久方式時，Redis 會把每一個寫請求都記錄在一個日志文件里。在 Redis 重啟時，會把 AOF 文件中記錄的所有寫操作順序執行一遍，確保數據恢復到最新。
• AOF 默認是關閉的，如要開啟，進行如下配置：

  appendonly yes

• AOF 提供了三種 fsync 配置，always/everysec/no，

通過配置項[appendfsync]指定

• appendfsync no：不進行 fsync，將 flush 文件的時機交給 OS 決定，速度最快
• appendfsync always：每寫入一條日志就進行一次 fsync 操作，數據安全性最高，但速度最慢

• appendfsync everysec：折中的做法，交由后台線程每秒 fsync 一次

• 隨着 AOF 不斷地記錄寫操作日志，必定會出現一些無用的日志，例如某個時間點執行了命令 SET key1 “abc”，在之后某個時間點又執行了 SET key1 “bcd”，那么第一條命令很顯然是沒有用的。大量的無用日志會讓 AOF 文件過大，也會讓數據恢復的時間過長。
• 所以 Redis 提供了 AOF rewrite 功能，可以重寫 AOF 文件，只保留能夠把數據恢復到最新狀態的最小寫操作集。
• AOF rewrite 可以通過 BGREWRITEAOF 命令觸發，也可以配置 Redis 定期自動進行：

  auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

• 上面兩行配置的含義是，Redis 在每次 AOF rewrite 時，會記錄完成 rewrite 后的 AOF 日志大小，當 AOF 日志大小在該基礎上增長了 100% 后，自動進行 AOF rewrite。同時如果增長的大小沒有達到 64mb，則不會進行 rewrite。

AOF的優點：

• 最安全，在啟用 appendfsync always 時，任何已寫入的數據都不會丟失，使用在啟用 appendfsync everysec 也至多只會丟失 1 秒的數據。
• AOF 文件在發生斷電等問題時也不會損壞，即使出現了某條日志只寫入了一半的情況，也可以使用 redis-check-aof 工具輕松修復。
• AOF 文件易讀，可修改，在進行了某些錯誤的數據清除操作后，只要 AOF 文件沒有 rewrite，就可以把 AOF 文件備份出來，把錯誤的命令刪除，然后恢復數據。

AOF的缺點：

• AOF 文件通常比 RDB 文件更大
• 性能消耗比 RDB 高
• 數據恢復速度比 RDB 慢

 

內存管理與數據淘汰機制

最大內存設置

• 默認情況下，在 32 位 OS 中，Redis 最大使用 3GB 的內存，在 64 位 OS 中則沒有限制。
• 在使用 Redis 時，應該對數據占用的最大空間有一個基本准確的預估，並為 Redis 設定最大使用的內存。否則在 64 位 OS 中 Redis 會無限制地占用內存（當物理內存被占滿后會使用 swap 空間），容易引發各種各樣的問題。

通過如下配置控制 Redis 使用的最大內存：

maxmemory 100mb

在內存占用達到了 maxmemory 后，再向 Redis 寫入數據時，Redis 會：

• 根據配置的數據淘汰策略嘗試淘汰數據，釋放空間
• 如果沒有數據可以淘汰，或者沒有配置數據淘汰策略，那么 Redis 會對所有寫請求返回錯誤，但讀請求仍然可以正常執行

在為 Redis 設置 maxmemory 時，需要注意：

• 如果采用了 Redis 的主從同步，主節點向從節點同步數據時，會占用掉一部分內存空間，如果 maxmemory 過於接近主機的可用內存，導致數據同步時內存不足。所以設置的 maxmemory 不要過於接近主機可用的內存，留出一部分預留用作主從同步。

 

數據淘汰機制

Redis 提供了 5 種數據淘汰策略：

• volatile-lru：使用 LRU 算法進行數據淘汰（淘汰上次使用時間最早的，且使用次數最少的 key），只淘汰設定了有效期的 key
• allkeys-lru：使用 LRU 算法進行數據淘汰，所有的 key 都可以被淘汰
• volatile-random：隨機淘汰數據，只淘汰設定了有效期的 key
• allkeys-random：隨機淘汰數據，所有的 key 都可以被淘汰

• volatile-ttl：淘汰剩余有效期最短的 key

• 最好為 Redis 指定一種有效的數據淘汰策略以配合 maxmemory 設置，避免在內存使用滿后發生寫入失敗的情況。
• 一般來說，推薦使用的策略是 volatile-lru，並辨識 Redis 中保存的數據的重要性。對於那些重要的，絕對不能丟棄的數據（如配置類數據等），應不設置有效期，這樣 Redis 就永遠不會淘汰這些數據。對於那些相對不是那么重要的，並且能夠熱加載的數據（比如緩存最近登錄的用戶信息，當在 Redis 中找不到時，程序會去 DB 中讀取），可以設置上有效期，這樣在內存不夠時 Redis 就會淘汰這部分數據。

配置方法：

maxmemory-policy volatile-lru #默認是noeviction，即不進行數據淘汰

Pipelining

• Redis 提供許多批量操作的命令，如 MSET/MGET/HMSET/HMGET 等等，這些命令存在的意義是減少維護網絡連接和傳輸數據所消耗的資源和時間。
• 例如連續使用 5 次 SET 命令設置 5 個不同的 key，比起使用一次 MSET 命令設置 5 個不同的 key，效果是一樣的，但前者會消耗更多的 RTT (Round Trip Time) 時長，永遠應優先使用后者。
• 然而，如果客戶端要連續執行的多次操作無法通過 Redis 命令組合在一起，例如：

SET a "abc" INCR b HSET c name "hi"

此時便可以使用 Redis 提供的 pipelining 功能來實現在一次交互中執行多條命令。

使用 pipelining 時，只需要從客戶端一次向 Redis 發送多條命令（以 rn）分隔，Redis 就會依次執行這些命令，並且把每個命令的返回按順序組裝在一起一次返回，比如：

$ (printf "PINGrnPINGrnPINGrn"; sleep 1) | nc localhost 6379 +PONG +PONG +PONG

大部分的 Redis 客戶端都對 Pipelining 提供支持，所以開發者通常並不需要自己手工拼裝命令列表。

Pipelining 的局限性

• Pipelining 只能用於執行連續且無相關性的命令，當某個命令的生成需要依賴於前一個命令的返回時，就無法使用 Pipelining 了。
• 通過 Scripting 功能，可以規避這一局限性

 

事務與 Scripting

Pipelining 能夠讓 Redis 在一次交互中處理多條命令，然而在一些場景下，我們可能需要在此基礎上確保這一組命令是連續執行的。

比如獲取當前累計的 PV 數並將其清 0

 >GET vCount 12384 > SET vCount 0 OK

• 如果在 GET 和 SET 命令之間插進來一個 INCR vCount，就會使客戶端拿到的 vCount 不准確。
• Redis 的事務可以確保復數命令執行時的原子性。也就是說 Redis 能夠保證：一個事務中的一組命令是絕對連續執行的，在這些命令執行完成之前，絕對不會有來自於其他連接的其他命令插進去執行。
• 通過 MULTI 和 EXEC 命令來把這兩個命令加入一個事務中：

  MULTI OK GET vCount QUEUED SET vCount 0 QUEUED EXEC 1) 12384 2) OK

• Redis 在接收到 MULTI 命令后便會開啟一個事務，這之后的所有讀寫命令都會保存在隊列中但並不執行，直到接收到 EXEC 命令后，Redis 會把隊列中的所有命令連續順序執行，並以數組形式返回每個命令的返回結果。
• 可以使用 DISCARD 命令放棄當前的事務，將保存的命令隊列清空。
• 需要注意的是，Redis 事務不支持回滾：
• 如果一個事務中的命令出現了語法錯誤，大部分客戶端驅動會返回錯誤，2.6.5 版本以上的 Redis 也會在執行 EXEC 時檢查隊列中的命令是否存在語法錯誤，如果存在，則會自動放棄事務並返回錯誤。
• 但如果一個事務中的命令有非語法類的錯誤（比如對 String 執行 HSET 操作），無論客戶端驅動還是 Redis 都無法在真正執行這條命令之前發現，所以事務中的所有命令仍然會被依次執行。在這種情況下，會出現一個事務中部分命令成功部分命令失敗的情況，然而與 RDBMS 不同，Redis 不提供事務回滾的功能，所以只能通過其他方法進行數據的回滾。

 

通過事務實現 CAS

Redis 提供了 WATCH 命令與事務搭配使用，實現 CAS 樂觀鎖的機制。

假設要實現將某個商品的狀態改為已售：

if(exec(HGET stock:1001 state) == "in stock") exec(HSET stock:1001 state "sold");

這一偽代碼執行時，無法確保並發安全性，有可能多個客戶端都獲取到了”in stock” 的狀態，導致一個庫存被售賣多次。
使用 WATCH 命令和事務可以解決這一問題：

exec(WATCH stock:1001); if(exec(HGET stock:1001 state) == "in stock") { exec(MULTI); exec(HSET stock:1001 state "sold"); exec(EXEC); }

WATCH 的機制是：在事務 EXEC 命令執行時，Redis 會檢查被 WATCH 的 key，只有被 WATCH 的 key 從 WATCH 起始時至今沒有發生過變更，EXEC 才會被執行。如果 WATCH 的 key 在 WATCH 命令到 EXEC 命令之間發生過變化，則 EXEC 命令會返回失敗。

Scripting

• 通過 EVAL 與 EVALSHA 命令，可以讓 Redis 執行 LUA 腳本。這就類似於 RDBMS 的存儲過程一樣，可以把客戶端與 Redis 之間密集的讀 / 寫交互放在服務端進行，避免過多的數據交互，提升性能。
• Scripting 功能是作為事務功能的替代者誕生的，事務提供的所有能力 Scripting 都可以做到。Redis 官方推薦使用 LUA Script 來代替事務，前者的效率和便利性都超過了事務。
• 關於 Scripting 的具體使用，本文不做詳細介紹，請參考官方文檔
  https://redis.io/commands/eval
   
   

  Redis 性能調優

• 盡管 Redis 是一個非常快速的內存數據存儲媒介，也並不代表 Redis 不會產生性能問題。
• 前文中提到過，Redis 采用單線程模型，所有的命令都是由一個線程串行執行的，所以當某個命令執行耗時較長時，會拖慢其后的所有命令，這使得 Redis 對每個任務的執行效率更加敏感。

針對 Redis 的性能優化，主要從下面幾個層面入手：

• 最初的也是最重要的，確保沒有讓 Redis 執行耗時長的命令
• 使用 pipelining 將連續執行的命令組合執行
• 操作系統的 Transparent huge pages 功能必須關閉：

echo never > /sys/kernel/mm/transparent_hugepage/enabled 

• 如果在虛擬機中運行 Redis，可能天然就有虛擬機環境帶來的固有延遲。可以通過./redis-cli –intrinsic-latency 100 命令查看固有延遲。同時如果對 Redis 的性能有較高要求的話，應盡可能在物理機上直接部署 Redis。
• 檢查數據持久化策略
• 考慮引入讀寫分離機制
• 長耗時命令
• Redis 絕大多數讀寫命令的時間復雜度都在 O (1) 到 O (N) 之間，在文本和官方文檔中均對每個命令的時間復雜度有說明。
• 通常來說，O (1) 的命令是安全的，O (N) 命令在使用時需要注意，如果 N 的數量級不可預知，則應避免使用。例如對一個 field 數未知的 Hash 數據執行 HGETALL/HKEYS/HVALS 命令，通常來說這些命令執行的很快，但如果這個 Hash 中的 field 數量極多，耗時就會成倍增長。
• 又如使用 SUNION 對兩個 Set 執行 Union 操作，或使用 SORT 對 List/Set 執行排序操作等時，都應該嚴加注意。

避免在使用這些 O (N) 命令時發生問題主要有幾個辦法：

• 不要把 List 當做列表使用，僅當做隊列來使用
• 通過機制嚴格控制 Hash、Set、Sorted Set 的大小
• 可能的話，將排序、並集、交集等操作放在客戶端執行
• 絕對禁止使用 KEYS 命令
• 避免一次性遍歷集合類型的所有成員，而應使用 SCAN 類的命令進行分批的，游標式的遍歷

Redis 提供了 SCAN 命令，可以對 Redis 中存儲的所有 key 進行游標式的遍歷，避免使用 KEYS 命令帶來的性能問題。同時還有 SSCAN/HSCAN/ZSCAN 等命令，分別用於對 Set/Hash/Sorted Set 中的元素進行游標式遍歷。SCAN 類命令的使用請參考官方文檔：
https://redis.io/commands/scan

Redis 提供了 Slow Log 功能，可以自動記錄耗時較長的命令。相關的配置參數有兩個：

slowlog-log-slower-than xxxms #執行時間慢於xxx毫秒的命令計入Slow Log slowlog-max-len xxx #Slow Log的長度，即最大紀錄多少條Slow Log

• 使用 SLOWLOG GET [number] 命令，可以輸出最近進入 Slow Log 的 number 條命令。
• 使用 SLOWLOG RESET 命令，可以重置 Slow Log

網絡引發的延遲

• 盡可能使用長連接或連接池，避免頻繁創建銷毀連接
• 客戶端進行的批量數據操作，應使用 Pipeline 特性在一次交互中完成。具體請參照本文的 Pipelining 章節
• 數據持久化引發的延遲

Redis 的數據持久化工作本身就會帶來延遲，需要根據數據的安全級別和性能要求制定合理的持久化策略：

• AOF + fsync always 的設置雖然能夠絕對確保數據安全，但每個操作都會觸發一次 fsync，會對 Redis 的性能有比較明顯的影響
• AOF + fsync every second 是比較好的折中方案，每秒 fsync 一次
• AOF + fsync never 會提供 AOF 持久化方案下的最優性能
• 使用 RDB 持久化通常會提供比使用 AOF 更高的性能，但需要注意 RDB 的策略配置
• 每一次 RDB 快照和 AOF Rewrite 都需要 Redis 主進程進行 fork 操作。fork 操作本身可能會產生較高的耗時，與 CPU 和 Redis 占用的內存大小有關。根據具體的情況合理配置 RDB 快照和 AOF Rewrite 時機，避免過於頻繁的 fork 帶來的延遲

Redis 在 fork 子進程時需要將內存分頁表拷貝至子進程，以占用了 24GB 內存的 Redis 實例為例，共需要拷貝 24GB / 4kB * 8 = 48MB 的數據。在使用單 Xeon 2.27Ghz 的物理機上，這一 fork 操作耗時 216ms。

可以通過 INFO 命令返回的 latest_fork_usec 字段查看上一次 fork 操作的耗時（微秒）

Swap 引發的延遲

• 當 Linux 將 Redis 所用的內存分頁移至 swap 空間時，將會阻塞 Redis 進程，導致 Redis 出現不正常的延遲。Swap 通常在物理內存不足或一些進程在進行大量 I/O 操作時發生，應盡可能避免上述兩種情況的出現。
• /proc//smaps 文件中會保存進程的 swap 記錄，通過查看這個文件，能夠判斷 Redis 的延遲是否由 Swap 產生。如果這個文件中記錄了較大的 Swap size，則說明延遲很有可能是 Swap 造成的。

數據淘汰引發的延遲

當同一秒內有大量 key 過期時，也會引發 Redis 的延遲。在使用時應盡量將 key 的失效時間錯開。

引入讀寫分離機制

• Redis 的主從復制能力可以實現一主多從的多節點架構，在這一架構下，主節點接收所有寫請求，並將數據同步給多個從節點。
• 在這一基礎上，我們可以讓從節點提供對實時性要求不高的讀請求服務，以減小主節點的壓力。
• 尤其是針對一些使用了長耗時命令的統計類任務，完全可以指定在一個或多個從節點上執行，避免這些長耗時命令影響其他請求的響應。

 

主從復制與集群分片

主從復制

Redis 支持一主多從的主從復制架構。一個 Master 實例負責處理所有的寫請求，Master 將寫操作同步至所有 Slave。

借助 Redis 的主從復制，可以實現讀寫分離和高可用：

實時性要求不是特別高的讀請求，可以在 Slave 上完成，提升效率。特別是一些周期性執行的統計任務，這些任務可能需要執行一些長耗時的 Redis 命令，可以專門規划出 1 個或幾個 Slave 用於服務這些統計任務
借助 Redis Sentinel 可以實現高可用，當 Master crash 后，Redis Sentinel 能夠自動將一個 Slave 晉升為 Master，繼續提供服務

啟用主從復制非常簡單，只需要配置多個 Redis 實例，在作為 Slave 的 Redis 實例中配置：

slaveof 192.168.1.1 6379 #指定Master的IP和端口

當 Slave 啟動后，會從 Master 進行一次冷啟動數據同步，由 Master 觸發 BGSAVE 生成 RDB 文件推送給 Slave 進行導入，導入完成后 Master 再將增量數據通過 Redis Protocol 同步給 Slave。之后主從之間的數據便一直以 Redis Protocol 進行同步

使用 Sentinel 做自動 failover

Redis 的主從復制功能本身只是做數據同步，並不提供監控和自動 failover 能力，要通過主從復制功能來實現 Redis 的高可用，還需要引入一個組件：Redis Sentinel

Redis Sentinel 是 Redis 官方開發的監控組件，可以監控 Redis 實例的狀態，通過 Master 節點自動發現 Slave 節點，並在監測到 Master 節點失效時選舉出一個新的 Master，並向所有 Redis 實例推送新的主從配置。

Redis Sentinel 需要至少部署 3 個實例才能形成選舉關系。

關鍵配置：

另外需要注意的是，Redis Sentinel 實現的自動 failover 不是在同一個 IP 和端口上完成的，也就是說自動 failover 產生的新 Master 提供服務的 IP 和端口與之前的 Master 是不一樣的，所以要實現 HA，還要求客戶端必須支持 Sentinel，能夠與 Sentinel 交互獲得新 Master 的信息才行。

集群分片

為何要做集群分片：

Redis中存儲的數據量大，一台主機的物理內存已經無法容納
Redis的寫請求並發量大，一個Redis實例以無法承載

當上述兩個問題出現時，就必須要對 Redis 進行分片了。

Redis的分片方案有很多種，例如很多Redis的客戶端都自行實現了分片功能，也有向Twemproxy這樣的以代理方式實現的Redis分片方案。然而首選的方案還應該是Redis官方在3.0版本中推出的Redis Cluster分片方案。

Redis Cluster 的能力

能夠自動將數據分散在多個節點上
當訪問的 key 不在當前分片上時，能夠自動將請求轉發至正確的分片
當集群中部分節點失效時仍能提供服務

其中第三點是基於主從復制來實現的，Redis Cluster 的每個數據分片都采用了主從復制的結構，原理和前文所述的主從復制完全一致，唯一的區別是省去了 Redis Sentinel 這一額外的組件，由 Redis Cluster 負責進行一個分片內部的節點監控和自動 failover。

Redis Cluster 分片原理

• Redis Cluster 中共有 16384 個 hash slot，Redis 會計算每個 key 的 CRC16，將結果與 16384 取模，來決定該 key 存儲在哪一個 hash slot 中，同時需要指定 Redis Cluster 中每個數據分片負責的 Slot 數。Slot 的分配在任何時間點都可以進行重新分配。
• 客戶端在對 key 進行讀寫操作時，可以連接 Cluster 中的任意一個分片，如果操作的 key 不在此分片負責的 Slot 范圍內，Redis Cluster 會自動將請求重定向到正確的分片上。

hash tags

• 在基礎的分片原則上，Redis 還支持 hash tags 功能，以 hash tags 要求的格式明明的 key，將會確保進入同一個 Slot 中。例如：{uiv} user:1000 和 {uiv} user:1001 擁有同樣的 hash tag {uiv}，會保存在同一個 Slot 中。
• 使用 Redis Cluster 時，pipelining、事務和 LUA Script 功能涉及的 key 必須在同一個數據分片上，否則將會返回錯誤。如要在 Redis Cluster 中使用上述功能，就必須通過 hash tags 來確保一個 pipeline 或一個事務中操作的所有 key 都位於同一個 Slot 中。
• 有一些客戶端（如 Redisson）實現了集群化的 pipelining 操作，可以自動將一個 pipeline 里的命令按 key 所在的分片進行分組，分別發到不同的分片上執行。但是 Redis 不支持跨分片的事務，事務和 LUA Script 還是必須遵循所有 key 在一個分片上的規則要求。
• 主從復制 vs 集群分片
• 在設計軟件架構時，要如何在主從復制和集群分片兩種部署方案中取舍呢？
• 從各個方面看，Redis Cluster 都是優於主從復制的方案

Redis Cluster能夠解決單節點上數據量過大的問題
Redis Cluster能夠解決單節點訪問壓力過大的問題
Redis Cluster包含了主從復制的能力

那是不是代表 Redis Cluster 永遠是優於主從復制的選擇呢？

並不是。

軟件架構永遠不是越復雜越好，復雜的架構在帶來顯著好處的同時，一定也會帶來相應的弊端。采用 Redis Cluster 的弊端包括：

• 維護難度增加。在使用 Redis Cluster 時，需要維護的 Redis 實例數倍增，需要監控的主機數量也相應增加，數據備份 / 持久化的復雜度也會增加。同時在進行分片的增減操作時，還需要進行 reshard 操作，遠比主從模式下增加一個 Slave 的復雜度要高。
• 客戶端資源消耗增加。當客戶端使用連接池時，需要為每一個數據分片維護一個連接池，客戶端同時需要保持的連接數成倍增多，加大了客戶端本身和操作系統資源的消耗。
• 性能優化難度增加。你可能需要在多個分片上查看 Slow Log 和 Swap 日志才能定位性能問題。

• 事務和 LUA Script 的使用成本增加。在 Redis Cluster 中使用事務和 LUA Script 特性有嚴格的限制條件，事務和 Script 中操作的 key 必須位於同一個分片上，這就使得在開發時必須對相應場景下涉及的 key 進行額外的規划和規范要求。如果應用的場景中大量涉及事務和 Script 的使用，如何在保證這兩個功能的正常運作前提下把數據平均分到多個數據分片中就會成為難點。

• 所以說，在主從復制和集群分片兩個方案中做出選擇時，應該從應用軟件的功能特性、數據和訪問量級、未來發展規划等方面綜合考慮，只在確實有必要引入數據分片時再使用 Redis Cluster。
• 綜合上面幾點考慮，如果單台主機的可用物理內存完全足以支撐對 Redis 的容量需求，且 Redis 面臨的並發寫壓力距離 Benchmark 值還尚有距離，建議采用主從復制的架構，可以省去很多不必要的麻煩。同時，如果應用中大量使用 pipelining 和事務，也建議盡可能選擇主從復制架構，可以減少設計和開發時的復雜度。

動動小手點點關注吧！

Java架構師學習公眾號！

一個專注分享架構干貨的微信公眾號

覺得本文有用就把文章分享給更多的人看到吧！