來源：www.jianshu.com/p/67093716547b

在一些網(wǎng)絡(luò)服務(wù)的系統(tǒng)中，Redis 的性能，可能是比 MySQL 等硬盤數(shù)據(jù)庫的性能更重要的課題。比如微博，把熱點(diǎn)微博［1］，最新的用戶關(guān)系［2］，都存儲(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)行［2］的（single-threaded），即同一時(shí)間只占用一個(gè) CPU，只能有一個(gè)指令在運(yùn)行，并行讀寫是不存在的。很多操作帶來的延遲問題，都可以在這里找到答案。

關(guān)于最后這個(gè)特性，為什么 Redis 是單線程的，卻能有很好的性能（根據(jù) Amdahl’s Law，優(yōu)化耗時(shí)占比大的過程，才更有意義），兩句話概括是：Redis 利用了多路 I/O 復(fù)用機(jī)制［3］，處理客戶端請(qǐng)求時(shí)，不會(huì)阻塞主線程；Redis 單純執(zhí)行（大多數(shù)指令）一個(gè)指令不到 1 微秒［4］，如此，單核 CPU 一秒就能處理 1 百萬個(gè)指令（大概對(duì)應(yīng)著幾十萬個(gè)請(qǐng)求吧），用不著實(shí)現(xiàn)多線程（網(wǎng)絡(luò)才是瓶頸［5］）。

優(yōu)化網(wǎng)絡(luò)延時(shí)

Redis 的官方博客在幾個(gè)地方都說，性能瓶頸更可能是網(wǎng)絡(luò)［6］，那么我們?nèi)绾蝺?yōu)化網(wǎng)絡(luò)上的延時(shí)呢？

首先，如果你們使用單機(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)萬變的方式杜絕新出現(xiàn)的問題。

責(zé)任編輯：haq