Redis(二十一)：Redis效能問題排查解決手冊

標籤：應用程式   方法   tps   限制   unix   提升效能   內容   數組   片段   

效能相關的資料指標

通過Redis-cli命令列介面訪問到Redis伺服器，然後使用info命令擷取所有與Redis服務相關的資訊。通過這些資訊來分析文章後面提到的一些效能指標。

info命令輸出的資料可分為10個類別，分別是：

• server
• clients
• memory
• persistence
• stats
• replication
• cpu
• commandstats
• cluster
• keyspace

這篇主要介紹比較重要的2部分效能指標memory和stats。

需要注意的是info命令返回的資訊，並沒有命令響應延遲相關的資料資訊，所以後面會詳細介紹怎麼擷取與延遲相關的資料指標。

倘若你覺得info輸出的資訊太多並且雜亂無章，可以指定info命令的參數來擷取單個分類下的資料。比如輸入info memory命令，會只返回與記憶體相關的資料。

為了快速定位並解決效能問題，這裡選擇5個關鍵性的資料指標，它包含了大多數人在使用Redis上會經常碰到的效能問題。

記憶體使用量率used_memory

中used_memory 欄位資料表示的是：由Redis分配器分配的記憶體總量，以位元組（byte）為單位。 其中used_memory_human上的資料和used_memory是一樣的值，它以M為單位顯示，僅為了方便閱讀。

used_memory是Redis使用的記憶體總量，它包含了實際緩衝佔用的記憶體和Redis自身運行所佔用的記憶體(如中繼資料、lua)。它是由Redis使用記憶體 Clerk分配的記憶體，所以這個資料並沒有把記憶體片段浪費掉的記憶體給統計進去。

其他欄位代表的含義，都以位元組為單位：

• used_memory_rss：從作業系統上顯示已經分配的記憶體總量。
• mem_fragmentation_ratio： 記憶體片段率。
• used_memory_lua： Lua指令碼引擎所使用的記憶體大小。
• mem_allocator： 在編譯時間指定的Redis使用的記憶體 Clerk，可以是libc、jemalloc、tcmalloc。

因記憶體交換引起的效能問題

記憶體使用量率是Redis服務最關鍵的一部分。如果一個Redis執行個體的記憶體使用量率超過可用最大記憶體(used_memory >可用最大記憶體)，那麼作業系統開始進行記憶體與swap空間交換，把記憶體中舊的或不再使用的內容寫入硬碟上（硬碟上的這塊空間叫Swap分區），以便騰出新的實體記憶體給新頁或活動頁(page)使用。 
在硬碟上進行讀寫操作要比在記憶體上進行讀寫操作，時間上慢了近5個數量級，記憶體是0.1μs單位、而硬碟是10ms。如果Redis進程上發生記憶體交換，那麼Redis和依賴Redis上資料的應用會受到嚴重的效能影響。 通過查看used_memory指標可知道Redis正在使用的記憶體情況，如果used_memory>可用最大記憶體，那就說明Redis執行個體進行中記憶體交換或者已經記憶體交換完畢。管理員根據這個情況，執行相對應的應急措施。

跟蹤記憶體使用量率

若是在使用Redis期間沒有開啟rdb快照或aof持久化策略，那麼快取資料在Redis崩潰時就有丟失的危險。因為當Redis記憶體使用量率超過可用記憶體的95%時，部分資料開始在記憶體與swap空間來回交換，這時就可能有遺失資料的危險。
當開啟並觸發快照功能時，Redis會fork一個子進程把當前記憶體中的資料完全複製一份寫入到硬碟上。因此若是當前使用記憶體超過可用記憶體的45%時觸發快照功能，那麼此時進行的記憶體交換會變的非常危險(可能會遺失資料)。 倘若在這個時候執行個體上有大量頻繁的更新操作，問題會變得更加嚴重。

通過減少Redis的記憶體佔用率，來避免這樣的問題，或者使用下面的技巧來避免記憶體交換髮生：

1. 假如快取資料小於4GB，就使用32位的Redis執行個體。因為32位執行個體上的指標大小隻有64位的一半，它的記憶體空間佔用空間會更少些。 這有一個壞處就是，假設實體記憶體超過4GB，那麼32位執行個體能使用的記憶體仍然會被限制在4GB以下。 要是執行個體同時也共用給其他一些應用使用的話，那可能需要更高效的64位Redis執行個體，這種情況下切換到32位是不可取的。 不管使用哪種方式，Redis的dump檔案在32位和64位之間是互相相容的， 因此倘若有減少佔用記憶體空間的需求，可以嘗試先使用32位，後面再切換到64位上。

