Redis 性能優(yōu)化思路，寫(xiě)的非常好！
你知道的越多，不知道的就越多，業(yè)余的像一棵小草！
你來(lái)，我們一起精進(jìn)！你不來(lái)，我和你的競(jìng)爭(zhēng)對(duì)手一起精進(jìn)！
編輯：業(yè)余草
juejin.cn/post/6948034657321484318
推薦：https://www.xttblog.com/?p=5182
在一些網(wǎng)絡(luò)服務(wù)的系統(tǒng)中，Redis 的性能，可能是比 MySQL 等硬盤數(shù)據(jù)庫(kù)的性能更重要的課題。比如微博，把熱點(diǎn)微博[1]，最新的用戶關(guān)系，都存儲(chǔ)在 Redis 中，大量的查詢擊中 Redis，而不走 MySQL。
那么，針對(duì) Redis 服務(wù)，我們能做哪些性能優(yōu)化呢？或者說(shuō)，應(yīng)該避免哪些性能浪費(fèi)呢？
Redis 性能的基本面
在討論優(yōu)化之前，我們需要知道，Redis 服務(wù)本身就有一些特性，比如單線程運(yùn)行。除非修改 Redis 的源代碼，不然這些特性，就是我們思考性能優(yōu)化的基本面。
那么，有哪些 Redis 基本特性需要我們考慮呢？Redis 的項(xiàng)目介紹中概括了它特性：
Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported.
首先，Redis 使用操作系統(tǒng)提供的虛擬內(nèi)存來(lái)存儲(chǔ)數(shù)據(jù)。而且，這個(gè)操作系統(tǒng)一般就是指 Unix。Windows 上也能運(yùn)行 Redis，但是需要特殊處理。如果你的操作系統(tǒng)使用交換空間，那么 Redis 的數(shù)據(jù)可能會(huì)被實(shí)際保存在硬盤上。
其次，Redis 支持持久化，可以把數(shù)據(jù)保存在硬盤上。很多時(shí)候，我們也確實(shí)有必要進(jìn)行持久化來(lái)實(shí)現(xiàn)備份，數(shù)據(jù)恢復(fù)等需求。但持久化不會(huì)憑空發(fā)生，它也會(huì)占用一部分資源。
第三，Redis 是用 key-value 的方式來(lái)讀寫(xiě)的，而 value 中又可以是很多不同種類的數(shù)據(jù)；更進(jìn)一步，一個(gè)數(shù)據(jù)類型的底層還有被存儲(chǔ)為不同的結(jié)構(gòu)。不同的存儲(chǔ)結(jié)構(gòu)決定了數(shù)據(jù)增刪改查的復(fù)雜度以及性能開(kāi)銷。
最后，在上面的介紹中沒(méi)有提到的是，Redis 大多數(shù)時(shí)候是單線程運(yùn)行[2]的（single-threaded)，即同一時(shí)間只占用一個(gè) CPU，只能有一個(gè)指令在運(yùn)行，并行讀寫(xiě)是不存在的。很多操作帶來(lái)的延遲問(wèn)題，都可以在這里找到答案。
關(guān)于最后這個(gè)特性，為什么 Redis 是單線程的，卻能有很好的性能(根據(jù) Amdahl’s Law，優(yōu)化耗時(shí)占比大的過(guò)程，才更有意義)，兩句話概括是：Redis 利用了多路 I/O 復(fù)用機(jī)制[3]，處理客戶端請(qǐng)求時(shí)，不會(huì)阻塞主線程；Redis 單純執(zhí)行（大多數(shù)指令）一個(gè)指令不到 1 微秒[4]，如此，單核 CPU 一秒就能處理 1 百萬(wàn)個(gè)指令（大概對(duì)應(yīng)著幾十萬(wàn)個(gè)請(qǐng)求吧），用不著實(shí)現(xiàn)多線程（網(wǎng)絡(luò)才是瓶頸[5]）。
優(yōu)化網(wǎng)絡(luò)延時(shí)
Redis 的官方博客在幾個(gè)地方都說(shuō)，性能瓶頸更可能是網(wǎng)絡(luò)[6]，那么我們?nèi)绾蝺?yōu)化網(wǎng)絡(luò)上的延時(shí)呢？另外，關(guān)注公眾號(hào)互聯(lián)網(wǎng)架構(gòu)師，在后臺(tái)回復(fù)：2T，可以獲取我整理的 Redis 系列面試題和答案，非常齊全。
首先，如果你們使用單機(jī)部署（應(yīng)用服務(wù)和 Redis 在同一臺(tái)機(jī)器上）的話，使用 Unix 進(jìn)程間通訊來(lái)請(qǐng)求 Redis 服務(wù)，速度比 localhost 局域網(wǎng)（學(xué)名 loopback）更快。官方文檔[7]是這么說(shuō)的，想一想，理論上也應(yīng)該是這樣的。
但很多公司的業(yè)務(wù)規(guī)模不是單機(jī)部署能支撐的，所以還是得用 TCP。
Redis 客戶端和服務(wù)器的通訊一般使用 TCP 長(zhǎng)鏈接。如果客戶端發(fā)送請(qǐng)求后需要等待 Redis 返回結(jié)果再發(fā)送下一個(gè)指令，客戶端和 Redis 的多個(gè)請(qǐng)求就構(gòu)成下面的關(guān)系：
但如果有可能，完全可以使用 multi-key 類的指令來(lái)合并請(qǐng)求，比如兩個(gè) GET key 可以用 MGET key1 key2 合并。這樣在實(shí)際通訊中，請(qǐng)求數(shù)也減少了，延時(shí)自然得到好轉(zhuǎn)。
如果不能用 multi-key 指令來(lái)合并，比如一個(gè) SET，一個(gè) GET 無(wú)法合并。怎么辦？
Redis 中有至少這樣兩個(gè)方法能合并多個(gè)指令到一個(gè) request 中，一個(gè)是 MULTI/EXEC，一個(gè)是 script。前者本來(lái)是構(gòu)建 Redis 事務(wù)的方法，但確實(shí)可以合并多個(gè)指令為一個(gè) request，它到通訊過(guò)程如下。至于 script，最好利用緩存腳本的 sha1 hash key 來(lái)調(diào)起腳本，這樣通訊量更小。
require 'redis'
@redis = Redis.new()
@redis.pipelined do
@redis.get 'key1'
@redis.set 'key2' 'some value'
end
# => [1, 2]據(jù)說(shuō)，有些語(yǔ)言的客戶端，甚至默認(rèn)就使用 pipeline 來(lái)優(yōu)化延時(shí)問(wèn)題，比如 node_redis。
另外，不是任意多個(gè)回復(fù)信息都可以放進(jìn)一個(gè) TCP 包中，如果請(qǐng)求數(shù)太多，回復(fù)的數(shù)據(jù)很長(zhǎng)（比如 get 一個(gè)長(zhǎng)字符串），TCP 還是會(huì)分包傳輸，但使用 pipeline，依然可以減少傳輸次數(shù)。
pipeline 和上面的其他方法都不一樣的是，它不具有原子性。所以在 cluster 狀態(tài)下的集群上，實(shí)現(xiàn) pipeline 比那些原子性的方法更有可能。
使用 unix 進(jìn)程間通信，如果單機(jī)部署 使用 multi-key 指令合并多個(gè)指令，減少請(qǐng)求數(shù)，如果有可能的話 使用 transaction、script 合并 requests 以及 responses 使用 pipeline 合并 response
警惕執(zhí)行時(shí)間長(zhǎng)的操作
在大數(shù)據(jù)量的情況下，有些操作的執(zhí)行時(shí)間會(huì)相對(duì)長(zhǎng)，比如 KEYS *，LRANGE mylist 0 -1，以及其他算法復(fù)雜度為 O(n) 的指令。因?yàn)?Redis 只用一個(gè)線程來(lái)做數(shù)據(jù)查詢，如果這些指令耗時(shí)很長(zhǎng)，就會(huì)阻塞 Redis，造成大量延時(shí)。
盡管官方文檔中說(shuō) KEYS * 的查詢挺快的，（在普通筆記本上）掃描 1 百萬(wàn)個(gè) key，只需 40 毫秒(參見(jiàn)：https://redis.io/commands/keys)，但幾十 ms 對(duì)于一個(gè)性能要求很高的系統(tǒng)來(lái)說(shuō)，已經(jīng)不短了，更何況如果有幾億個(gè) key（一臺(tái)機(jī)器完全可能存幾億個(gè) key，比如一個(gè) key 100字節(jié)，1 億個(gè) key 只有 10GB），時(shí)間更長(zhǎng)。
所以，盡量不要在生產(chǎn)環(huán)境的代碼使用這些執(zhí)行很慢的指令，這一點(diǎn) Redis 的作者在博客[8]中也提到了。另外，運(yùn)維同學(xué)查詢 Redis 的時(shí)候也盡量不要用。甚至，Redis Essential 這本書(shū)建議利用 rename-command KEYS '' 來(lái)禁止使用這個(gè)耗時(shí)的指令。
除了這些耗時(shí)的指令，Redis 中 transaction，script，因?yàn)榭梢院喜⒍鄠€(gè) commands 為一個(gè)具有原子性的執(zhí)行過(guò)程，所以也可能占用 Redis 很長(zhǎng)時(shí)間，需要注意。
如果你想找出生產(chǎn)環(huán)境使用的「慢指令」，那么可以利用 SLOWLOG GET count 來(lái)查看最近的 count 個(gè)執(zhí)行時(shí)間很長(zhǎng)的指令。至于多長(zhǎng)算長(zhǎng)，可以通過(guò)在 redis.conf 中設(shè)置 slowlog-log-slower-than 來(lái)定義。
除此之外，在很多地方都沒(méi)有提到的一個(gè)可能的慢指令是 DEL，但 redis.conf 文件的注釋[9]中倒是說(shuō)了。長(zhǎng)話短說(shuō)就是 DEL 一個(gè)大的 object 時(shí)候，回收相應(yīng)的內(nèi)存可能會(huì)需要很長(zhǎng)時(shí)間（甚至幾秒），所以，建議用 DEL 的異步版本：UNLINK。后者會(huì)啟動(dòng)一個(gè)新的 thread 來(lái)刪除目標(biāo) key，而不阻塞原來(lái)的線程。
更進(jìn)一步，當(dāng)一個(gè) key 過(guò)期之后，Redis 一般也需要同步的把它刪除。其中一種刪除 keys 的方式是，每秒 10 次的檢查一次有設(shè)置過(guò)期時(shí)間的 keys，這些 keys 存儲(chǔ)在一個(gè)全局的 struct 中，可以用 server.db->expires 訪問(wèn)。
檢查的方式是：
從中隨機(jī)取出 20 個(gè) keys 把過(guò)期的刪掉。 如果剛剛 20 個(gè) keys 中，有 25% 以上（也就是 5 個(gè)以上）都是過(guò)期的，Redis 認(rèn)為，過(guò)期的 keys 還挺多的，繼續(xù)重復(fù)步驟 1，直到滿足退出條件：某次取出的 keys 中沒(méi)有那么多過(guò)去的 keys。
這里對(duì)于性能的影響是，如果真的有很多的 keys 在同一時(shí)間過(guò)期，那么 Redis 真的會(huì)一直循環(huán)執(zhí)行刪除，占用主線程。
EXPIREAT 這個(gè)指令，因?yàn)樗菀桩a(chǎn)生 keys 同時(shí)過(guò)期的現(xiàn)象。我還見(jiàn)到過(guò)一些建議是給 keys 的過(guò)期時(shí)間設(shè)置一個(gè)隨機(jī)波動(dòng)量。最后，redis.conf 中也給出了一個(gè)方法，把 keys 的過(guò)期刪除操作變?yōu)楫惒降?，即，?redis.conf 中設(shè)置 lazyfree-lazy-expire yes。優(yōu)化數(shù)據(jù)結(jié)構(gòu)、使用正確的算法
我們?cè)谑褂靡环N數(shù)據(jù)類型時(shí)，可以適當(dāng)關(guān)注一下它底層的存儲(chǔ)結(jié)構(gòu)及其算法，避免使用復(fù)雜度太高的方法。
ZADD的時(shí)間復(fù)雜度是 O(log(N))，這比其他數(shù)據(jù)類型增加一個(gè)新元素的操作更復(fù)雜，所以要小心使用。若 Hash 類型的值的 fields 數(shù)量有限，它很有可能采用 ziplist 這種結(jié)構(gòu)做存儲(chǔ)，而 ziplist 的查詢效率可能沒(méi)有同等字段數(shù)量的 hashtable 效率高，在必要時(shí)，可以調(diào)整 Redis 的存儲(chǔ)結(jié)構(gòu)。
除了時(shí)間性能上的考慮，有時(shí)候我們還需要節(jié)省存儲(chǔ)空間。比如上面提到的 ziplist 結(jié)構(gòu)，就比 hashtable 結(jié)構(gòu)節(jié)省存儲(chǔ)空間（Redis Essentials 的作者分別在 hashtable 和 ziplist 結(jié)構(gòu)的 Hash 中插入 500 個(gè) fields，每個(gè) field 和 value 都是一個(gè) 15 位左右的字符串，結(jié)果是 hashtable 結(jié)構(gòu)使用的空間是 ziplist 的 4 倍。）。但節(jié)省空間的數(shù)據(jù)結(jié)構(gòu)，其算法的復(fù)雜度可能很高。所以，這里就需要在具體問(wèn)題面前做出權(quán)衡。
如何做出更好的權(quán)衡？我覺(jué)得得深挖 Redis 的存儲(chǔ)結(jié)構(gòu)才能讓自己安心。這方面的內(nèi)容我們下次再說(shuō)。
以上這三點(diǎn)都是編程層面的考慮，寫(xiě)程序時(shí)應(yīng)該注意啊。下面這幾點(diǎn)，也會(huì)影響 Redis 的性能，但解決起來(lái)，就不只是靠代碼層面的調(diào)整了，還需要架構(gòu)和運(yùn)維上的考慮。
考慮操作系統(tǒng)和硬件是否影響性能
CPU：Intel 多種 CPU 都比 AMD 皓龍系列好 虛擬化：實(shí)體機(jī)比虛擬機(jī)好，主要是因?yàn)椴糠痔摂M機(jī)上，硬盤不是本地硬盤，監(jiān)控軟件導(dǎo)致 fork 指令的速度慢（持久化時(shí)會(huì)用到 fork），尤其是用 Xen 來(lái)做虛擬化時(shí)。 內(nèi)存管理：在 linux 操作系統(tǒng)中，為了讓 translation lookaside buffer，即 TLB，能夠管理更多內(nèi)存空間（TLB 只能緩存有限個(gè) page），操作系統(tǒng)把一些 memory page 變得更大，比如 2MB 或者 1GB，而不是通常的 4096 字節(jié)，這些大的內(nèi)存頁(yè)叫做 huge pages。同時(shí)，為了方便程序員使用這些大的內(nèi)存 page，操作系統(tǒng)中實(shí)現(xiàn)了一個(gè) transparent huge pages（THP）機(jī)制，使得大內(nèi)存頁(yè)對(duì)他們來(lái)說(shuō)是透明的，可以像使用正常的內(nèi)存 page 一樣使用他們。但這種機(jī)制并不是數(shù)據(jù)庫(kù)所需要的，可能是因?yàn)?THP 會(huì)把內(nèi)存空間變得緊湊而連續(xù)吧，就像mongodb 的文檔[11]中明確說(shuō)的，數(shù)據(jù)庫(kù)需要的是稀疏的內(nèi)存空間，所以請(qǐng)禁掉 THP 功能。Redis 也不例外，但 Redis 官方博客上給出的理由是：使用大內(nèi)存 page 會(huì)使 bgsave 時(shí)，fork 的速度變慢；如果 fork 之后，這些內(nèi)存 page 在原進(jìn)程中被修改了，他們就需要被復(fù)制（即 copy on write），這樣的復(fù)制會(huì)消耗大量的內(nèi)存（畢竟，人家是 huge pages，復(fù)制一份消耗成本很大）。所以，請(qǐng)禁止掉操作系統(tǒng)中的 transparent huge pages 功能。 交換空間：當(dāng)一些內(nèi)存 page 被存儲(chǔ)在交換空間文件上，而 Redis 又要請(qǐng)求那些數(shù)據(jù)，那么操作系統(tǒng)會(huì)阻塞 Redis 進(jìn)程，然后把想要的 page，從交換空間中拿出來(lái)，放進(jìn)內(nèi)存。這其中涉及整個(gè)進(jìn)程的阻塞，所以可能會(huì)造成延時(shí)問(wèn)題，一個(gè)解決方法是禁止使用交換空間（Redis Essentials 中如是建議，如果內(nèi)存空間不足，請(qǐng)用別的方法處理）。
考慮持久化帶來(lái)的開(kāi)銷
Redis 的一項(xiàng)重要功能就是持久化，也就是把數(shù)據(jù)復(fù)制到硬盤上?；诔志没?，才有了 Redis 的數(shù)據(jù)恢復(fù)等功能。
但維護(hù)這個(gè)持久化的功能，也是有性能開(kāi)銷的。
首先說(shuō)，RDB 全量持久化。
這種持久化方式把 Redis 中的全量數(shù)據(jù)打包成 rdb 文件放在硬盤上。但是執(zhí)行 RDB 持久化過(guò)程的是原進(jìn)程 fork 出來(lái)一個(gè)子進(jìn)程，而 fork 這個(gè)系統(tǒng)調(diào)用是需要時(shí)間的，根據(jù)Redis Lab 6 年前做的實(shí)驗(yàn)[12]，在一臺(tái)新型的 AWS EC2 m1.small^13 上，fork 一個(gè)內(nèi)存占用 1GB 的 Redis 進(jìn)程，需要 700+ 毫秒，而這段時(shí)間，redis 是無(wú)法處理請(qǐng)求的。
雖然現(xiàn)在的機(jī)器應(yīng)該都會(huì)比那個(gè)時(shí)候好，但是 fork 的開(kāi)銷也應(yīng)該考慮吧。為此，要使用合理的 RDB 持久化的時(shí)間間隔，不要太頻繁。
接下來(lái)，我們看另外一種持久化方式：AOF 增量持久化。
這種持久化方式會(huì)把你發(fā)到 redis server 的指令以文本的形式保存下來(lái)（格式遵循 redis protocol），這個(gè)過(guò)程中，會(huì)調(diào)用兩個(gè)系統(tǒng)調(diào)用，一個(gè)是 write(2)，同步完成，一個(gè)是 fsync(2)，異步完成。
write 可能會(huì)因?yàn)檩敵龅?buffer 滿了，或者 kernal 正在把 buffer 中的數(shù)據(jù)同步到硬盤，就被阻塞了。
fsync 的作用是確保 write 寫(xiě)入到 aof 文件的數(shù)據(jù)落到了硬盤上，在一個(gè) 7200 轉(zhuǎn)/分的硬盤上可能要延時(shí) 20 毫秒左右，消耗還是挺大的。更重要的是，在 fsync 進(jìn)行的時(shí)候，write 可能會(huì)被阻塞。
其中，write 的阻塞貌似只能接受，因?yàn)闆](méi)有更好的方法把數(shù)據(jù)寫(xiě)到一個(gè)文件中了。但對(duì)于 fsync，Redis 允許三種配置，選用哪種取決于你對(duì)備份及時(shí)性和性能的平衡：
always：當(dāng)把 appendfsync 設(shè)置為 always，fsync 會(huì)和客戶端的指令同步執(zhí)行，因此最可能造成延時(shí)問(wèn)題，但備份及時(shí)性最好。 everysec：每秒鐘異步執(zhí)行一次 fsync，此時(shí) redis 的性能表現(xiàn)會(huì)更好，但是 fsync 依然可能阻塞 write，算是一個(gè)折中選擇。 no：redis 不會(huì)主動(dòng)出發(fā) fsync （并不是永遠(yuǎn)不 fsync，那是不太可能的），而由 kernel 決定何時(shí) fsync
使用分布式架構(gòu) —— 讀寫(xiě)分離、數(shù)據(jù)分片
以上，我們都是基于單臺(tái)，或者單個(gè) Redis 服務(wù)進(jìn)行優(yōu)化。下面，我們考慮當(dāng)網(wǎng)站的規(guī)模變大時(shí)，利用分布式架構(gòu)來(lái)保障 Redis 性能的問(wèn)題。
數(shù)據(jù)量很大，單臺(tái)服務(wù)器內(nèi)存不可能裝得下，比如 1 個(gè) T 這種量級(jí)
需要服務(wù)高可用
單臺(tái)的請(qǐng)求壓力過(guò)大
解決這些問(wèn)題可以采用數(shù)據(jù)分片或者主從分離，或者兩者都用（即，在分片用的 cluster 節(jié)點(diǎn)上，也設(shè)置主從結(jié)構(gòu)）。
把慢速的指令發(fā)到某些從庫(kù)中執(zhí)行 把持久化功能放在一個(gè)很少使用的從庫(kù)上 把某些大 list 分片
其中前兩條都是根據(jù) Redis 單線程的特性，用其他進(jìn)程（甚至機(jī)器）做性能補(bǔ)充的方法。
當(dāng)然，使用分布式架構(gòu)，也可能對(duì)性能有影響，比如請(qǐng)求需要被轉(zhuǎn)發(fā)，數(shù)據(jù)需要被不斷復(fù)制分發(fā)等。
后話
其實(shí)還有很多東西也影響 Redis 的性能，比如 active rehashing（keys 主表的再哈希，每秒 10 次，關(guān)掉它可以提升一點(diǎn)點(diǎn)性能），但是這篇博客已經(jīng)寫(xiě)的很長(zhǎng)了。而且，更重要不是收集已經(jīng)被別人提出的問(wèn)題，然后記憶解決方案；而是掌握 Redis 的基本原理，以不變應(yīng)萬(wàn)變的方式?jīng)Q絕新出現(xiàn)的問(wèn)題。