辰东,玄幻小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案

一文搞定Redis高級(jí)特性與性能調(diào)優(yōu)

本文從 Redis 基本特性入手，通過(guò)講述 Redis 的數(shù)據(jù)結(jié)構(gòu)和主要命令對(duì) Redis 的基本能力進(jìn)行直觀介紹。之后概覽 Redis 提供的高級(jí)能力，并在部署、維護(hù)、性能調(diào)優(yōu)等多個(gè)方面深入介紹和指導(dǎo)。

十余年建站經(jīng)驗(yàn)，網(wǎng)站設(shè)計(jì)制作、網(wǎng)站建設(shè)客戶的見(jiàn)證與正確選擇。創(chuàng)新互聯(lián)提供完善的營(yíng)銷(xiāo)型網(wǎng)頁(yè)建站明細(xì)報(bào)價(jià)表。后期開(kāi)發(fā)更加便捷高效，我們致力于追求更美、更快、更規(guī)范。

本文適合使用 Redis 的普通開(kāi)發(fā)人員，以及對(duì) Redis 進(jìn)行選型、架構(gòu)設(shè)計(jì)和性能調(diào)優(yōu)的架構(gòu)設(shè)計(jì)人員：

Redis 的數(shù)據(jù)結(jié)構(gòu)和相關(guān)常用命令
數(shù)據(jù)持久化
內(nèi)存管理與數(shù)據(jù)淘汰機(jī)制
Pipelining
事務(wù)與 Scripting
Redis 性能調(diào)優(yōu)
主從復(fù)制與集群分片
Redis Java 客戶端的選擇

Redis 是一個(gè)開(kāi)源的，基于內(nèi)存的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)媒介，可以作為數(shù)據(jù)庫(kù)、緩存服務(wù)或消息服務(wù)使用。

Redis 支持多種數(shù)據(jù)結(jié)構(gòu)，包括字符串、哈希表、鏈表、集合、有序集合、位圖、Hyperloglogs 等。

Redis 具備 LRU 淘汰、事務(wù)實(shí)現(xiàn)、以及不同級(jí)別的硬盤(pán)持久化等能力，并且支持副本集和通過(guò) Redis Sentinel 實(shí)現(xiàn)的高可用方案，同時(shí)還支持通過(guò) Redis Cluster 實(shí)現(xiàn)的數(shù)據(jù)自動(dòng)分片能力。

Redis 的主要功能都基于單線程模型實(shí)現(xiàn)，也就是說(shuō) Redis 使用一個(gè)線程來(lái)服務(wù)所有的客戶端請(qǐng)求，同時(shí) Redis 采用了非阻塞式 IO，并精細(xì)地優(yōu)化各種命令的算法時(shí)間復(fù)雜度。

這些信息意味著：

Redis 是線程安全的(因?yàn)橹挥幸粋€(gè)線程)，其所有操作都是原子的，不會(huì)因并發(fā)產(chǎn)生數(shù)據(jù)異常。
Redis 的速度非常快(因?yàn)槭褂梅亲枞?IO，且大部分命令的算法時(shí)間復(fù)雜度都是 O(1))。
使用高耗時(shí)的 Redis 命令是很危險(xiǎn)的，會(huì)占用唯一的一個(gè)線程的大量處理時(shí)間，導(dǎo)致所有的請(qǐng)求都被拖慢(例如時(shí)間復(fù)雜度為 O(N)的 Keys 命令，嚴(yán)格禁止在生產(chǎn)環(huán)境中使用)。

Redis 的數(shù)據(jù)結(jié)構(gòu)和相關(guān)常用命令

本節(jié)中將介紹 Redis 支持的主要數(shù)據(jù)結(jié)構(gòu)，以及相關(guān)的常用 Redis 命令。本節(jié)只對(duì) Redis 命令進(jìn)行扼要的介紹，且只列出了較常用的命令。

如果想要了解完整的 Redis 命令集，或了解某個(gè)命令的詳細(xì)使用方法，請(qǐng)參考官方文檔：

 
 
 
 
  
  
  
  https://redis.io/commands

Key

Redis 采用 Key-Value 型的基本數(shù)據(jù)結(jié)構(gòu)，任何二進(jìn)制序列都可以作為 Redis 的 Key 使用(例如普通的字符串或一張 JPEG 圖片)。

關(guān)于 Key 的一些注意事項(xiàng)：

不要使用過(guò)長(zhǎng)的 Key。例如使用一個(gè) 1024 字節(jié)的 Key 就不是一個(gè)好主意，不僅會(huì)消耗更多的內(nèi)存，還會(huì)導(dǎo)致查找的效率降低。
Key 短到缺失了可讀性也是不好的，例如”u1000flw”比起”user:1000:followers”來(lái)說(shuō)，節(jié)省了寥寥的存儲(chǔ)空間，卻引發(fā)了可讀性和可維護(hù)性上的麻煩。
最好使用統(tǒng)一的規(guī)范來(lái)設(shè)計(jì) Key，比如”object-type:id:attr”，以這一規(guī)范設(shè)計(jì)出的 Key 可能是”user:1000″或”comment:1234:reply-to”。
Redis 允許的最大 Key 長(zhǎng)度是 512MB(對(duì) Value 的長(zhǎng)度限制也是 512MB)。

String

String 是 Redis 的基礎(chǔ)數(shù)據(jù)類型，Redis 沒(méi)有 Int、Float、Boolean 等數(shù)據(jù)類型的概念，所有的基本類型在 Redis 中都以 String 體現(xiàn)。

與 String 相關(guān)的常用命令：

SET：為一個(gè) Key 設(shè)置 Value，可以配合 EX/PX 參數(shù)指定 Key 的有效期，通過(guò) NX/XX 參數(shù)針對(duì) Key 是否存在的情況進(jìn)行區(qū)別操作，時(shí)間復(fù)雜度 O(1)。
GET：獲取某個(gè) Key 對(duì)應(yīng)的 Value，時(shí)間復(fù)雜度 O(1)。
GETSET：為一個(gè) Key 設(shè)置 Value，并返回該 Key 的原 Value，時(shí)間復(fù)雜度 O(1)。
MSET：為多個(gè) Key 設(shè)置 Value，時(shí)間復(fù)雜度 O(N)。
MSETNX：同 MSET，如果指定的 Key 中有任意一個(gè)已存在，則不進(jìn)行任何操作，時(shí)間復(fù)雜度O(N)。
MGET：獲取多個(gè) Key 對(duì)應(yīng)的 Value，時(shí)間復(fù)雜度O(N)。

上文提到過(guò)，Redis 的基本數(shù)據(jù)類型只有 String，但 Redis 可以把 String 作為整型或浮點(diǎn)型數(shù)字來(lái)使用，主要體現(xiàn)在 INCR、DECR 類的命令上：

INCR：將 Key 對(duì)應(yīng)的 Value 值自增 1，并返回自增后的值。只對(duì)可以轉(zhuǎn)換為整型的 String 數(shù)據(jù)起作用。時(shí)間復(fù)雜度 O(1)。
INCRBY：將 Key 對(duì)應(yīng)的 Value 值自增指定的整型數(shù)值，并返回自增后的值。只對(duì)可以轉(zhuǎn)換為整型的 String 數(shù)據(jù)起作用。時(shí)間復(fù)雜度 O(1)。
DECR/DECRBY：同 INCR/INCRBY，自增改為自減。

INCR/DECR 系列命令要求操作的 Value 類型為 String，并可以轉(zhuǎn)換為 64 位帶符號(hào)的整型數(shù)字，否則會(huì)返回錯(cuò)誤。

也就是說(shuō)，進(jìn)行 INCR/DECR 系列命令的 Value，必須在 [-2^63 ~ 2^63 – 1] 范圍內(nèi)。

前文提到過(guò)，Redis 采用單線程模型，天然是線程安全的，這使得 INCR/DECR 命令可以非常便利的實(shí)現(xiàn)高并發(fā)場(chǎng)景下的精確控制。

例 1：庫(kù)存控制

在高并發(fā)場(chǎng)景下實(shí)現(xiàn)庫(kù)存余量的精準(zhǔn)校驗(yàn)，確保不出現(xiàn)超賣(mài)的情況。設(shè)置庫(kù)存總量：

 
 
 
 
  
  
  
  SET inv:remain "100"

庫(kù)存扣減+余量校驗(yàn)：

 
 
 
 
  
  
  
  DECR inv:remain

當(dāng) DECR 命令返回值大于等于 0 時(shí)，說(shuō)明庫(kù)存余量校驗(yàn)通過(guò)，如果返回小于 0 的值，則說(shuō)明庫(kù)存已耗盡。