2. 儘可能的使用Hash資料結構。因為Redis在儲存小於100個欄位的Hash結構上，其儲存效率是非常高的。所以在不需要集合(set)操作或list的push/pop操作的時候，儘可能的使用Hash結構。比如，在一個web應用程式中，需要儲存一個對象表示使用者資訊，使用單個key表示一個使用者，其每個屬性儲存區在Hash的欄位裡，這樣要比給每個屬性單獨設定一個key-value要高效的多。 通常情況下倘若有資料使用string結構，用多個key儲存時，那麼應該轉換成單key多欄位的Hash結構。 如上述例子中介紹的Hash結構應包含，單個對象的屬性或者單個使用者各種各樣的資料。Hash結構的操作命令是HSET(key, fields, value)和HGET(key, field)，使用它可以儲存或從Hash中取出指定的欄位。

3. 設定key的到期時間。一個減少記憶體使用量率的簡單方法就是，每當儲存物件時確保設定key的到期時間。倘若key在明確的時間周期內使用或者舊key不大可能被使用時，就可以用Redis到期時間命令(expire,expireat, pexpire, pexpireat)去設定到期時間，這樣Redis會在key到期時自動刪除key。 假如你知道每秒鐘有多少個新key-value被建立，那可以調整key的存活時間，並指定閥值去限制Redis使用的最大記憶體。

4. 回收key。在Redis設定檔中(一般叫Redis.conf)，通過設定“maxmemory”屬性的值可以限制Redis最大使用的記憶體，修改後重啟執行個體生效。也可以使用用戶端命令config set maxmemory 去修改值，這個命令是立即生效的，但會在重啟後會失效，需要使用config rewrite命令去重新整理設定檔。 若是啟用了Redis快照功能，應該設定“maxmemory”值為系統可使用記憶體的45%，因為快照時需要一倍的記憶體來複製整個資料集，也就是說如果當前已使用45%，在快照期間會變成95%(45%+45%+5%)，其中5%是預留給其他的開銷。 如果沒開啟快照功能，maxmemory最高能設定為系統可用記憶體的95%。

當記憶體使用量達到設定的最大閥值時，需要選擇一種key的回收策略，可在Redis.conf設定檔中修改“maxmemory-policy”屬性值。 若是Redis資料集中的key都設定了到期時間，那麼“volatile-ttl”策略是比較好的選擇。但如果key在達到最大記憶體限制時沒能夠迅速到期，或者根本沒有設定到期時間。那麼設定為“allkeys-lru”值比較合適，它允許Redis從整個資料集中挑選最近最少使用的key進行刪除(LRU淘汰演算法)。Redis還提供了一些其他淘汰策略，如下：

• volatile-lru：使用LRU演算法從已設定到期時間的資料集合中淘汰資料。
• volatile-ttl：從已設定到期時間的資料集合中挑選即將到期的資料淘汰。
• volatile-random：從已設定到期時間的資料集合中隨機挑選資料淘汰。
• allkeys-lru：使用LRU演算法從所有資料集合中淘汰資料。
• allkeys-random：從資料集合中任意選擇資料淘汰
• no-enviction：禁止淘汰資料。

通過設定maxmemory為系統可用記憶體的45%或95%(取決於持久化策略)和設定“maxmemory-policy”為“volatile-ttl”或“allkeys-lru”(取決於到期設定)，可以比較準確的限制Redis最大記憶體使用量率，在絕大多數情境下使用這2種方式可確保Redis不會進行記憶體交換。倘若你擔心由於限制了記憶體使用量率導致遺失資料的話，可以設定noneviction值禁止淘汰資料。

命令處理數total_commands_processed

在info資訊裡的total_commands_processed欄位顯示了Redis服務處理命令的總數，其命令都是從一個或多個Redis用戶端請求過來的。Redis每時每刻都在處理從用戶端請求過來的命令，它可以是Redis提供的140種命令的任意一個。 total_commands_processed欄位的值是遞增的，比如Redis服務分別處理了client_x請求過來的2個命令和client_y請求過來的3個命令，那麼命令處理總數(total_commands_processed)就會加上5。 

