前言

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

本文將會介紹十三條性能優(yōu)化軍規(guī)，開發(fā)過程中只要按照執(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. 生產環(huán)境禁用keys命令

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

3. keys需要設置過期時間

Redis作為內存數(shù)據(jù)庫，一切的數(shù)據(jù)都是在內存中，一旦內存占用過大則會大大影響性能，因此需要對有時間限制的數(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，那么，一秒內基本有 200 個過期 key 會被刪除。這一策略對清除過期 key、釋放內存空間很有幫助。如果每秒鐘刪除 200 個過期 key，并不會對 Redis 造成太大影響。

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

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

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

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

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

1. string：單個的緩存結果，不與其他的 KV 之間有聯(lián)系
2. hash：一個 Object 包含有很多屬性，且這些屬性都需要單獨存儲。注意：這種情況不要使用 string，因為 string 會占據(jù)更多的內存
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快照：以快照的方式，將某一個時刻的內存數(shù)據(jù)，以二進制的方式寫入磁盤。
3. AOF和 RDB混用：Redis4.0新增的方式，為了采用兩種方式各自的優(yōu)點，在RDB快照的時間段內使用的AOF日志記錄這段時間的操作的命令，這樣一旦發(fā)生宕機，將不會丟失兩段快照中間的數(shù)據(jù)。

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

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

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

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

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

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

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

9. 增加機器內存或者使用Redis集群

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13. 避免內存碎片

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

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

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 當前的內存碎片率。那么，這個碎片率是怎么計算的呢？其實，就是上面的命令中的兩個指標 used_memory_rss 和 used_memory 相除的結果。

mem_fragmentation_ratio?=?used_memory_rss/?used_memory

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

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

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

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

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

總結

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

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

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