前言

Redis作為高性能的內(nèi)存數(shù)據(jù)庫，在大數(shù)據(jù)量的情況下也會遇到性能瓶頸，日常開發(fā)中只有時刻謹記優(yōu)化鐵則，才能使得Redis性能發(fā)揮到極致。

本文將會介紹十三條性能優(yōu)化軍規(guī)，開發(fā)過程中只要按照執(zhí)行，性能必能質(zhì)的飛躍。

1. 避免慢查詢命令

慢查詢命令指的是執(zhí)行較慢的命令，Redis自身提供了許多的命令，并不是所有的命令都慢，這和命令的操作復雜度有關，因此必須知道Redis不同命令的復雜度。

如說，Value 類型為 String 時，GET/SET 操作主要就是操作 Redis 的哈希表索引。這個操作復雜度基本是固定的，即 O(1)。但是，當 Value 類型為 Set 時，SORT、SUNION/SMEMBERS 操作復雜度分別為 O(N+M*log(M)) 和 O(N)。其中，N 為 Set 中的元素個數(shù)，M 為 SORT 操作返回的元素個數(shù)。這個復雜度就增加了很多。Redis 官方文檔中對每個命令的復雜度都有介紹，當你需要了解某個命令的復雜度時，可以直接查詢。

當你發(fā)現(xiàn) Redis 性能變慢時，可以通過 Redis 日志，或者是 latency monitor 工具，查詢變慢的請求，根據(jù)請求對應的具體命令以及官方文檔，確認下是否采用了復雜度高的慢查詢命令。

如果確實存在大量的慢查詢命令，建議如下兩種方式：

1. 用其他高效的命令代替：比如說，如果你需要返回一個 SET 中的所有成員時，不要使用 SMEMBERS 命令，而是要使用 SSCAN 多次迭代返回，避免一次返回大量數(shù)據(jù)，造成線程阻塞。

2. 當你需要執(zhí)行排序、交集、并集操作時，可以在客戶端完成，而不要用 SORT、SUNION、SINTER 這些命令，以免拖慢 Redis 實例。

2. 生產(chǎn)環(huán)境禁用keys命令

keys這個命令是最容易忽略的慢查詢命令，因為keys命令需要遍歷存儲的鍵值對，所以操作延時很高，在生產(chǎn)環(huán)境使用很可能導致Redis阻塞；因此不建議在生產(chǎn)環(huán)境中使用keys命令。

3. keys需要設置過期時間

Redis作為內(nèi)存數(shù)據(jù)庫，一切的數(shù)據(jù)都是在內(nèi)存中，一旦內(nèi)存占用過大則會大大影響性能，因此需要對有時間限制的數(shù)據(jù)需要設置過期時間，這樣Redis能夠定時的刪除過期的數(shù)據(jù)。

4. 禁止批量的給keys設置相同的過期時間

默認情況下，Redis 每 100 毫秒會刪除一些過期 key，具體的算法如下：