分析命令處理總數，診斷響應延遲。

在Redis執行個體中，跟蹤命令處理總數是解決響應延遲問題最關鍵的部分，因為Redis是個單執行緒模式，用戶端過來的命令是按照順序執行的。比較常見的延遲是頻寬，通過千兆網卡的延遲大約有200μs。倘若明顯看到命令的回應時間變慢，延遲高於200μs，那可能是Redis命令隊列裡等待處理的命令數量比較多。 如上所述，延遲時間增加導致回應時間變慢可能是由於一個或多個慢命令引起的，這時可以看到每秒命令處理數在明顯下降，甚至於後面的命令完全被阻塞，導致Redis效能降低。要分析解決這個效能問題，需要跟蹤命令處理數的數量和延遲時間。
比如可以寫個指令碼，定期記錄total_commands_processed的值。當用戶端明顯發現回應時間過慢時，可以通過記錄的total_commands_processed曆史資料值來判斷命理處理總數是上升趨勢還是下降趨勢，以便排查問題。

使用命令處理總數解決延遲時間增加。

通過與記錄的曆史資料比較得知，命令處理總數確實是處於上升或下降狀態，那麼可能是有2個原因引起的:

• 命令隊列裡的命令數量過多，後面命令一直在等待中。
• 幾個慢命令阻塞Redis。

下面有三個辦法可以解決，因上面2條原因引起的響應延遲問題。

1. 使用多參數命令：若是用戶端在很短的時間內發送大量的命令過來，會發現回應時間明顯變慢，這由於後面命令一直在等待隊列中前面大量命令執行完畢。有個方法可以改善延遲問題，就是通過單命令多參數的形式取代多命令單參數的形式。舉例來說，迴圈使用LSET命令去添加1000個元素到list結構中，是效能比較差的一種方式，更好的做法是在用戶端建立一個1000元素的列表，用單個命令LPUSH或RPUSH，通過多參數構造形式一次性把1000個元素髮送的Redis服務上。下面的表格是Redis的一些操作命令，有單個參數命令和支援多個參數的命令，通過這些命令可盡量減少使用多命令的次數。                                                                                                                                     

2. 管道命令：另一個減少多命令的方法是使用管道(pipeline)，把幾個命令合并一起執行，從而減少因網路開銷引起的延遲問題。因為10個命令單獨發送到服務端會引起10次網路延遲開銷，使用管道會一次性把執行結果返回，僅需要一次網路延遲開銷。Redis本身支援管道命令，大多數用戶端也支援，倘若當前執行個體延遲很明顯，那麼使用管道去降低延遲是非常有效。

3. 避免操作大集合的慢命令：如果命令處理頻率過低導致延遲時間增加，這可能是因為使用了高時間複雜度的命令操作導致，這意味著每個命令從集合中擷取資料的時間增大。 所以減少使用高時間複雜的命令，能顯著的提高的Redis的效能。下面的表格是高時間複雜度命令的列表，其詳細描述了命令的屬性，有這助於高效合理的、最佳化的使用這些命令(如果不得不使用的話)，以提高Redis效能。

       

延遲時間 

Redis的延遲資料是無法從info資訊中擷取的。倘若想要查看延遲時間，可以用Redis-cli工具加--latency參數運行，如:

Redis-cli --latency -h 127.0.0.1 -p 6379

其host和port是Redis執行個體的ip及連接埠。由於當前伺服器不同的運行情況，延遲時間可能有所誤差，通常1G網卡的延遲時間是200μs。

以毫秒為單位測量Redis的響應延遲時間，樓主原生延遲是300μs：

跟蹤Redis延遲效能

Redis之所以這麼流行的主要原因之一就是低延遲特性帶來的高效能，所以說解決延遲問題是提高Redis效能最直接的辦法。拿1G頻寬來說，若是延遲時間遠高於200μs，那明顯是出現了效能問題。 雖然在伺服器上會有一些慢的IO操作，但Redis是單核接受所有用戶端的請求，所有請求是按良好的順序排隊執行。因此若是一個用戶端發過來的命令是個慢操作，那麼其他所有請求必須等待它完成後才能繼續執行。

使用延遲命令提高效能