假設(shè)同時(shí)有 300 個(gè)并發(fā)請(qǐng)求進(jìn)行庫(kù)存扣減，Redis 能夠確保這 300 個(gè)請(qǐng)求分別得到 99 到 -200 的返回值，每個(gè)請(qǐng)求得到的返回值都是唯一的，絕對(duì)不會(huì)出現(xiàn)兩個(gè)請(qǐng)求得到一樣的返回值的情況。

例 2：自增序列生成

實(shí)現(xiàn)類似于 RDBMS 的 Sequence 功能，生成一系列唯一的序列號(hào)。設(shè)置序列起始值：

 
 
 
 
  
  
  
  SET sequence "10000"

獲取一個(gè)序列值：

 
 
 
 
  
  
  
  INCR sequence

直接將返回值作為序列使用即可。獲取一批(如100個(gè))序列值：

 
 
 
 
  
  
  
  INCRBY sequence 100

假設(shè)返回值為 N，那么 [N – 99 ~ N] 的數(shù)值都是可用的序列值。

當(dāng)多個(gè)客戶端同時(shí)向 Redis 申請(qǐng)自增序列時(shí)，Redis 能夠確保每個(gè)客戶端得到的序列值或序列范圍都是全局唯一的，絕對(duì)不會(huì)出現(xiàn)不同客戶端得到了重復(fù)的序列值的情況。

List

Redis 的 List 是鏈表型的數(shù)據(jù)結(jié)構(gòu)，可以使用 LPUSH/RPUSH/LPOP/RPOP 等命令在 List 的兩端執(zhí)行插入元素和彈出元素的操作。

雖然 List 也支持在特定 Index 上插入和讀取元素的功能，但其時(shí)間復(fù)雜度較高(O(N))，應(yīng)小心使用。

與 List 相關(guān)的常用命令：

LPUSH：向指定 List 的左側(cè)(即頭部)插入 1 個(gè)或多個(gè)元素，返回插入后的 List 長(zhǎng)度。時(shí)間復(fù)雜度O(N)，N 為插入元素的數(shù)量。
RPUSH：同 LPUSH，向指定 List 的右側(cè)(即尾部)插入 1 或多個(gè)元素。
LPOP：從指定 List 的左側(cè)(即頭部)移除一個(gè)元素并返回，時(shí)間復(fù)雜度 O(1)。
RPOP：同 LPOP，從指定 List 的右側(cè)(即尾部)移除 1 個(gè)元素并返回。
LPUSHX/RPUSHX：與 LPUSH/RPUSH 類似，區(qū)別在于 LPUSHX/RPUSHX 操作的 Key 如果不存在，則不會(huì)進(jìn)行任何操作。
LLEN：返回指定 List 的長(zhǎng)度，時(shí)間復(fù)雜度 O(1)。
LRANGE：返回指定 List 中指定范圍的元素(雙端包含，即 LRANGE key 0 10 會(huì)返回 11 個(gè)元素)，時(shí)間復(fù)雜度 O(N)。

應(yīng)盡可能控制一次獲取的元素?cái)?shù)量，一次獲取過(guò)大范圍的 List 元素會(huì)導(dǎo)致延遲，同時(shí)對(duì)長(zhǎng)度不可預(yù)知的 List，避免使用 LRANGE key 0 -1 這樣的完整遍歷操作。

應(yīng)謹(jǐn)慎使用的 List 相關(guān)命令：

LINDEX：返回指定 List 指定 Index 上的元素，如果 Index 越界，返回 nil。Index 數(shù)值是回環(huán)的，即 -1 代表 List 最后一個(gè)位置，-2 代表 List 倒數(shù)第二個(gè)位置。時(shí)間復(fù)雜度 O(N)。
LSET：將指定 List 指定 Index 上的元素設(shè)置為 Value，如果 Index 越界則返回錯(cuò)誤，時(shí)間復(fù)雜度 O(N)，如果操作的是頭/尾部的元素，則時(shí)間復(fù)雜度為 O(1)。
LINSERT：向指定 List 中指定元素之前/之后插入一個(gè)新元素，并返回操作后的 List 長(zhǎng)度。

如果指定的元素不存在，返回 -1。如果指定 Key 不存在，不會(huì)進(jìn)行任何操作，時(shí)間復(fù)雜度 O(N)。

由于 Redis 的 List 是鏈表結(jié)構(gòu)的，上述的三個(gè)命令的算法效率較低，需要對(duì) List 進(jìn)行遍歷，命令的耗時(shí)無(wú)法預(yù)估，在 List 長(zhǎng)度大的情況下耗時(shí)會(huì)明顯增加，應(yīng)謹(jǐn)慎使用。

換句話說(shuō)，Redis 的 List 實(shí)際是設(shè)計(jì)來(lái)用于實(shí)現(xiàn)隊(duì)列，而不是用于實(shí)現(xiàn)類似 ArrayList 這樣的列表的。

如果你不是想要實(shí)現(xiàn)一個(gè)雙端出入的隊(duì)列，那么請(qǐng)盡量不要使用 Redis 的 List 數(shù)據(jù)結(jié)構(gòu)。

為了更好支持隊(duì)列的特性，Redis 還提供了一系列阻塞式的操作命令，如 BLPOP/BRPOP 等，能夠?qū)崿F(xiàn)類似于 BlockingQueue 的能力，即在 List 為空時(shí)，阻塞該連接，直到 List 中有對(duì)象可以出隊(duì)時(shí)再返回。

針對(duì)阻塞類的命令，此處不做詳細(xì)探討，請(qǐng)參考官方文檔中”Blocking operations on lists”一節(jié)：

 
 
 
 
  
  
  
  https://redis.io/topics/data-types-intro

Hash

Hash 即哈希表，Redis 的 Hash 和傳統(tǒng)的哈希表一樣，是一種 field-value 型的數(shù)據(jù)結(jié)構(gòu)，可以理解成將 HashMap 搬入 Redis。

Hash 非常適合用于表現(xiàn)對(duì)象類型的數(shù)據(jù)，用 Hash 中的 field 對(duì)應(yīng)對(duì)象的 field 即可。

Hash 的優(yōu)點(diǎn)包括：

可以實(shí)現(xiàn)二元查找，如”查找 ID 為 1000 的用戶的年齡”。
比起將整個(gè)對(duì)象序列化后作為 String 存儲(chǔ)的方法，Hash 能夠有效地減少網(wǎng)絡(luò)傳輸?shù)南摹?/li>
當(dāng)使用 Hash 維護(hù)一個(gè)集合時(shí)，提供了比 List 效率高得多的隨機(jī)訪問(wèn)命令。
與 Hash 相關(guān)的常用命令：
HSET：將 Key 對(duì)應(yīng)的 Hash 中的 field 設(shè)置為 Value。如果該 Hash 不存在，會(huì)自動(dòng)創(chuàng)建一個(gè)。時(shí)間復(fù)雜度 O(1)。
HGET：返回指定 Hash 中 field 字段的值，時(shí)間復(fù)雜度 O(1)。
HMSET/HMGET：同 HSET 和 HGET，可以批量操作同一個(gè) Key 下的多個(gè) field，時(shí)間復(fù)雜度：O(N)，N 為一次操作的 field 數(shù)量。
HSETNX：同 HSET，但如 field 已經(jīng)存在，HSETNX 不會(huì)進(jìn)行任何操作，時(shí)間復(fù)雜度 O(1)。
HEXISTS：判斷指定 Hash 中 field 是否存在，存在返回 1，不存在返回 0，時(shí)間復(fù)雜度 O(1)。
HDEL：刪除指定 Hash 中的 field(1 個(gè)或多個(gè))，時(shí)間復(fù)雜度：O(N)，N 為操作的 field 數(shù)量。
HINCRBY：同 INCRBY 命令，對(duì)指定 Hash 中的一個(gè) field 進(jìn)行 INCRBY，時(shí)間復(fù)雜度 O(1)。

應(yīng)謹(jǐn)慎使用的 Hash 相關(guān)命令：

HGETALL：返回指定 Hash 中所有的 field-value 對(duì)。返回結(jié)果為數(shù)組，數(shù)組中 field 和 Value 交替出現(xiàn)。時(shí)間復(fù)雜度 O(N)。
HKEYS/HVALS：返回指定 Hash 中所有的 field/value，時(shí)間復(fù)雜度 O(N)。

上述三個(gè)命令都會(huì)對(duì) Hash 進(jìn)行完整遍歷，Hash 中的 field 數(shù)量與命令的耗時(shí)線性相關(guān)，對(duì)于尺寸不可預(yù)知的 Hash，應(yīng)嚴(yán)格避免使用上面三個(gè)命令。

而改為使用 HSCAN 命令進(jìn)行游標(biāo)式的遍歷，具體請(qǐng)見(jiàn)：

 
 
 
 
  
  
  
  https://redis.io/commands/scan

Set

