Redis基礎、高階特性與效能調優

發表於2018-10-16
Redis

本文將從Redis的基本特性入手，通過講述Redis的資料結構和主要命令對Redis的基本能力進行直觀介紹。之後概覽Redis提供的高階能力，並在部署、維護、效能調優等多個方面進行更深入的介紹和指導。
本文適合使用Redis的普通開發人員，以及對Redis進行選型、架構設計和效能調優的架構設計人員。

目錄

  • 概述
  • Redis的資料結構和相關常用命令
  • 資料持久化
  • 記憶體管理與資料淘汰機制
  • Pipelining
  • 事務與Scripting
  • Redis效能調優
  • 主從複製與叢集分片
  • Redis Java客戶端的選擇

概述

Redis是一個開源的，基於記憶體的結構化資料儲存媒介，可以作為資料庫、快取服務或訊息服務使用。
Redis支援多種資料結構，包括字串、雜湊表、連結串列、集合、有序集合、點陣圖、Hyperloglogs等。
Redis具備LRU淘汰、事務實現、以及不同級別的硬碟持久化等能力，並且支援副本集和通過Redis Sentinel實現的高可用方案，同時還支援通過Redis Cluster實現的資料自動分片能力。

Redis的主要功能都基於單執行緒模型實現，也就是說Redis使用一個執行緒來服務所有的客戶端請求，同時Redis採用了非阻塞式IO，並精細地優化各種命令的演算法時間複雜度，這些資訊意味著：

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

Redis的資料結構和相關常用命令

本節中將介紹Redis支援的主要資料結構，以及相關的常用Redis命令。本節只對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：庫存控制

在高併發場景下實現庫存餘量的精準校驗，確保不出現超賣的情況。

設定庫存總量：

庫存扣減+餘量校驗：

當DECR命令返回值大於等於0時，說明庫存餘量校驗通過，如果返回小於0的值，則說明庫存已耗盡。

假設同時有300個併發請求進行庫存扣減，Redis能夠確保這300個請求分別得到99到-200的返回值，每個請求得到的返回值都是唯一的，絕對不會找出現兩個請求得到一樣的返回值的情況。

例2：自增序列生成

實現類似於RDBMS的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進行快照儲存的時機：

意為在[seconds]秒內如果發生了[changes]次資料修改，則進行一次RDB快照儲存，例如

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

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

RDB的優點：

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

RDB的缺點：

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

AOF

採用AOF持久方式時，Redis會把每一個寫請求都記錄在一個日誌檔案裡。在Redis重啟時，會把AOF檔案中記錄的所有寫操作順序執行一遍，確保資料恢復到最新。

AOF預設是關閉的，如要開啟，進行如下配置：

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定期自動進行：

上面兩行配置的含義是，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後，再向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就會淘汰這部分資料。

配置方法：

Pipelining

Pipelining

Redis提供許多批量操作的命令，如MSET/MGET/HMSET/HMGET等等，這些命令存在的意義是減少維護網路連線和傳輸資料所消耗的資源和時間。
例如連續使用5次SET命令設定5個不同的key，比起使用一次MSET命令設定5個不同的key，效果是一樣的，但前者會消耗更多的RTT(Round Trip Time)時長，永遠應優先使用後者。

然而，如果客戶端要連續執行的多次操作無法通過Redis命令組合在一起，例如：

此時便可以使用Redis提供的pipelining功能來實現在一次互動中執行多條命令。
使用pipelining時，只需要從客戶端一次向Redis傳送多條命令（以rn）分隔，Redis就會依次執行這些命令，並且把每個命令的返回按順序組裝在一起一次返回，比如：

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

Pipelining的侷限性

Pipelining只能用於執行連續且無相關性的命令，當某個命令的生成需要依賴於前一個命令的返回時，就無法使用Pipelining了。

通過Scripting功能，可以規避這一侷限性

事務與Scripting

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

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

如果在GET和SET命令之間插進來一個INCR vCount，就會使客戶端拿到的vCount不準確。

Redis的事務可以確保複數命令執行時的原子性。也就是說Redis能夠保證：一個事務中的一組命令是絕對連續執行的，在這些命令執行完成之前，絕對不會有來自於其他連線的其他命令插進去執行。

通過MULTI和EXEC命令來把這兩個命令加入一個事務中：