一旦確定延遲時間是個效能問題後，這裡有幾個辦法可以用來分析解決效能問題。

1. 使用slowlog查出引發延遲的慢命令：Redis中的slowlog命令可以讓我們快速定位到那些超出指定執行時間的慢命令，預設情況下命令若是執行時間超過10ms就會被記錄到日誌。slowlog只會記錄其命令執行的時間，不包含io往返操作，也不記錄單由網路延遲引起的響應慢。通常1gb頻寬的網路延遲，預期在200μs左右，倘若一個命令僅執行時間就超過10ms，那比網路延遲慢了近50倍。 想要查看所有執行時間比較慢的命令，可以通過使用Redis-cli工具，輸入slowlog get命令查看，返回結果的第三個欄位以微妙位單位顯示命令的執行時間。假如只需要查看最後10個慢命令，輸入slowlog get 10即可。 關於怎麼定位到是由慢命令引起的延遲問題，可查看total_commands_processed介紹章節。

圖中欄位分別意思是：

• 1=日誌的唯一識別碼
• 2=被記錄命令的執行時間點，以 UNIX 時間戳記格式表示
• 3=查詢執行時間，以微秒為單位。例子中命令使用54毫秒。
• 4= 執行的命令，以數組的形式排列。完整命令是config get *。

倘若你想自訂慢命令的標準，可以調整觸發日誌記錄慢命令的閥值。若是很少或沒有命令超過10ms，想降低記錄的閥值，比如5毫秒，可在Redis-cli工具中輸入下面的命令配置：

config set slowlog-log-slower-than 5000

也可以在Redis.config設定檔中設定，以微妙位單位。

2.監控用戶端的串連：因為Redis是單執行緒模式(只能使用單核)，來處理所有用戶端的請求， 但由於用戶端串連數的增長，處理請求的線程資源開始降低分配給單個用戶端串連的處理時間，這時每個用戶端需要花費更多的時間去等待Redis共用服務的響應。這種情況下監控用戶端串連數是非常重要的，因為用戶端建立串連數的數量可能超出預期的數量，也可能是用戶端端沒有有效釋放串連。在Redis-cli工具中輸入info clients可以查看到當前執行個體的所有用戶端串連資訊。如，第一個欄位(connected_clients)顯示當前執行個體用戶端串連的總數：

Redis預設允許用戶端串連的最大數量是10000。若是看到串連數超過5000以上，那可能會影響Redis的效能。倘若一些或大部分用戶端發送大量的命令過來，這個數字會低的多。

3.限制用戶端串連數：自Redis2.6以後，允許使用者在設定檔(Redis.conf)maxclients屬性上修改用戶端串連的最大數，也可以通過在Redis-cli工具上輸入config set maxclients 去設定最大串連數。根據串連數負載的情況，這個數字應該設定為預期串連數峰值的110%到150之間，若是串連數超出這個數字後，Redis會拒絕並立刻關閉新來的串連。通過設定最大串連數來限制非預期數量的串連數增長，是非常重要的。另外，新串連嘗試失敗會返回一個錯誤訊息，這可以讓用戶端知道，Redis此時有非預期數量的串連數，以便執行對應的處理措施。 上述二種做法對控制串連數的數量和持續保持Redis的效能最優是非常重要的，

4.加強記憶體管理：較少的記憶體會引起Redis延遲時間增加。如果Redis佔用記憶體超出系統可用記憶體，作業系統會把Redis進程的一部分資料，從實體記憶體交換到硬碟上，記憶體交換會明顯的增加延遲時間。關於怎麼監控和減少記憶體使用量，可查看used_memory介紹章節。

5. 效能資料指標：

分析解決Redis效能問題，通常需要把延遲時間的資料變化與其他效能指標的變化相關聯起來。命令處理總數下降的發生可能是由慢命令阻塞了整個系統，但如果命令處理總數的增加，同時記憶體使用量率也增加，那麼就可能是由於記憶體交換引起的效能問題。對於這種效能指標相關聯的分析，需要從曆史資料上來觀察到資料指標的重要變化，此外還可以觀察到單個效能指標相關聯的所有其他效能指標資訊。這些資料可以在Redis上收集，周期性的調用內容為Redis info的指令碼，然後分析輸出的資訊，記錄到記錄檔中。當延遲發生變化時，用記錄檔配合其他資料指標，把資料串聯起來排查定位問題。