Redis Set 是無(wú)序的，不可重復(fù)的 String 集合。與 Set 相關(guān)的常用命令：

SADD：向指定 Set 中添加 1 個(gè)或多個(gè) Member，如果指定 Set 不存在，會(huì)自動(dòng)創(chuàng)建一個(gè)。時(shí)間復(fù)雜度 O(N)，N 為添加的 Member 個(gè)數(shù)。
SREM：從指定 Set 中移除 1 個(gè)或多個(gè) Member，時(shí)間復(fù)雜度 O(N)，N 為移除的 Member 個(gè)數(shù)。
SRANDMEMBER：從指定 Set 中隨機(jī)返回 1 個(gè)或多個(gè) Member，時(shí)間復(fù)雜度 O(N)，N 為返回的 Member 個(gè)數(shù)。
SPOP：從指定 Set 中隨機(jī)移除并返回 Count 個(gè) Member，時(shí)間復(fù)雜度O(N)，N 為移除的 Member 個(gè)數(shù)。
SCARD：返回指定 Set 中的 Member 個(gè)數(shù)，時(shí)間復(fù)雜度 O(1)。
SISMEMBER：判斷指定的 Value 是否存在于指定 Set 中，時(shí)間復(fù)雜度 O(1)。
SMOVE：將指定 Member 從一個(gè) Set 移至另一個(gè) Set。

慎用的 Set 相關(guān)命令：

SMEMBERS：返回指定 Hash 中所有的 Member，時(shí)間復(fù)雜度 O(N)。
SUNION/SUNIONSTORE：計(jì)算多個(gè) Set 的并集并返回/存儲(chǔ)至另一個(gè) Set 中，時(shí)間復(fù)雜度 O(N)，N 為參與計(jì)算的所有集合的總 Member 數(shù)。
SINTER/SINTERSTORE：計(jì)算多個(gè) Set 的交集并返回/存儲(chǔ)至另一個(gè) Set 中，時(shí)間復(fù)雜度 O(N)，N 為參與計(jì)算的所有集合的總 Member 數(shù)。
SDIFF/SDIFFSTORE：計(jì)算 1 個(gè) Set 與 1 或多個(gè) Set 的差集并返回/存儲(chǔ)至另一個(gè) Set 中，時(shí)間復(fù)雜度 O(N)，N 為參與計(jì)算的所有集合的總 Member 數(shù)。

上述幾個(gè)命令涉及的計(jì)算量大，應(yīng)謹(jǐn)慎使用，特別是在參與計(jì)算的 Set 尺寸不可知的情況下，應(yīng)嚴(yán)格避免使用。

可以考慮通過(guò) SSCAN 命令遍歷獲取相關(guān) Set 的全部 Member，具體請(qǐng)見(jiàn)：

 
 
 
 
  
  
  
  https://redis.io/commands/scan

如果需要做并集/交集/差集計(jì)算，可以在客戶端進(jìn)行，或在不服務(wù)實(shí)時(shí)查詢請(qǐng)求的 Slave 上進(jìn)行。

Sorted Set

Redis Sorted Set 是有序的、不可重復(fù)的 String 集合。Sorted Set 中的每個(gè)元素都需要指派一個(gè)分?jǐn)?shù)(score)，Sorted Set 會(huì)根據(jù) Score 對(duì)元素進(jìn)行升序排序。

如果多個(gè) Member 擁有相同的 Score，則以字典序進(jìn)行升序排序。Sorted Set 非常適合用于實(shí)現(xiàn)排名。

Sorted Set 的主要命令：

ZADD：向指定 Sorted Set 中添加 1 個(gè)或多個(gè) Member，時(shí)間復(fù)雜度 O(Mlog(N))，M 為添加的 Member 數(shù)量，N 為 Sorted Set 中的 Member 數(shù)量。
ZREM：從指定 Sorted Set 中刪除 1 個(gè)或多個(gè) Member，時(shí)間復(fù)雜度 O(Mlog(N))，M 為刪除的 Member 數(shù)量，N 為 Sorted Set 中的 Member 數(shù)量。
ZCOUNT：返回指定 Sorted Set 中指定 Score 范圍內(nèi)的 Member 數(shù)量，時(shí)間復(fù)雜度：O(log(N))。
ZCARD：返回指定 Sorted Set 中的 Member 數(shù)量，時(shí)間復(fù)雜度 O(1)。
ZSCORE：返回指定 Sorted Set 中指定 Member 的 Score，時(shí)間復(fù)雜度 O(1)。
ZRANK/ZREVRANK：返回指定 Member 在 Sorted Set 中的排名，ZRANK 返回按升序排序的排名，ZREVRANK 則返回按降序排序的排名。時(shí)間復(fù)雜度 O(log(N))。
ZINCRBY：同 INCRBY，對(duì)指定 Sorted Set 中的指定 Member 的 Score 進(jìn)行自增，時(shí)間復(fù)雜度 O(log(N))。

慎用的 Sorted Set 相關(guān)命令：

ZRANGE/ZREVRANGE：返回指定 Sorted Set 中指定排名范圍內(nèi)的所有 Member，ZRANGE 為按 Score 升序排序，ZREVRANGE 為按 Score 降序排序，時(shí)間復(fù)雜度 O(log(N)+M)，M 為本次返回的 Member 數(shù)。
ZRANGEBYSCORE/ZREVRANGEBYSCORE：返回指定 Sorted Set 中指定 Score 范圍內(nèi)的所有 Member，返回結(jié)果以升序/降序排序。
Min 和 Max 可以指定為 -inf 和 +inf，代表返回所有的 Member。時(shí)間復(fù)雜度 O(log(N)+M)。

ZREMRANGEBYRANK/ZREMRANGEBYSCORE：移除 Sorted Set 中指定排名范圍/指定 Score 范圍內(nèi)的所有 Member。時(shí)間復(fù)雜度 O(log(N)+M)。

上述幾個(gè)命令，應(yīng)盡量避免傳遞 [0 -1] 或 [-inf +inf] 這樣的參數(shù)，來(lái)對(duì) Sorted Set 做一次性的完整遍歷，特別是在 Sorted Set 的尺寸不可預(yù)知的情況下。

可以通過(guò) ZSCAN 命令來(lái)進(jìn)行游標(biāo)式的遍歷，具體請(qǐng)見(jiàn)：

 
 
 
 
  
  
  
  https://redis.io/commands/scan

或通過(guò) LIMIT 參數(shù)來(lái)限制返回 Member 的數(shù)量(適用于 ZRANGEBYSCORE 和 ZREVRANGEBYSCORE 命令)，以實(shí)現(xiàn)游標(biāo)式的遍歷。

Bitmap 和 HyperLogLog

Redis 的這兩種數(shù)據(jù)結(jié)構(gòu)相較之前的并不常用，在本文中只做簡(jiǎn)要介紹，如想要詳細(xì)了解這兩種數(shù)據(jù)結(jié)構(gòu)與其相關(guān)的命令，請(qǐng)參考官方文檔中的相關(guān)章節(jié)：

 
 
 
 
  
  
  
  https://redis.io/topics/data-types-intro

Bitmap 在 Redis 中不是一種實(shí)際的數(shù)據(jù)類型，而是一種將 String 作為 Bitmap 使用的方法。

可以理解為將 String 轉(zhuǎn)換為 bit 數(shù)組。使用 Bitmap 來(lái)存儲(chǔ) true/false 類型的簡(jiǎn)單數(shù)據(jù)極為節(jié)省空間。

HyperLogLogs 是一種主要用于數(shù)量統(tǒng)計(jì)的數(shù)據(jù)結(jié)構(gòu)，它和 Set 類似，維護(hù)一個(gè)不可重復(fù)的 String 集合，但是 HyperLogLogs 并不維護(hù)具體的 Member 內(nèi)容，只維護(hù) Member 的個(gè)數(shù)。

也就是說(shuō)，HyperLogLogs 只能用于計(jì)算一個(gè)集合中不重復(fù)的元素?cái)?shù)量，所以它比 Set 要節(jié)省很多內(nèi)存空間。

其他常用命令：

EXISTS：判斷指定的 Key 是否存在，返回 1 代表存在，0 代表不存在，時(shí)間復(fù)雜度 O(1)。
DEL：刪除指定的 Key 及其對(duì)應(yīng)的 Value，時(shí)間復(fù)雜度 O(N)，N 為刪除的 Key 數(shù)量。
EXPIRE/PEXPIRE：為一個(gè) Key 設(shè)置有效期，單位為秒或毫秒，時(shí)間復(fù)雜度 O(1)。
TTL/PTTL：返回一個(gè) Key 剩余的有效時(shí)間，單位為秒或毫秒，時(shí)間復(fù)雜度 O(1)。
RENAME/RENAMENX：將 Key 重命名為 Newkey。使用 RENAME 時(shí)，如果 Newkey 已經(jīng)存在，其值會(huì)被覆蓋。

