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