記憶體片段率

info資訊中的mem_fragmentation_ratio給出了記憶體片段率的資料指標，它是由操系統分配的記憶體除以Redis分配的記憶體得出：

used_memory和used_memory_rss數字都包含的記憶體配置有：

• 使用者定義的資料：記憶體被用來儲存key-value值。
• 內部開銷： 儲存內部Redis資訊用來表示不同的資料類型。

used_memory_rss的rss是Resident Set Size的縮寫，表示該進程所佔實體記憶體的大小，是作業系統分配給Redis執行個體的記憶體大小。除了使用者定義的資料和內部開銷以外，used_memory_rss指標還包含了記憶體片段的開銷，記憶體片段是由作業系統低效的分配/回收實體記憶體導致的。
作業系統負責分配實體記憶體給各個應用進程，Redis使用的記憶體與實體記憶體的映射是由作業系統上虛擬記憶體管理分配器完成的。
舉個例子來說，Redis需要分配連續記憶體塊來儲存1G的資料集，這樣的話更有利，但可能實體記憶體上沒有超過1G的連續記憶體塊，那作業系統就不得不使用多個不連續的小記憶體塊來分配並儲存這1G資料，也就導致記憶體片段的產生。
記憶體 Clerk另一個複雜的層面是，它經常會預先分配一些記憶體塊給引用，這樣做會使加快應用程式的運行。

理解資源效能

跟蹤記憶體片段率對理解Redis執行個體的資源效能是非常重要的。記憶體片段率稍大於1是合理的，這個值表示記憶體片段率比較低，也說明redis沒有發生記憶體交換。但如果記憶體片段率超過1.5，那就說明Redis消耗了實際需要實體記憶體的150%，其中50%是記憶體片段率。若是記憶體片段率低於1的話，說明Redis記憶體配置超出了實體記憶體，作業系統進行中記憶體交換。記憶體交換會引起非常明顯的響應延遲，可查看used_memory介紹章節。

中的0.99即99%。

用記憶體片段率預測效能問題

倘若記憶體片段率超過了1.5，那可能是作業系統或Redis執行個體中記憶體管理變差的表現。下面有3種方法解決記憶體管理變差的問題，並提高Redis效能：

1. 重啟Redis伺服器：如果記憶體片段率超過1.5，重啟Redis伺服器可以讓額外產生的記憶體片段失效並重新作為新記憶體來使用，使作業系統恢複高效的記憶體管理。額外片段的產生是由於Redis釋放了記憶體塊，但記憶體 Clerk並沒有返回記憶體給作業系統，這個記憶體 Clerk是在編譯時間指定的，可以是libc、jemalloc或者tcmalloc。 通過比較used_memory_peak, used_memory_rss和used_memory_metrics的資料指標值可以檢查額外記憶體片段的佔用。從名字上可以看出，used_memory_peak是過去Redis記憶體使用量的峰值，而不是當前使用記憶體的值。如果used_memory_peak和used_memory_rss的值大致上相等，而且二者明顯超過了used_memory值，這說明額外的記憶體片段正在產生。在Redis-cli工具上輸入info memory可以查看上面三個指標的資訊：

在重啟伺服器之前，需要在Redis-cli工具上輸入shutdown save命令，意思是強制讓Redis資料庫執行儲存操作並關閉Redis服務，這樣做能保證在執行Redis關閉時不丟失任何資料。 在重啟後，Redis會從硬碟上載入持久化的檔案，以確保資料集持續可用。

2.限制記憶體交換： 如果記憶體片段率低於1，Redis執行個體可能會把部分資料交換到硬碟上。記憶體交換會嚴重影響Redis的效能，所以應該增加可用實體記憶體或減少實Redis記憶體佔用。 可查看used_memory章節的最佳化建議。

3.修改記憶體 Clerk：
Redis支援glibc’smalloc、jemalloc11、tcmalloc幾種不同的記憶體 Clerk，每個分配器在記憶體配置和片段上都有不同的實現。不建議普通管理員修改Redis預設記憶體 Clerk，因為這需要完全理解這幾種記憶體 Clerk的差異，也要重新編譯Redis。這個方法更多的是讓其瞭解Redis記憶體 Clerk所做的工作，當然也是改善記憶體片段問題的一種辦法。