使用 RENAMENX 時(shí)，如果 Newkey 已經(jīng)存在，則不會(huì)進(jìn)行任何操作，時(shí)間復(fù)雜度 O(1)。

TYPE：返回指定 Key 的類型，String，List，Set，Zset，Hash。時(shí)間復(fù)雜度 O(1)。
CONFIG GET：獲得 Redis 某配置項(xiàng)的當(dāng)前值，可以使用 * 通配符，時(shí)間復(fù)雜度 O(1)。
CONFIG SET：為 Redis 某個(gè)配置項(xiàng)設(shè)置新值，時(shí)間復(fù)雜度 O(1)。
CONFIG REWRITE：讓 Redis 重新加載 redis.conf 中的配置。

數(shù)據(jù)持久化

Redis 提供了將數(shù)據(jù)定期自動(dòng)持久化至硬盤(pán)的能力，包括 RDB 和 AOF 兩種方案，兩種方案分別有其長(zhǎng)處和短板，可以配合起來(lái)同時(shí)運(yùn)行，確保數(shù)據(jù)的穩(wěn)定性。

必須使用數(shù)據(jù)持久化嗎?Redis 的數(shù)據(jù)持久化機(jī)制是可以關(guān)閉的。如果你只把 Redis 作為緩存服務(wù)使用，Redis 中存儲(chǔ)的所有數(shù)據(jù)都不是該數(shù)據(jù)的主體而僅僅是同步過(guò)來(lái)的備份，那么可以關(guān)閉 Redis 的數(shù)據(jù)持久化機(jī)制。

但通常來(lái)說(shuō)，仍然建議至少開(kāi)啟 RDB 方式的數(shù)據(jù)持久化，因?yàn)椋?/p>

RDB 方式的持久化幾乎不損耗 Redis 本身的性能，在進(jìn)行 RDB 持久化時(shí)，Redis 主進(jìn)程唯一需要做的事情就是 Fork 出一個(gè)子進(jìn)程，所有持久化工作都由子進(jìn)程完成。
Redis 無(wú)論因?yàn)槭裁丛?Crash 掉之后，重啟時(shí)能夠自動(dòng)恢復(fù)到上一次 RDB 快照中記錄的數(shù)據(jù)。

這省去了手工從其他數(shù)據(jù)源(如 DB)同步數(shù)據(jù)的過(guò)程，而且要比其他任何的數(shù)據(jù)恢復(fù)方式都要快。

現(xiàn)在硬盤(pán)那么大，真的不缺那一點(diǎn)地方。

RDB

采用 RDB 持久方式，Redis 會(huì)定期保存數(shù)據(jù)快照至一個(gè) RBD 文件中，并在啟動(dòng)時(shí)自動(dòng)加載 RDB 文件，恢復(fù)之前保存的數(shù)據(jù)。

可以在配置文件中配置 Redis 進(jìn)行快照保存的時(shí)機(jī)：

 
 
 
 
  
  
  
  save [seconds] [changes]

意為在 [seconds] 秒內(nèi)如果發(fā)生了 [changes] 次數(shù)據(jù)修改，則進(jìn)行一次 RDB 快照保存，例如：

 
 
 
 
  
  
  
  save 60 100

會(huì)讓 Redis 每 60 秒檢查一次數(shù)據(jù)變更情況，如果發(fā)生了 100 次或以上的數(shù)據(jù)變更，則進(jìn)行 RDB 快照保存。可以配置多條 Save 指令，讓 Redis 執(zhí)行多級(jí)的快照保存策略。

Redis 默認(rèn)開(kāi)啟 RDB 快照，默認(rèn)的 RDB 策略如下：

 
 
 
 
  
  
  
  save 900 1
  
  
  
  save 300 10
  
  
  
  save 60 10000

也可以通過(guò) BGSAVE 命令手工觸發(fā) RDB 快照保存。

RDB 的優(yōu)點(diǎn)：

對(duì)性能影響最小。如前文所述，Redis 在保存 RDB 快照時(shí)會(huì) Fork 出子進(jìn)程進(jìn)行，幾乎不影響 Redis 處理客戶端請(qǐng)求的效率。
每次快照會(huì)生成一個(gè)完整的數(shù)據(jù)快照文件，所以可以輔以其他手段保存多個(gè)時(shí)間點(diǎn)的快照(例如把每天 0 點(diǎn)的快照備份至其他存儲(chǔ)媒介中)，作為非?？煽康臑?zāi)難恢復(fù)手段。
使用 RDB 文件進(jìn)行數(shù)據(jù)恢復(fù)比使用 AOF 要快很多。

RDB 的缺點(diǎn)：

快照是定期生成的，所以在 Redis Crash 時(shí)或多或少會(huì)丟失一部分?jǐn)?shù)據(jù)。
如果數(shù)據(jù)集非常大且 CPU 不夠強(qiáng)(比如單核 CPU)，Redis 在 Fork 子進(jìn)程時(shí)可能會(huì)消耗相對(duì)較長(zhǎng)的時(shí)間(長(zhǎng)至 1 秒)，影響這期間的客戶端請(qǐng)求。

AOF

采用 AOF 持久方式時(shí)，Redis 會(huì)把每一個(gè)寫(xiě)請(qǐng)求都記錄在一個(gè)日志文件里。在 Redis 重啟時(shí)，會(huì)把 AOF 文件中記錄的所有寫(xiě)操作順序執(zhí)行一遍，確保數(shù)據(jù)恢復(fù)到最新。

AOF 默認(rèn)是關(guān)閉的，如要開(kāi)啟，進(jìn)行如下配置：

 
 
 
 
  
  
  
  appendonly yes

AOF 提供了三種 Fsync 配置，always/everysec/no，通過(guò)配置項(xiàng) [appendfsync] 指定：

appendfsync no：不進(jìn)行 Fsync，將 Flush 文件的時(shí)機(jī)交給 OS 決定，速度最快。
appendfsync always：每寫(xiě)入一條日志就進(jìn)行一次 Fsync 操作，數(shù)據(jù)安全性最高，但速度最慢。
appendfsync everysec：折中的做法，交由后臺(tái)線程每秒 Fsync 一次。

隨著 AOF 不斷地記錄寫(xiě)操作日志，必定會(huì)出現(xiàn)一些無(wú)用的日志，例如某個(gè)時(shí)間點(diǎn)執(zhí)行了命令 SET key1 “abc”，在之后某個(gè)時(shí)間點(diǎn)又執(zhí)行了 SET key1 “bcd”，那么第一條命令很顯然是沒(méi)有用的。

大量的無(wú)用日志會(huì)讓 AOF 文件過(guò)大，也會(huì)讓數(shù)據(jù)恢復(fù)的時(shí)間過(guò)長(zhǎng)。所以 Redis 提供了 AOF Rewrite 功能，可以重寫(xiě) AOF 文件，只保留能夠把數(shù)據(jù)恢復(fù)到最新?tīng)顟B(tài)的最小寫(xiě)操作集。

AOF Rewrite 可以通過(guò) BGREWRITEAOF 命令觸發(fā)，也可以配置 Redis 定期自動(dòng)進(jìn)行：

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

上面兩行配置的含義是，Redis 在每次 AOF Rewrite 時(shí)，會(huì)記錄完成 Rewrite 后的 AOF 日志大小，當(dāng) AOF 日志大小在該基礎(chǔ)上增長(zhǎng)了 100% 后，自動(dòng)進(jìn)行 AOF Rewrite。

同時(shí)如果增長(zhǎng)的大小沒(méi)有達(dá)到 64MB，則不會(huì)進(jìn)行 Rewrite。

AOF 的優(yōu)點(diǎn)：

最安全，在啟用 appendfsync always 時(shí)，任何已寫(xiě)入的數(shù)據(jù)都不會(huì)丟失，使用在啟用 appendfsync everysec 也至多只會(huì)丟失 1 秒的數(shù)據(jù)。
AOF 文件在發(fā)生斷電等問(wèn)題時(shí)也不會(huì)損壞，即使出現(xiàn)了某條日志只寫(xiě)入了一半的情況，也可以使用 redis-check-aof 工具輕松修復(fù)。
AOF 文件易讀，可修改，在進(jìn)行了某些錯(cuò)誤的數(shù)據(jù)清除操作后，只要 AOF 文件沒(méi)有 Rewrite，就可以把 AOF 文件備份出來(lái)，把錯(cuò)誤的命令刪除，然后恢復(fù)數(shù)據(jù)。

AOF 的缺點(diǎn)：

AOF 文件通常比 RDB 文件更大。
性能消耗比 RDB 高。
數(shù)據(jù)恢復(fù)速度比 RDB 慢。