Redis在接收到MULTI命令後便會開啟一個事務，這之後的所有讀寫命令都會儲存在佇列中但並不執行，直到接收到EXEC命令後，Redis會把佇列中的所有命令連續順序執行，並以陣列形式返回每個命令的返回結果。

可以使用DISCARD命令放棄當前的事務，將儲存的命令佇列清空。

需要注意的是，Redis事務不支援回滾：
如果一個事務中的命令出現了語法錯誤，大部分客戶端驅動會返回錯誤，2.6.5版本以上的Redis也會在執行EXEC時檢查佇列中的命令是否存在語法錯誤，如果存在，則會自動放棄事務並返回錯誤。
但如果一個事務中的命令有非語法類的錯誤（比如對String執行HSET操作），無論客戶端驅動還是Redis都無法在真正執行這條命令之前發現，所以事務中的所有命令仍然會被依次執行。在這種情況下，會出現一個事務中部分命令成功部分命令失敗的情況，然而與RDBMS不同，Redis不提供事務回滾的功能，所以只能通過其他方法進行資料的回滾。

通過事務實現CAS

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

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

這一虛擬碼執行時，無法確保併發安全性，有可能多個客戶端都獲取到了”in stock”的狀態，導致一個庫存被售賣多次。

使用WATCH命令和事務可以解決這一問題：

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功能必須關閉：

  • 如果在虛擬機器中執行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 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/<pid>/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例項中配置：

當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的具體安裝和部署細節進行介紹，重點介紹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。
下面是一些建議：

  1. 需要在Redis中儲存的資料有多大？未來2年內可能發展為多大？這些資料是否都需要長期儲存？是否可以使用LRU演算法進行非熱點資料的淘汰？綜合考慮前面幾個因素，評估出Redis需要使用的實體記憶體。
  2. 用於部署Redis的主機實體記憶體有多大？有多少可以分配給Redis使用？對比(1)中的記憶體需求評估，是否足夠用？
  3. Redis面臨的併發寫壓力會有多大？在不使用pipelining時，Redis的寫效能可以超過10萬次/秒（更多的benchmark可以參考 https://redis.io/topics/benchmarks ）
  4. 在使用Redis時，是否會使用到pipelining和事務功能？使用的場景多不多？

綜合上面幾點考慮，如果單臺主機的可用實體記憶體完全足以支撐對Redis的容量需求，且Redis面臨的併發寫壓力距離Benchmark值還尚有距離，建議採用主從複製的架構，可以省去很多不必要的麻煩。同時，如果應用中大量使用pipelining和事務，也建議儘可能選擇主從複製架構，可以減少設計和開發時的複雜度。

Redis Java客戶端的選擇

Redis的Java客戶端很多，官方推薦的有三種：Jedis、Redisson和lettuce。

在這裡對Jedis和Redisson進行對比介紹

Jedis：

  • 輕量，簡潔，便於整合和改造
  • 支援連線池
  • 支援pipelining、事務、LUA Scripting、Redis Sentinel、Redis Cluster
  • 不支援讀寫分離，需要自己實現
  • 文件差（真的很差，幾乎沒有……）

Redisson：

  • 基於Netty實現，採用非阻塞IO，效能高
  • 支援非同步請求
  • 支援連線池
  • 支援pipelining、LUA Scripting、Redis Sentinel、Redis Cluster
  • 不支援事務，官方建議以LUA Scripting代替事務
  • 支援在Redis Cluster架構下使用pipelining
  • 支援讀寫分離，支援讀負載均衡，在主從複製和Redis Cluster架構下都可以使用
  • 內建Tomcat Session Manager，為Tomcat 6/7/8提供了會話共享功能
  • 可以與Spring Session整合，實現基於Redis的會話共享
  • 文件較豐富，有中文文件

對於Jedis和Redisson的選擇，同樣應遵循前述的原理，儘管Jedis比起Redisson有各種各樣的不足，但也應該在需要使用Redisson的高階特性時再選用Redisson，避免造成不必要的程式複雜度提升。

Jedis：
github：https://github.com/xetorthio/jedis
文件：https://github.com/xetorthio/jedis/wiki

Redisson：
github：https://github.com/redisson/redisson
文件：https://github.com/redisson/redisson/wiki

相關文章