1. 采樣 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 個數(shù)的 key，并將其中過期的 key 全部刪除；
2. 如果超過 25% 的 key 過期了，則重復刪除的過程，直到過期 key 的比例降至 `25%`` 以下。

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 是 Redis 的一個參數(shù)，默認是 20，那么，一秒內(nèi)基本有 200 個過期 key 會被刪除。這一策略對清除過期 key、釋放內(nèi)存空間很有幫助。如果每秒鐘刪除 200 個過期 key，并不會對 Redis 造成太大影響。

但是，如果觸發(fā)了上面這個算法的第二條，Redis 就會一直刪除以釋放內(nèi)存空間。注意，刪除操作是阻塞的（Redis 4.0 后可以用異步線程機制來減少阻塞影響）。所以，一旦該條件觸發(fā)，Redis 的線程就會一直執(zhí)行刪除，這樣一來，就沒辦法正常服務其他的鍵值操作了，就會進一步引起其他鍵值操作的延遲增加，Redis 就會變慢。

頻繁使用帶有相同時間參數(shù)的 EXPIREAT 命令設置過期 key 將會觸發(fā)算法第二條，這就會導致在一秒內(nèi)存在大量的keys過期。

因此開發(fā)中一定要禁止批量的給keys設置過期時間。

5. 謹慎選擇數(shù)據(jù)結構

Redis 常用的數(shù)據(jù)結構一共有五種：string、hash、list、set、zset（sorted set）。可以發(fā)現(xiàn)，大多數(shù)場景下使用 string 都可以去解決問題。但是，這并不一定是最優(yōu)的選擇。下面，簡單說明下它們各自的適用場景：

1. string：單個的緩存結果，不與其他的 KV 之間有聯(lián)系
2. hash：一個 Object 包含有很多屬性，且這些屬性都需要單獨存儲。注意：這種情況不要使用 string，因為 string 會占據(jù)更多的內(nèi)存
3. list：一個 Object 包含很多數(shù)據(jù)，且這些數(shù)據(jù)允許重復、要求有順序性
4. set：一個 Object 包含很多數(shù)據(jù)，不要求數(shù)據(jù)有順序，但是不允許重復
5. zset：一個 Object 包含很多數(shù)據(jù)，且這些數(shù)據(jù)自身還包含一個權重值，可以利用這個權重值來排序

另外Redis還提供了幾種的擴展類型，如下：

1. HyperLogLog：適合用于 基數(shù)統(tǒng)計，比如PV，UV的統(tǒng)計，存在 誤差問題，不適合精確統(tǒng)計。
2. BitMap：適合 二值狀態(tài)的統(tǒng)計，比如簽到打卡，要么打卡了，要么未打卡。

6. 檢查持久化策略

Redis4.0之后使用了如下三種持久化策略：

1. AOF日志：一種采用文件追加的方式將命令記錄在日志中的策略，針對同步和異步追加還提供了三個配置項，有興趣的可以查看官方文檔。
2. RDB快照：以快照的方式，將某一個時刻的內(nèi)存數(shù)據(jù)，以二進制的方式寫入磁盤。
3. AOF和 RDB混用：Redis4.0新增的方式，為了采用兩種方式各自的優(yōu)點，在RDB快照的時間段內(nèi)使用的AOF日志記錄這段時間的操作的命令，這樣一旦發(fā)生宕機，將不會丟失兩段快照中間的數(shù)據(jù)。

由于寫入磁盤有IO性能瓶頸，因此不是將Redis作為數(shù)據(jù)庫的話（可以從后端恢復），建議禁用持久化或者調(diào)整持久化策略。

7. 采用高速的固態(tài)硬盤作為日志寫入設備

由于AOF日志的重寫對磁盤的壓力較大，很可能會阻塞，如果需要使用到持久化，建議使用高速的固態(tài)硬盤作為日志寫入設備。

8. 使用物理機而非虛擬機

由于虛擬機增加了虛擬化軟件層，與物理機相比，虛擬機本身就存在性能的開銷，可以使用如下命令來分別測試下物理機和虛擬機的基線性能：

./redis-cli?--intrinsic-latency?120

測試結果可以知道，使用物理機的基線性能明顯比虛擬機的基線性能更好。

9. 增加機器內(nèi)存或者使用Redis集群

物理機器的內(nèi)存不足將會導致操作系統(tǒng)內(nèi)存的Swap。

內(nèi)存 swap 是操作系統(tǒng)里將內(nèi)存數(shù)據(jù)在內(nèi)存和磁盤間來回換入和換出的機制，涉及到磁盤的讀寫，所以，一旦觸發(fā) swap，無論是被換入數(shù)據(jù)的進程，還是被換出數(shù)據(jù)的進程，其性能都會受到慢速磁盤讀寫的影響。

Redis 是內(nèi)存數(shù)據(jù)庫，內(nèi)存使用量大，如果沒有控制好內(nèi)存的使用量，或者和其他內(nèi)存需求大的應用一起運行了，就可能受到 swap 的影響，而導致性能變慢。

這一點對于 Redis 內(nèi)存數(shù)據(jù)庫而言，顯得更為重要：正常情況下，Redis 的操作是直接通過訪問內(nèi)存就能完成，一旦 swap 被觸發(fā)了，Redis 的請求操作需要等到磁盤數(shù)據(jù)讀寫完成才行。而且，和我剛才說的 AOF 日志文件讀寫使用 fsync 線程不同，swap 觸發(fā)后影響的是 Redis 主 IO 線程，這會極大地增加 Redis 的響應時間。

因此增加機器的內(nèi)存或者使用Redis集群能夠有效的解決操作系統(tǒng)內(nèi)存的Swap，提高性能。

10. 使用 Pipeline 批量操作數(shù)據(jù)

Pipeline (管道技術) 是客戶端提供的一種批處理技術，用于一次處理多個 Redis 命令，從而提高整個交互的性能。

11. 客戶端使用優(yōu)化

在客戶端的使用上我們除了要盡量使用 Pipeline 的技術外，還需要注意要盡量使用 Redis 連接池，而不是頻繁創(chuàng)建銷毀 Redis 連接，這樣就可以減少網(wǎng)絡傳輸次數(shù)和減少了非必要調(diào)用指令。

12. 使用分布式架構來增加讀寫速度

Redis 分布式架構有三個重要的手段：

1. 主從同步
2. 哨兵模式
3. Redis Cluster 集群

使用主從同步功能我們可以把寫入放到主庫上執(zhí)行，把讀功能轉移到從服務上，因此就可以在單位時間內(nèi)處理更多的請求，從而提升的 Redis 整體的運行速度。

而哨兵模式是對于主從功能的升級，但當主節(jié)點奔潰之后，無需人工干預就能自動恢復 Redis 的正常使用。

Redis Cluster 是 Redis 3.0 正式推出的，Redis 集群是通過將數(shù)據(jù)分散存儲到多個節(jié)點上，來平衡各個節(jié)點的負載壓力。

Redis Cluster 采用虛擬哈希槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到 0 ~ 16383整數(shù)槽內(nèi)，計算公式：slot = CRC16(key) & 16383，每一個節(jié)點負責維護一部分槽以及槽所映射的鍵值數(shù)據(jù)。這樣 Redis 就可以把讀寫壓力從一臺服務器，分散給多臺服務器了，因此性能會有很大的提升。

在這三個功能中，我們只需要使用一個就行了，毫無疑問 Redis Cluster 應該是首選的實現(xiàn)方案，它可以把讀寫壓力自動的分擔給更多的服務器，并且擁有自動容災的能力。

13. 避免內(nèi)存碎片

頻繁的新增修改會導致內(nèi)存碎片的增多，因此需要時刻的清理內(nèi)存碎片。

Redis提供了INFO memory可以查看內(nèi)存的使用信息，如下：

INFO?memory
#?Memory
used_memory:1073741736
used_memory_human:1024.00M
used_memory_rss:1997159792
used_memory_rss_human:1.86G
…
mem_fragmentation_ratio:1.86

這里有一個 mem_fragmentation_ratio 的指標，它表示的就是 Redis 當前的內(nèi)存碎片率。那么，這個碎片率是怎么計算的呢？其實，就是上面的命令中的兩個指標 used_memory_rss 和 used_memory 相除的結果。

mem_fragmentation_ratio?=?used_memory_rss/?used_memory

used_memory_rss 是操作系統(tǒng)實際分配給 Redis 的物理內(nèi)存空間，里面就包含了碎片；而 used_memory 是 Redis 為了保存數(shù)據(jù)實際申請使用的空間。

那么，知道了這個指標，我們該如何使用呢？在這兒，我提供一些經(jīng)驗閾值：

1. mem_fragmentation_ratio 大于 1 但小于 1.5。這種情況是合理的。這是因為，剛才我介紹的那些因素是難以避免的。畢竟，內(nèi)因的內(nèi)存分配器是一定要使用的，分配策略都是通用的，不會輕易修改；而外因由 Redis 負載決定，也無法限制。所以，存在內(nèi)存碎片也是正常的。

2. mem_fragmentation_ratio 大于 1.5 。這表明內(nèi)存碎片率已經(jīng)超過了 50%。一般情況下，這個時候，我們就需要采取一些措施來降低內(nèi)存碎片率了。

一旦內(nèi)存碎片率過高了，此時就應該采用手段清理內(nèi)存碎片了，具體如何清理，參考文章：Redis清理內(nèi)存碎片

總結

本文著重介紹了13條性能優(yōu)化軍規(guī)，在開發(fā)過程中還是需要針對性的具體問題具體分析，希望作者這篇文章能夠幫助到你。

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