內(nèi)存管理與數(shù)據(jù)淘汰機(jī)制

最大內(nèi)存設(shè)置

默認(rèn)情況下，在 32 位 OS 中，Redis 最大使用 3GB 的內(nèi)存，在 64 位 OS 中則沒(méi)有限制。

在使用 Redis 時(shí)，應(yīng)該對(duì)數(shù)據(jù)占用的最大空間有一個(gè)基本準(zhǔn)確的預(yù)估，并為 Redis 設(shè)定最大使用的內(nèi)存。

否則在 64 位 OS 中 Redis 會(huì)無(wú)限制地占用內(nèi)存(當(dāng)物理內(nèi)存被占滿后會(huì)使用 Swap 空間)，容易引發(fā)各種各樣的問(wèn)題。

通過(guò)如下配置控制 Redis 使用的最大內(nèi)存：

 
 
 
 
  
  
  
  maxmemory 100mb

在內(nèi)存占用達(dá)到了 maxmemory 后，再向 Redis 寫(xiě)入數(shù)據(jù)時(shí)，Redis 會(huì)：

根據(jù)配置的數(shù)據(jù)淘汰策略嘗試淘汰數(shù)據(jù)，釋放空間。
如果沒(méi)有數(shù)據(jù)可以淘汰，或者沒(méi)有配置數(shù)據(jù)淘汰策略，那么 Redis 會(huì)對(duì)所有寫(xiě)請(qǐng)求返回錯(cuò)誤，但讀請(qǐng)求仍然可以正常執(zhí)行。

在為 Redis 設(shè)置 maxmemory 時(shí)，需要注意：如果采用了 Redis 的主從同步，主節(jié)點(diǎn)向從節(jié)點(diǎn)同步數(shù)據(jù)時(shí)，會(huì)占用掉一部分內(nèi)存空間;如果 maxmemory 過(guò)于接近主機(jī)的可用內(nèi)存，導(dǎo)致數(shù)據(jù)同步時(shí)內(nèi)存不足。

所以設(shè)置的 maxmemory 不要過(guò)于接近主機(jī)可用的內(nèi)存，留出一部分預(yù)留用作主從同步。

數(shù)據(jù)淘汰機(jī)制

Redis 提供了 5 種數(shù)據(jù)淘汰策略：

volatile-lru：使用 LRU 算法進(jìn)行數(shù)據(jù)淘汰(淘汰上次使用時(shí)間最早的，且使用次數(shù)最少的 Key)，只淘汰設(shè)定了有效期的 Key。
allkeys-lru：使用 LRU 算法進(jìn)行數(shù)據(jù)淘汰，所有的 Key 都可以被淘汰。
volatile-random：隨機(jī)淘汰數(shù)據(jù)，只淘汰設(shè)定了有效期的 Key。
allkeys-random：隨機(jī)淘汰數(shù)據(jù)，所有的 Key 都可以被淘汰。
volatile-ttl：淘汰剩余有效期最短的 Key。

最好為 Redis 指定一種有效的數(shù)據(jù)淘汰策略以配合 maxmemory 設(shè)置，避免在內(nèi)存使用滿后發(fā)生寫(xiě)入失敗的情況。

一般來(lái)說(shuō)，推薦使用的策略是 volatile-lru，并辨識(shí) Redis 中保存的數(shù)據(jù)的重要性。

對(duì)于那些重要的，絕對(duì)不能丟棄的數(shù)據(jù)(如配置類數(shù)據(jù)等)，應(yīng)不設(shè)置有效期，這樣 Redis 就永遠(yuǎn)不會(huì)淘汰這些數(shù)據(jù)。

對(duì)于那些相對(duì)不是那么重要的，并且能夠熱加載的數(shù)據(jù)(比如緩存最近登錄的用戶信息，當(dāng)在 Redis 中找不到時(shí)，程序會(huì)去 DB 中讀取)，可以設(shè)置上有效期，這樣在內(nèi)存不夠時(shí) Redis 就會(huì)淘汰這部分?jǐn)?shù)據(jù)。

配置方法：

 
 
 
 
  
  
  
  maxmemory-policy volatile-lru #默認(rèn)是noeviction，即不進(jìn)行數(shù)據(jù)淘汰

Pipelining

Redis 提供許多批量操作的命令，如 MSET/MGET/HMSET/HMGET 等等，這些命令存在的意義是減少維護(hù)網(wǎng)絡(luò)連接和傳輸數(shù)據(jù)所消耗的資源和時(shí)間。

例如連續(xù)使用 5 次 SET 命令設(shè)置 5 個(gè)不同的 Key，比起使用一次 MSET 命令設(shè)置 5 個(gè)不同的 Key，效果是一樣的，但前者會(huì)消耗更多的 RTT(Round Trip Time)時(shí)長(zhǎng)，永遠(yuǎn)應(yīng)優(yōu)先使用后者。

然而，如果客戶端要連續(xù)執(zhí)行的多次操作無(wú)法通過(guò) Redis 命令組合在一起，例如：

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

此時(shí)便可以使用 Redis 提供的 Pipelining 功能來(lái)實(shí)現(xiàn)在一次交互中執(zhí)行多條命令。

使用 Pipelining 時(shí)，只需要從客戶端一次向 Redis 發(fā)送多條命令(以 rn)分隔，Redis 就會(huì)依次執(zhí)行這些命令，并且把每個(gè)命令的返回按順序組裝在一起一次返回，比如：

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

大部分的 Redis 客戶端都對(duì) Pipelining 提供支持，所以開(kāi)發(fā)者通常并不需要自己手工拼裝命令列表。

Pipelining 的局限性

Pipelining 只能用于執(zhí)行連續(xù)且無(wú)相關(guān)性的命令，當(dāng)某個(gè)命令的生成需要依賴于前一個(gè)命令的返回時(shí)，就無(wú)法使用 Pipelining 了。通過(guò) Scripting 功能，可以規(guī)避這一局限性。

事務(wù)與 Scripting

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

比如獲取當(dāng)前累計(jì)的 PV 數(shù)并將其清 0：

 
 
 
 
  
  
  
  > GET vCount
  
  
  
  12384
  
  
  
  > SET vCount 0
  
  
  
  OK

如果在 GET 和 SET 命令之間插進(jìn)來(lái)一個(gè) INCR vCount，就會(huì)使客戶端拿到的 vCount 不準(zhǔn)確。

Redis 的事務(wù)可以確保復(fù)數(shù)命令執(zhí)行時(shí)的原子性。也就是說(shuō) Redis 能夠保證：一個(gè)事務(wù)中的一組命令是絕對(duì)連續(xù)執(zhí)行的，在這些命令執(zhí)行完成之前，絕對(duì)不會(huì)有來(lái)自于其他連接的其他命令插進(jìn)去執(zhí)行。

通過(guò) MULTI 和 EXEC 命令來(lái)把這兩個(gè)命令加入一個(gè)事務(wù)中：

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

Redis 在接收到 MULTI 命令后便會(huì)開(kāi)啟一個(gè)事務(wù)，這之后的所有讀寫(xiě)命令都會(huì)保存在隊(duì)列中但并不執(zhí)行，直到接收到 EXEC 命令后，Redis 會(huì)把隊(duì)列中的所有命令連續(xù)順序執(zhí)行，并以數(shù)組形式返回每個(gè)命令的返回結(jié)果。

可以使用 DISCARD 命令放棄當(dāng)前的事務(wù)，將保存的命令隊(duì)列清空。需要注意的是，Redis 事務(wù)不支持回滾。

如果一個(gè)事務(wù)中的命令出現(xiàn)了語(yǔ)法錯(cuò)誤，大部分客戶端驅(qū)動(dòng)會(huì)返回錯(cuò)誤，2.6.5 版本以上的 Redis 也會(huì)在執(zhí)行 EXEC 時(shí)檢查隊(duì)列中的命令是否存在語(yǔ)法錯(cuò)誤，如果存在，則會(huì)自動(dòng)放棄事務(wù)并返回錯(cuò)誤。

但如果一個(gè)事務(wù)中的命令有非語(yǔ)法類的錯(cuò)誤(比如對(duì) String 執(zhí)行 HSET 操作)，無(wú)論客戶端驅(qū)動(dòng)還是 Redis 都無(wú)法在真正執(zhí)行這條命令之前發(fā)現(xiàn)，所以事務(wù)中的所有命令仍然會(huì)被依次執(zhí)行。

在這種情況下，會(huì)出現(xiàn)一個(gè)事務(wù)中部分命令成功部分命令失敗的情況，然而與 RDBMS 不同，Redis 不提供事務(wù)回滾的功能，所以只能通過(guò)其他方法進(jìn)行數(shù)據(jù)的回滾。

