知識星球
本文將從Redis的基本特性入手，透過講述Redis的資料結構和主要命令對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 支援的主要資料結構，以及相關的常用 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：庫存控制
在高併發場景下實現庫存餘量的精準校驗，確保不出現超賣的情況。
設定庫存總量：
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 效能調優
儘管 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 Logslowlog-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 個實體才能形成選舉關係。
關鍵配置：
sentinel monitor mymaster 127.0.0.1 6379 2 #Master實體的IP、埠，以及選舉需要的贊成票數sentinel down-after-milliseconds mymaster 60000 #多長時間沒有響應視為Master失效sentinel failover-timeout mymaster 180000 #兩次failover嘗試間的間隔時長sentinel parallel-syncs mymaster 1 #如果有多個Slave，可以透過此配置指定同時從新Master進行資料同步的Slave數，避免所有Slave同時進行資料同步導致查詢服務也不可用
另外需要註意的是，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。
下麵是一些建議：
需要在 Redis 中儲存的資料有多大？未來 2 年內可能發展為多大？這些資料是否都需要長期儲存？是否可以使用 LRU 演演算法進行非熱點資料的淘汰？綜合考慮前面幾個因素，評估出 Redis 需要使用的物理記憶體。
用於部署 Redis 的主機物理記憶體有多大？有多少可以分配給 Redis 使用？對比 (1) 中的記憶體需求評估，是否足夠用？
Redis 面臨的併發寫壓力會有多大？在不使用 pipelining 時，Redis 的寫效能可以超過 10 萬次 / 秒（更多的 benchmark 可以參考 https://redis.io/topics/benchmarks ）
在使用 Redis 時，是否會使用到 pipelining 和事務功能？使用的場景多不多？
綜合上面幾點考慮，如果單臺主機的可用物理記憶體完全足以支撐對 Redis 的容量需求，且 Redis 面臨的併發寫壓力距離 Benchmark 值還尚有距離，建議採用主從複製的架構，可以省去很多不必要的麻煩。同時，如果應用中大量使用 pipelining 和事務，也建議盡可能選擇主從複製架構，可以減少設計和開發時的複雜度。
————近期開班————
《馬哥Linux雲端計算及架構師》課程，由知名Linux佈道師馬哥創立，經歷了8年的發展，聯合阿裡巴巴、唯品會、大眾點評、騰訊、陸金所等大型網際網路一線公司的馬哥課程團隊的工程師進行深度定製開發，課程採用 Centos7.2系統教學，加入了大量實戰案例，授課案例均來自於一線的技術案例，自動化運維、Devops、雲服務、python等技能一站式搞定，掌握2018年linux雲端計算高薪未來。
29期網路班:2018年02月10日（網路）
30期面授班:2018年03月26日（北京）
掃描二維碼領取學習資料
更多Linux好文請點選【閱讀原文】哦
↓↓↓