回收key

info資訊中的evicted_keys欄位顯示的是，因為maxmemory限制導致key被回收刪除的數量。關於maxmemory的介紹見前面章節，回收key的情況只會發生在設定maxmemory值後，不設定會發生記憶體交換。 當Redis由於記憶體壓力需要回收一個key時，Redis首先考慮的不是回收最舊的資料，而是在最近最少使用的key或即將到期的key中隨機播放一個key，從資料集中刪除。

這可以在設定檔中設定maxmemory-policy值為“volatile-lru”或“volatile-ttl”，來確定Redis是使用lru策略還是到期時間策略。 倘若所有的key都有明確的到期時間，那到期時間回收策略是比較合適的。若是沒有設定key的到期時間或者說沒有足夠的到期key，那設定lru策略是比較合理的，這可以回收key而不用考慮其到期狀態。

根據key回收定位效能問題

跟蹤key回收是非常重要的，因為通過回收key，可以保證合理分配Redis有限的記憶體資源。如果evicted_keys值經常超過0，那應該會看到用戶端命令響應延遲時間增加，因為Redis不但要處理用戶端過來的命令請求，還要頻繁的回收滿足條件的key。
需要注意的是，回收key對效能的影響遠沒有記憶體交換嚴重，若是在強制記憶體交換和設定回收策略做一個選擇的話，選擇設定回收策略是比較合理的，因為把記憶體資料交換到硬碟上對效能影響非常大(見前面章節)。

減少回收key以提升效能

減少回收key的數量是提升Redis效能的直接辦法，下面有2種方法可以減少回收key的數量：

1.增加記憶體限制：倘若開啟快照功能，maxmemory需要設定成實體記憶體的45%，這幾乎不會有引發記憶體交換的危險。若是沒有開啟快照功能，設定系統可用記憶體的95%是比較合理的，具體參考前面的快照和maxmemory限制章節。如果maxmemory的設定是低於45%或95%(視持久化策略)，通過增加maxmemory的值能讓Redis在記憶體中儲存更多的key，這能顯著減少回收key的數量。 若是maxmemory已經設定為推薦的閥值後，增加maxmemory限制不但無法提升效能，反而會引發記憶體交換，導致延遲增加、效能降低。 maxmemory的值可以在Redis-cli工具上輸入config set maxmemory命令來設定。
需要注意的是，這個設定是立即生效的，但重啟後丟失，需要永久化儲存的話，再輸入config rewrite命令會把記憶體中的新配置重新整理到設定檔中。

2.對執行個體進行分區：分區是把資料分割成合適大小，分別存放在不同的Redis執行個體上，每一個執行個體都包含整個資料集的一部分。通過分區可以把很多伺服器聯合起來儲存資料，相當於增加總的實體記憶體，使其在沒有記憶體交換和回收key的策略下也能儲存更多的key。假如有一個非常大的資料集，maxmemory已經設定，實際記憶體使用量也已經超過了推薦設定的閥值，那通過資料分區能明顯減少key的回收，從而提高Redis的效能。 分區的實現有很多種方法，下面是Redis實現分區的幾種常見方式：

• a. Hash分區：一個比較簡單的方法實現，通過HashFunction Compute出key的Hash值，然後值所在範圍對應特定的Redis執行個體。
• b. 代理分區：用戶端把請求發送到代理上，代理通過分區配置表選擇對應的Redis執行個體。 如Twitter的Twemproxy，豌豆莢的codis。
• c. 一致性Hash分區： 參見前面部落格《一致性Hash分區詳解》
• d. 虛擬桶分區：參見前面部落格《虛擬桶分詳解》

總結

對於開發人員來說，Redis是個速度非常快的key-value記憶體資料庫，並提供了方便的API介面。為了最好最優的使用Redis，需要理解哪些因素能影響到Redis效能，哪些資料指標能協助我們避免效能陷阱。 通過本篇，能理解Redis中的重要效能指標，怎麼查看，更重要的是怎麼利用這些資料排查解決Redis效能問題。

本篇部落客要翻譯了一電子書的中間15頁，電子書地址是https://www.datadoghq.com/wp-content/uploads/2013/09/Understanding-the-Top-5-Redis-Performance-Metrics.pdf。

Redis(二十一)：Redis效能問題排查解決手冊（轉）