通過(guò)事務(wù)實(shí)現(xiàn) CAS

Redis 提供了 WATCH 命令與事務(wù)搭配使用，實(shí)現(xiàn) CAS 樂(lè)觀鎖的機(jī)制。

假設(shè)要實(shí)現(xiàn)將某個(gè)商品的狀態(tài)改為已售：

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

這一偽代碼執(zhí)行時(shí)，無(wú)法確保并發(fā)安全性，有可能多個(gè)客戶端都獲取到了”in stock”的狀態(tài)，導(dǎo)致一個(gè)庫(kù)存被售賣(mài)多次。

使用 WATCH 命令和事務(wù)可以解決這一問(wèn)題：

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

WATCH 的機(jī)制是：在事務(wù) EXEC 命令執(zhí)行時(shí)，Redis 會(huì)檢查被 WATCH 的 Key，只有被 WATCH 的 Key 從 WATCH 起始時(shí)至今沒(méi)有發(fā)生過(guò)變更，EXEC 才會(huì)被執(zhí)行。

如果 WATCH 的 Key 在 WATCH 命令到 EXEC 命令之間發(fā)生過(guò)變化，則 EXEC 命令會(huì)返回失敗。

Scripting

通過(guò) EVAL 與 EVALSHA 命令，可以讓 Redis 執(zhí)行 LUA 腳本。這就類似于 RDBMS 的存儲(chǔ)過(guò)程一樣，可以把客戶端與 Redis 之間密集的讀/寫(xiě)交互放在服務(wù)端進(jìn)行，避免過(guò)多的數(shù)據(jù)交互，提升性能。

Scripting 功能是作為事務(wù)功能的替代者誕生的，事務(wù)提供的所有能力 Scripting 都可以做到。Redis 官方推薦使用 LUA Script 來(lái)代替事務(wù)，前者的效率和便利性都超過(guò)了事務(wù)。

關(guān)于 Scripting 的具體使用，本文不做詳細(xì)介紹，請(qǐng)參考官方文檔：

 
 
 
 
  
  
  
  https://redis.io/commands/eval

Redis 性能調(diào)優(yōu)

盡管 Redis 是一個(gè)非?？焖俚膬?nèi)存數(shù)據(jù)存儲(chǔ)媒介，也并不代表 Redis 不會(huì)產(chǎn)生性能問(wèn)題。

前文中提到過(guò)，Redis 采用單線程模型，所有的命令都是由一個(gè)線程串行執(zhí)行的，所以當(dāng)某個(gè)命令執(zhí)行耗時(shí)較長(zhǎng)時(shí)，會(huì)拖慢其后的所有命令，這使得 Redis 對(duì)每個(gè)任務(wù)的執(zhí)行效率更加敏感。

針對(duì) Redis 的性能優(yōu)化，主要從下面幾個(gè)層面入手：

最初的也是最重要的，確保沒(méi)有讓 Redis 執(zhí)行耗時(shí)長(zhǎng)的命令。
使用 Pipelining 將連續(xù)執(zhí)行的命令組合執(zhí)行。
操作系統(tǒng)的 Transparent huge pages 功能必須關(guān)閉。

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

如果在虛擬機(jī)中運(yùn)行 Redis，可能天然就有虛擬機(jī)環(huán)境帶來(lái)的固有延遲?？梢酝ㄟ^(guò) ./redis-cli –intrinsic-latency 100 命令查看固有延遲。
同時(shí)如果對(duì) Redis 的性能有較高要求的話，應(yīng)盡可能在物理機(jī)上直接部署 Redis。
檢查數(shù)據(jù)持久化策略。

考慮引入讀寫(xiě)分離機(jī)制。

長(zhǎng)耗時(shí)命令

Redis 絕大多數(shù)讀寫(xiě)命令的時(shí)間復(fù)雜度都在 O(1) 到 O(N) 之間，在文本和官方文檔中均對(duì)每個(gè)命令的時(shí)間復(fù)雜度有說(shuō)明。

通常來(lái)說(shuō)，O(1) 的命令是安全的，O(N) 命令在使用時(shí)需要注意，如果 N 的數(shù)量級(jí)不可預(yù)知，則應(yīng)避免使用。

例如對(duì)一個(gè) field 數(shù)未知的 Hash 數(shù)據(jù)執(zhí)行 HGETALL/HKEYS/HVALS 命令，通常來(lái)說(shuō)這些命令執(zhí)行的很快，但如果這個(gè) Hash 中的 field 數(shù)量極多，耗時(shí)就會(huì)成倍增長(zhǎng)。

又如使用 SUNION 對(duì)兩個(gè) Set 執(zhí)行 Union 操作，或使用 SORT 對(duì) List/Set 執(zhí)行排序操作等時(shí)，都應(yīng)該嚴(yán)加注意。

避免在使用這些 O(N) 命令時(shí)發(fā)生問(wèn)題主要有幾個(gè)辦法：

不要把 List 當(dāng)做列表使用，僅當(dāng)做隊(duì)列來(lái)使用。
通過(guò)機(jī)制嚴(yán)格控制 Hash、Set、Sorted Set 的大小。
可能的話，將排序、并集、交集等操作放在客戶端執(zhí)行。
絕對(duì)禁止使用 Keys 命令。
避免一次性遍歷集合類型的所有成員，而應(yīng)使用 SCAN 類的命令進(jìn)行分批的，游標(biāo)式的遍歷。

Redis 提供了 SCAN 命令，可以對(duì) Redis 中存儲(chǔ)的所有 Key 進(jìn)行游標(biāo)式的遍歷，避免使用 Keys 命令帶來(lái)的性能問(wèn)題。

同時(shí)還有 SSCAN/HSCAN/ZSCAN 等命令，分別用于對(duì) Set/Hash/Sorted Set 中的元素進(jìn)行游標(biāo)式遍歷。

SCAN 類命令的使用請(qǐng)參考官方文檔：

 
 
 
 
  
  
  
  https://redis.io/commands/scan

Redis 提供了 Slow Log 功能，可以自動(dòng)記錄耗時(shí)較長(zhǎng)的命令。相關(guān)的配置參數(shù)有兩個(gè)：

 
 
 
 
  
  
  
  slowlog-log-slower-than xxxms  #執(zhí)行時(shí)間慢于xxx毫秒的命令計(jì)入Slow Log
  
  
  
  slowlog-max-len xxx  #Slow Log的長(zhǎng)度，即最大紀(jì)錄多少條Slow Log

使用 SLOWLOG GET [number] 命令，可以輸出最近進(jìn)入 Slow Log 的 Mumber 條命令。使用 SLOWLOG RESET 命令，可以重置 Slow Log。

網(wǎng)絡(luò)引發(fā)的延遲

盡可能使用長(zhǎng)連接或連接池，避免頻繁創(chuàng)建銷(xiāo)毀連接，客戶端進(jìn)行的批量數(shù)據(jù)操作，應(yīng)使用 Pipeline 特性在一次交互中完成。具體請(qǐng)參照本文的 Pipelining 章節(jié)。

數(shù)據(jù)持久化引發(fā)的延遲

Redis 的數(shù)據(jù)持久化工作本身就會(huì)帶來(lái)延遲，需要根據(jù)數(shù)據(jù)的安全級(jí)別和性能要求制定合理的持久化策略：

AOF + fsync always 的設(shè)置雖然能夠絕對(duì)確保數(shù)據(jù)安全，但每個(gè)操作都會(huì)觸發(fā)一次 Fsync，會(huì)對(duì) Redis 的性能有比較明顯的影響。
AOF + fsync every second 是比較好的折中方案，每秒 Fsync 一次。
AOF + fsync never 會(huì)提供 AOF 持久化方案下的最優(yōu)性能。
使用 RDB 持久化通常會(huì)提供比使用 AOF 更高的性能，但需要注意 RDB 的策略配置。
每一次 RDB 快照和 AOF Rewrite 都需要 Redis 主進(jìn)程進(jìn)行 Fork 操作。Fork 操作本身可能會(huì)產(chǎn)生較高的耗時(shí)，與 CPU 和 Redis 占用的內(nèi)存大小有關(guān)。

根據(jù)具體的情況合理配置 RDB 快照和 AOF Rewrite 時(shí)機(jī)，避免過(guò)于頻繁的 Fork 帶來(lái)的延遲。

Redis 在 Fork 子進(jìn)程時(shí)需要將內(nèi)存分頁(yè)表拷貝至子進(jìn)程，以占用了 24GB 內(nèi)存的 Redis 實(shí)例為例，共需要拷貝 24GB / 4KB * 8 = 48MB 的數(shù)據(jù)。

在使用單 Xeon 2.27Ghz 的物理機(jī)上，這一 Fork 操作耗時(shí) 216ms?？梢酝ㄟ^(guò) INFO 命令返回的 latest_fork_usec 字段查看上一次 Fork 操作的耗時(shí)(微秒)。

