性能相關的資料名額
通過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使用記憶體配置設定器配置設定的記憶體，是以這個資料并沒有把記憶體碎片浪費掉的記憶體給統計進去。
其他字段代表的含義，都以位元組為機關：
used_memory_rss：從作業系統上顯示已經配置設定的記憶體總量。
mem_fragmentation_ratio： 記憶體碎片率。
used_memory_lua： Lua腳本引擎所使用的記憶體大小。
mem_allocator： 在編譯時指定的Redis使用的記憶體配置設定器，可以是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資料，也就導緻記憶體碎片的産生。
記憶體配置設定器另一個複雜的層面是，它經常會預先配置設定一些記憶體塊給引用，這樣做會使加快應用程式的運作。
了解資源性能
跟蹤記憶體碎片率對了解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釋放了記憶體塊，但記憶體配置設定器并沒有傳回記憶體給作業系統，這個記憶體配置設定器是在編譯時指定的，可以是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.修改記憶體配置設定器：
Redis支援glibc’s malloc、jemalloc11、tcmalloc幾種不同的記憶體配置設定器，每個配置設定器在記憶體配置設定和碎片上都有不同的實作。
不建議普通管理者修改Redis預設記憶體配置設定器，因為這需要完全了解這幾種記憶體配置設定器的差異，也要重新編譯Redis。這個方法更多的是讓其了解Redis記憶體配置設定器所做的工作，當然也是改善記憶體碎片問題的一種辦法。
回收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分片：一個比較簡單的方法實作，通過Hash函數計算出key的Hash值，然後值所在範圍對應特定的Redis執行個體。
b. 代理分片：用戶端把請求發送到代理上，代理通過分片配置表選擇對應的Redis執行個體。 如Twitter的Twemproxy，豌豆莢的codis。
c. 一緻性Hash分片
d. 虛拟桶分片
總結
對于開發者來說，Redis是個速度非常快的key-value記憶體資料庫，并提供了友善的API接口。為了最好最優的使用Redis，需要了解哪些因素能影響到Redis性能，哪些資料名額能幫助我們避免性能陷阱。 通過本篇，能了解Redis中的重要性能名額，怎麼檢視，更重要的是怎麼利用這些資料排查解決Redis性能問題。