Swap 引發(fā)的延遲

當(dāng) Linux 將 Redis 所用的內(nèi)存分頁(yè)移至 Swap 空間時(shí)，將會(huì)阻塞 Redis 進(jìn)程，導(dǎo)致 Redis 出現(xiàn)不正常的延遲。

Swap 通常在物理內(nèi)存不足或一些進(jìn)程在進(jìn)行大量 I/O 操作時(shí)發(fā)生，應(yīng)盡可能避免上述兩種情況的出現(xiàn)。

/proc/ /smaps 文件中會(huì)保存進(jìn)程的 Swap 記錄，通過(guò)查看這個(gè)文件，能夠判斷 Redis 的延遲是否由 Swap 產(chǎn)生。

如果這個(gè)文件中記錄了較大的 Swap size，則說(shuō)明延遲很有可能是 Swap 造成的。

數(shù)據(jù)淘汰引發(fā)的延遲

當(dāng)同一秒內(nèi)有大量 Key 過(guò)期時(shí)，也會(huì)引發(fā) Redis 的延遲。在使用時(shí)應(yīng)盡量將 Key 的失效時(shí)間錯(cuò)開(kāi)。

引入讀寫(xiě)分離機(jī)制

Redis 的主從復(fù)制能力可以實(shí)現(xiàn)一主多從的多節(jié)點(diǎn)架構(gòu)，在這一架構(gòu)下，主節(jié)點(diǎn)接收所有寫(xiě)請(qǐng)求，并將數(shù)據(jù)同步給多個(gè)從節(jié)點(diǎn)。

在這一基礎(chǔ)上，我們可以讓從節(jié)點(diǎn)提供對(duì)實(shí)時(shí)性要求不高的讀請(qǐng)求服務(wù)，以減小主節(jié)點(diǎn)的壓力。

尤其是針對(duì)一些使用了長(zhǎng)耗時(shí)命令的統(tǒng)計(jì)類任務(wù)，完全可以指定在一個(gè)或多個(gè)從節(jié)點(diǎn)上執(zhí)行，避免這些長(zhǎng)耗時(shí)命令影響其他請(qǐng)求的響應(yīng)。

主從復(fù)制與集群分片

主從復(fù)制

Redis 支持一主多從的主從復(fù)制架構(gòu)。一個(gè) Master 實(shí)例負(fù)責(zé)處理所有的寫(xiě)請(qǐng)求，Master 將寫(xiě)操作同步至所有 Slave。

借助 Redis 的主從復(fù)制，可以實(shí)現(xiàn)讀寫(xiě)分離和高可用：

實(shí)時(shí)性要求不是特別高的讀請(qǐng)求，可以在 Slave 上完成，提升效率。特別是一些周期性執(zhí)行的統(tǒng)計(jì)任務(wù)，這些任務(wù)可能需要執(zhí)行一些長(zhǎng)耗時(shí)的 Redis 命令，可以專門(mén)規(guī)劃出 1 個(gè)或幾個(gè) Slave 用于服務(wù)這些統(tǒng)計(jì)任務(wù)。
借助 Redis Sentinel 可以實(shí)現(xiàn)高可用，當(dāng) Master Crash 后，Redis Sentinel 能夠自動(dòng)將一個(gè) Slave 晉升為 Master，繼續(xù)提供服務(wù)。

啟用主從復(fù)制非常簡(jiǎn)單，只需要配置多個(gè) Redis 實(shí)例，在作為 Slave 的 Redis 實(shí)例中配置：

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

當(dāng) Slave 啟動(dòng)后，會(huì)從 Master 進(jìn)行一次冷啟動(dòng)數(shù)據(jù)同步，由 Master 觸發(fā) BGSAVE 生成 RDB 文件推送給 Slave 進(jìn)行導(dǎo)入。

導(dǎo)入完成后 Master 再將增量數(shù)據(jù)通過(guò) Redis Protocol 同步給 Slave。之后主從之間的數(shù)據(jù)便一直以 Redis Protocol 進(jìn)行同步。

使用 Sentinel 做自動(dòng) Failover：Redis 的主從復(fù)制功能本身只是做數(shù)據(jù)同步，并不提供監(jiān)控和自動(dòng) Failover 能力，要通過(guò)主從復(fù)制功能來(lái)實(shí)現(xiàn) Redis 的高可用，還需要引入一個(gè)組件：Redis Sentinel。

Redis Sentinel 是 Redis 官方開(kāi)發(fā)的監(jiān)控組件，可以監(jiān)控 Redis 實(shí)例的狀態(tài)，通過(guò) Master 節(jié)點(diǎn)自動(dòng)發(fā)現(xiàn) Slave 節(jié)點(diǎn)，并在監(jiān)測(cè)到 Master 節(jié)點(diǎn)失效時(shí)選舉出一個(gè)新的 Master，并向所有 Redis 實(shí)例推送新的主從配置。

Redis Sentinel 需要至少部署 3 個(gè)實(shí)例才能形成選舉關(guān)系。關(guān)鍵配置：

 
 
 
 
  
  
  
  sentinel monitor mymaster 127.0.0.1 6379 2  #Master實(shí)例的IP、端口，以及選舉需要的贊成票數(shù)
  
  
  
  sentinel down-after-milliseconds mymaster 60000  #多長(zhǎng)時(shí)間沒(méi)有響應(yīng)視為Master失效
  
  
  
  sentinel failover-timeout mymaster 180000  #兩次failover嘗試間的間隔時(shí)長(zhǎng)
  
  
  
  sentinel parallel-syncs mymaster 1  #如果有多個(gè)Slave，可以通過(guò)此配置指定同時(shí)從新Master進(jìn)行數(shù)據(jù)同步的Slave數(shù)，避免所有Slave同時(shí)進(jìn)行數(shù)據(jù)同步導(dǎo)致查詢服務(wù)也不可用

另外需要注意的是，Redis Sentinel 實(shí)現(xiàn)的自動(dòng) Failover 不是在同一個(gè) IP 和端口上完成的。

也就是說(shuō)自動(dòng) Failover 產(chǎn)生的新 Master 提供服務(wù)的 IP 和端口與之前的 Master 是不一樣的。

所以要實(shí)現(xiàn) HA，還要求客戶端必須支持 Sentinel，能夠與 Sentinel 交互獲得新 Master 的信息才行。

集群分片

為何要做集群分片?原因如下：

Redis 中存儲(chǔ)的數(shù)據(jù)量大，一臺(tái)主機(jī)的物理內(nèi)存已經(jīng)無(wú)法容納。
Redis 的寫(xiě)請(qǐng)求并發(fā)量大，一個(gè) Redis 實(shí)例以無(wú)法承載。

當(dāng)上述兩個(gè)問(wèn)題出現(xiàn)時(shí)，就必須要對(duì) Redis 進(jìn)行分片了。Redis 的分片方案有很多種，例如很多 Redis 的客戶端都自行實(shí)現(xiàn)了分片功能，也有向 Twemproxy 這樣的以代理方式實(shí)現(xiàn)的 Redis 分片方案。

然而選擇的方案還應(yīng)該是 Redis 官方在 3.0 版本中推出的 Redis Cluster 分片方案。

本文不會(huì)對(duì) Redis Cluster 的具體安裝和部署細(xì)節(jié)進(jìn)行介紹，重點(diǎn)介紹 Redis Cluster 帶來(lái)的好處與弊端。

Redis Cluster 的能力：

能夠自動(dòng)將數(shù)據(jù)分散在多個(gè)節(jié)點(diǎn)上。
當(dāng)訪問(wèn)的 Key 不在當(dāng)前分片上時(shí)，能夠自動(dòng)將請(qǐng)求轉(zhuǎn)發(fā)至正確的分片。
當(dāng)集群中部分節(jié)點(diǎn)失效時(shí)仍能提供服務(wù)。

其中第三點(diǎn)是基于主從復(fù)制來(lái)實(shí)現(xiàn)的，Redis Cluster 的每個(gè)數(shù)據(jù)分片都采用了主從復(fù)制的結(jié)構(gòu)，原理和前文所述的主從復(fù)制完全一致。

唯一的區(qū)別是省去了 Redis Sentinel 這一額外的組件，由 Redis Cluster 負(fù)責(zé)進(jìn)行一個(gè)分片內(nèi)部的節(jié)點(diǎn)監(jiān)控和自動(dòng) Failover。

Redis Cluster 分片原理：Redis Cluster 中共有 16384 個(gè) hash slot，Redis 會(huì)計(jì)算每個(gè) Key 的 CRC16，將結(jié)果與 16384 取模，來(lái)決定該 Key 存儲(chǔ)在哪一個(gè) hash slot 中。

同時(shí)需要指定 Redis Cluster 中每個(gè)數(shù)據(jù)分片負(fù)責(zé)的 Slot 數(shù)。Slot 的分配在任何時(shí)間點(diǎn)都可以進(jìn)行重新分配。

客戶端在對(duì) Key 進(jìn)行讀寫(xiě)操作時(shí)，可以連接 Cluster 中的任意一個(gè)分片，如果操作的 Key 不在此分片負(fù)責(zé)的 Slot 范圍內(nèi)，Redis Cluster 會(huì)自動(dòng)將請(qǐng)求重定向到正確的分片上。

Hash Tags：在基礎(chǔ)的分片原則上，Redis 還支持 hash tags 功能，以 hash tags 要求的格式明明的 Key，將會(huì)確保進(jìn)入同一個(gè) Slot 中。

例如：{uiv}user:1000 和 {uiv}user:1001 擁有同樣的 hash tag {uiv}，會(huì)保存在同一個(gè) Slot 中。

使用 Redis Cluster 時(shí)，Pipelining、事務(wù)和 LUA Script 功能涉及的 Key 必須在同一個(gè)數(shù)據(jù)分片上，否則將會(huì)返回錯(cuò)誤。

如要在 Redis Cluster 中使用上述功能，就必須通過(guò) hash tags 來(lái)確保一個(gè) Pipeline 或一個(gè)事務(wù)中操作的所有 Key 都位于同一個(gè) Slot 中。

有一些客戶端(如 Redisson)實(shí)現(xiàn)了集群化的 Pipelining 操作，可以自動(dòng)將一個(gè) Pipeline 里的命令按 Key 所在的分片進(jìn)行分組，分別發(fā)到不同的分片上執(zhí)行。

但是 Redis 不支持跨分片的事務(wù)，事務(wù)和 LUA Script 還是必須遵循所有 Key 在一個(gè)分片上的規(guī)則要求。

主從復(fù)制 VS 集群分片

在設(shè)計(jì)軟件架構(gòu)時(shí)，要如何在主從復(fù)制和集群分片兩種部署方案中取舍呢?從各個(gè)方面看，Redis Cluster 都是優(yōu)于主從復(fù)制的方案：

Redis Cluster 能夠解決單節(jié)點(diǎn)上數(shù)據(jù)量過(guò)大的問(wèn)題。
Redis Cluster 能夠解決單節(jié)點(diǎn)訪問(wèn)壓力過(guò)大的問(wèn)題。
Redis Cluster 包含了主從復(fù)制的能力。

那是不是代表 Redis Cluster 永遠(yuǎn)是優(yōu)于主從復(fù)制的選擇呢?并不是。軟件架構(gòu)永遠(yuǎn)不是越復(fù)雜越好，復(fù)雜的架構(gòu)在帶來(lái)顯著好處的同時(shí)，一定也會(huì)帶來(lái)相應(yīng)的弊端。

采用 Redis Cluster 的弊端包括：

維護(hù)難度增加。在使用 Redis Cluster 時(shí)，需要維護(hù)的 Redis 實(shí)例數(shù)倍增，需要監(jiān)控的主機(jī)數(shù)量也相應(yīng)增加，數(shù)據(jù)備份/持久化的復(fù)雜度也會(huì)增加。

同時(shí)在進(jìn)行分片的增減操作時(shí)，還需要進(jìn)行 Reshard 操作，遠(yuǎn)比主從模式下增加一個(gè) Slave 的復(fù)雜度要高。

客戶端資源消耗增加。當(dāng)客戶端使用連接池時(shí)，需要為每一個(gè)數(shù)據(jù)分片維護(hù)一個(gè)連接池，客戶端同時(shí)需要保持的連接數(shù)成倍增多，加大了客戶端本身和操作系統(tǒng)資源的消耗。
性能優(yōu)化難度增加。你可能需要在多個(gè)分片上查看 Slow Log 和 Swap 日志才能定位性能問(wèn)題。
事務(wù)和 LUA Script 的使用成本增加。在 Redis Cluster 中使用事務(wù)和 LUA Script 特性有嚴(yán)格的限制條件，事務(wù)和 Script 中操作的 Key 必須位于同一個(gè)分片上。

這就使得在開(kāi)發(fā)時(shí)必須對(duì)相應(yīng)場(chǎng)景下涉及的 Key 進(jìn)行額外的規(guī)劃和規(guī)范要求。如果應(yīng)用的場(chǎng)景中大量涉及事務(wù)和 Script 的使用，如何在保證這兩個(gè)功能的正常運(yùn)作前提下把數(shù)據(jù)平均分到多個(gè)數(shù)據(jù)分片中就會(huì)成為難點(diǎn)。

所以說(shuō)，在主從復(fù)制和集群分片兩個(gè)方案中做出選擇時(shí)，應(yīng)該從應(yīng)用軟件的功能特性、數(shù)據(jù)和訪問(wèn)量級(jí)、未來(lái)發(fā)展規(guī)劃等方面綜合考慮，只在確實(shí)有必要引入數(shù)據(jù)分片時(shí)再使用 Redis Cluster。

下面是一些建議：

需要在 Redis 中存儲(chǔ)的數(shù)據(jù)有多大?未來(lái) 2 年內(nèi)可能發(fā)展為多大?這些數(shù)據(jù)是否都需要長(zhǎng)期保存?是否可以使用 LRU 算法進(jìn)行非熱點(diǎn)數(shù)據(jù)的淘汰?綜合考慮前面幾個(gè)因素，評(píng)估出 Redis 需要使用的物理內(nèi)存。
用于部署 Redis 的主機(jī)物理內(nèi)存有多大?有多少可以分配給 Redis 使用?對(duì)比 (1) 中的內(nèi)存需求評(píng)估，是否足夠用?
Redis 面臨的并發(fā)寫(xiě)壓力會(huì)有多大?在不使用 Pipelining 時(shí)，Redis 的寫(xiě)性能可以超過(guò) 10 萬(wàn)次/秒(更多的 Benchmark 可以參考 https://redis.io/topics/benchmarks )。
在使用 Redis 時(shí)，是否會(huì)使用到 Pipelining 和事務(wù)功能?使用的場(chǎng)景多不多?

綜合上面幾點(diǎn)考慮，如果單臺(tái)主機(jī)的可用物理內(nèi)存完全足以支撐對(duì) Redis 的容量需求，且 Redis 面臨的并發(fā)寫(xiě)壓力距離 Benchmark 值還尚有距離，建議采用主從復(fù)制的架構(gòu)，可以省去很多不必要的麻煩。

同時(shí)，如果應(yīng)用中大量使用 Pipelining 和事務(wù)，也建議盡可能選擇主從復(fù)制架構(gòu)，可以減少設(shè)計(jì)和開(kāi)發(fā)時(shí)的復(fù)雜度。

Redis Java 客戶端的選擇

Redis 的 Java 客戶端很多，官方推薦的有三種：

Jedis
Redisson
Lettuce

在這里對(duì) Jedis 和 Redisson 進(jìn)行對(duì)比介紹。

Jedis：

輕量，簡(jiǎn)潔，便于集成和改造。
支持連接池。
支持 Pipelining、事務(wù)、LUA Scripting、Redis Sentinel、Redis Cluster。
不支持讀寫(xiě)分離，需要自己實(shí)現(xiàn)。
文檔差(真的很差，幾乎沒(méi)有……)。

Redisson：

基于 Netty 實(shí)現(xiàn)，采用非阻塞 IO，性能高。
支持異步請(qǐng)求。
支持連接池。
支持 Pipelining、LUA Scripting、Redis Sentinel、Redis Cluster。
不支持事務(wù)，官方建議以 LUA Scripting 代替事務(wù)。
支持在 Redis Cluster 架構(gòu)下使用 Pipelining。
支持讀寫(xiě)分離，支持讀負(fù)載均衡，在主從復(fù)制和 Redis Cluster 架構(gòu)下都可以使用。
內(nèi)建 Tomcat Session Manager，為 Tomcat 6/7/8 提供了會(huì)話共享功能。
可以與 Spring Session 集成，實(shí)現(xiàn)基于 Redis 的會(huì)話共享。
文檔較豐富，有中文文檔。

對(duì)于 Jedis 和 Redisson 的選擇，同樣應(yīng)遵循前述的原理，盡管 Jedis 比起 Redisson 有各種各樣的不足，但也應(yīng)該在需要使用 Redisson 的高級(jí)特性時(shí)再選用 Redisson，避免造成不必要的程序復(fù)雜度提升。

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

本文名稱：一文搞定Redis高級(jí)特性與性能調(diào)優(yōu)
鏈接地址：http://m.fisionsoft.com.cn/article/dphcdeo.html

新聞中心

其他資訊