什麼是Redis
Redis是一種流行的記憶體鍵/值資料存儲。 Redis以其出色的性能和簡單的入門而聞名，已在各個行業中找到了用途，包括：
- 資料庫：盡管可以使用異步磁盤持久性，但Redis可以用持久性來換取速度，而不是傳統的基于磁盤的資料庫。 Redis提供了豐富的資料原語集和異常豐富的指令清單。
- 郵件隊列：Redis的阻止清單指令和低延遲使其成為郵件代理服務的良好後端。
- 記憶體緩存：可配置的密鑰收回政策，包括流行的“最近最少使用”政策以及從Redis 4.0開始的“最少經常使用”政策，使Redis成為緩存伺服器的絕佳選擇。 與傳統的緩存不同，Redis還允許持久化磁盤以提高可靠性。
Redis是免費的開放源代碼産品。 提供商業支援，以及完全托管的Redis即服務。
Redis被許多高流量的網站和應用程式所采用，例如Twitter，GitHub，Docker，Pinterest，Datadog和Stack Overflow。
關鍵Redis名額
監視Redis可以幫助您在兩個方面發現問題：Redis本身的資源問題以及支援基礎架構中其他地方出現的問題。
在本文中，我們詳細介紹了以下每個類别中最重要的Redis名額：
- 性能名額
- 記憶體名額
- 基本活動名額
- 持續性名額
- 錯誤名額
除低錯誤率外，良好的性能是系統運作狀況的最佳頂級名額之一。 如記憶體部分中所述，性能不佳通常是由記憶體問題引起的。
告警名額：latency
延遲是對用戶端請求和實際伺服器響應之間的時間的度量。 跟蹤延遲是檢測Redis性能變化的最直接方法。 由于Redis具有單線程特性，是以延遲分布中的異常值可能會導緻嚴重的瓶頸。 一個請求的響應時間過長會增加所有後續請求的等待時間。一旦确定延遲是一個問題，就可以采取多種措施來診斷和解決性能問題。
觀測名額：Instantaneous_ops_per_sec
跟蹤已處理指令的吞吐量對于診斷Redis執行個體中高延遲的原因至關重要。 高延遲可能是由許多問題引起的，從積壓的指令隊列到速度慢的指令，再到網絡鍊路過度使用。 您可以通過測量每秒處理的指令數來進行調查-如果該指令幾乎保持不變，則原因不是計算密集型指令。 如果一個或多個慢速指令引起延遲問題，您将看到每秒的指令數量下降或完全停止。與曆史規範相比，每秒處理的指令數量下降可能是低指令量或阻塞系統的慢指令的迹象。 低指令量可能是正常現象，或者可能表明上遊出現問題。
名額：hit rate
将Redis用作緩存時，監視緩存命中率可以告訴您緩存是否得到有效使用。命中率低意味着用戶端正在尋找不再存在的密鑰。Redis不直接提供命中率名額。我們仍然可以這樣計算：
hit rate = keyspace_hits / (keyspace_hits + keyspace_misses)
高速緩存命中率低可能是由多種因素引起的，包括資料到期和配置設定給Redis的記憶體不足（這可能會導緻鍵退出）。 低命中率可能會導緻應用程式延遲增加，因為它們必須從較慢的備用資源中擷取資料。
觀測名額：used_memory
記憶體使用率是Redis性能的關鍵組成部分。 如果used_memory超出了可用的系統總記憶體，則作業系統将開始交換記憶體的舊/未使用部分。 每個交換的部分都寫入磁盤，進而嚴重影響性能。 從磁盤寫入或讀取比從記憶體寫入或讀取要慢5個數量級（100,000x！）（記憶體為0.1 µs，磁盤為10 ms）。
您可以将Redis配置為限制在指定的記憶體量内。 在redis.conf檔案中設定maxmemory指令可以直接控制Redis的記憶體使用情況。 啟用maxmemory要求您為Redis配置驅逐政策，以确定釋放記憶體的方式。 在evicted_keys部分中了解有關配置maxmemory-policy指令的更多資訊。
警報名額：mem_fragmentation_ratio
mem_fragmentation_ratio度量标準提供了作業系統（used_memory_rss）所使用的記憶體與Redis配置設定的記憶體（used_memory）的比率。
mem_fragmentation_ratio = used_memory_rss / used_memory
作業系統負責為每個程序配置設定實體記憶體。作業系統的虛拟記憶體管理器處理由記憶體配置設定器介導的實際映射。
這是什麼意思？如果您的Redis執行個體的記憶體占用為1GB，則記憶體配置設定器将首先嘗試查找連續的記憶體段來存儲資料。如果找不到連續的段，則配置設定器必須将程序的資料劃分為多個段，進而增加記憶體開銷。
跟蹤碎片率對于了解Redis執行個體的性能非常重要。碎片率大于1表示正在發生碎片。比率超過1.5表示碎片過多，您的Redis執行個體消耗了其請求的實體記憶體的150％。小于1的碎片率告訴您Redis需要的記憶體多于系統上可用的記憶體，這導緻交換。交換到磁盤将導緻延遲顯着增加（請參閱已用記憶體）。理想情況下，作業系統将在實體記憶體中配置設定一個連續的段，其碎片率等于1或更大。
如果伺服器的碎片率超過1.5，重新啟動Redis執行個體将允許作業系統恢複以前由于碎片而無法使用的記憶體。在這種情況下，将警報作為通知可能就足夠了。
但是，如果您的Redis伺服器的碎片率低于1，則可能需要作為頁面發出警報，以便您可以快速增加可用記憶體或減少記憶體使用量。
從Redis 4開始，将Redis配置為使用随附的jemalloc副本時，可以使用新的主動碎片整理功能。可以将該工具配置為在碎片達到一定級别時啟動，并開始将值複制到連續的記憶體區域中并釋放舊副本，進而減少伺服器運作時的碎片。
警報名額：evicted_keys（僅高速緩存）
如果您将Redis用作緩存，則可能需要将其配置為在達到最大記憶體限制時自動清除密鑰。 如果您将Redis用作資料庫或隊列，則最好将其替換為逐出，在這種情況下，您可以跳過此名額。
跟蹤密鑰移出很重要，因為Redis會順序處理每個操作，這意味着逐出大量密鑰會導緻較低的命中率，進而導緻更長的延遲時間。 如果您使用的是TTL，則可能不會希望退出按鍵。 在這種情況下，如果該名額始終大于零，則您的執行個體中的延遲可能會增加。 其他大多數不使用TTL的配置最終都會耗盡記憶體，并開始逐出密鑰。 隻要您的響應時間是可以接受的，穩定的驅逐率是可以接受的。
您可以使用以下指令配置密鑰到期政策：
redis-cli CONFIG SET maxmemory-policy <policy>
其中policy是下列之一：
- noeviction：當達到記憶體限制并且使用者嘗試添加其他鍵時，傳回一個錯誤
- volatile-lru：删除具有到期集的密鑰中最近最少使用的密鑰
- volatile-ttl：從具有到期集的密鑰中删除剩餘生存時間最短的密鑰
- volatile-random：從具有到期集的密鑰中删除一個随機密鑰
- allkeys-lru：從所有密鑰集中删除最近最少使用的密鑰
- allkeys-random：從所有密鑰集中删除一個随機密鑰
- volatile-lfu：在Redis 4中添加、删除具有到期集的密鑰中最不常用的密鑰
- allkeys-lfu：在Redis 4中添加、從所有密鑰集中删除最不常用的密鑰
注意：由于性能原因，在使用LRU，TTL或Redis 4（從LUF開始）政策時，Redis實際上不會從整個鍵空間中進行采樣。 Redis首先對密鑰空間的一個随機子集進行采樣，然後将逐出政策應用于該樣本。 通常，較新的（> = 3）版本的Redis采用LRU采樣政策，該政策更接近于真實LRU。 LFU政策可以通過設定例如以下内容來調整：設定項目必須經過多少時間才能通路級别降低的項目。 有關更多詳細資訊，請參見Redis的文檔。
觀測名額：blocked_clients
Redis提供了許多對清單進行操作的阻止指令。 BLPOP，BRPOP和BRPOPLPUSH分别是指令LPOP，RPOP和RPOPLPUSH的阻塞變體。 當源清單為非空時，指令将按預期執行。 但是，當源清單為空時，阻止指令将等待，直到源被填充或達到逾時為止。
等待資料的被阻止用戶端的數量增加可能是問題的征兆。 延遲或其他問題可能會阻止源清單的填寫。 盡管阻止的用戶端本身并不會引起警報，但是，如果您看到此名額始終為非零值，則應進行調查。
注意：本節包括使用術語“主”和“從”的度量。 除了引用特定的度量标準名稱外，本文将其替換為 “primary” 和 “replica"。
告警名額：connected_clients
由于對Redis的通路通常是由應用程式介導的（使用者通常不直接通路資料庫），是以在大多數情況下，所連接配接用戶端的數量會有合理的上限和下限。 如果數字超出正常範圍，則可能表明存在問題。 如果它太低，則上遊連接配接可能已丢失；如果它太高，則大量并發用戶端連接配接可能會使伺服器處理請求的能力不堪重負。
無論如何，用戶端連接配接的最大數量始終是有限的資源-無論是受作業系統，Redis的配置還是網絡限制。 監視用戶端連接配接可幫助您確定有足夠的可用資源可用于新用戶端或管理會話。
告警名額：connected_slaves
如果您的資料庫是讀取型資料庫，則可能是在使用Redis中可用的主副本資料庫複制功能。 在這種情況下，監視連接配接副本的數量是關鍵。 如果連接配接的副本數量意外更改，則可能表明主機已關閉或副本執行個體出現問題。
注意：在上圖中，Redis主資料庫将顯示其具有兩個連接配接的副本，并且第一個子節點将各自報告它們也具有兩個連接配接的副本。 由于輔助副本未直接連接配接到Redis主副本，是以它們不包括在連接配接到主副本的副本計數中。
告警名額：master_last_io_seconds_ago
使用Redis的複制功能時，副本執行個體會定期使用其主執行個體進行檢入。長時間沒有通信可能表明您的主Redis伺服器，副本伺服器或兩者之間存在問題。您還冒着副本提供自上次同步以來可能已更改的舊資料的風險。由于Redis執行同步的方式，是以最小化主副本通信的中斷至關重要。當副本在中斷後重新連接配接到主資料庫時，它将發送PSYNC指令以嘗試僅對中斷期間丢失的指令進行部分同步。如果無法做到這一點，則副本将請求完整的SYNC，這将導緻主副本立即開始将資料庫背景儲存到磁盤，同時緩沖收到的所有将修改資料集的新指令。背景儲存完成後，資料将與緩沖的指令一起發送到用戶端。副本每次執行一次SYNC時，都會導緻主執行個體的延遲顯着增加。
值得關注的名額：keyspace
跟蹤資料庫中鍵的數量通常是一個好主意。作為記憶體資料存儲，鍵空間越大，Redis需要更多的實體記憶體來確定最佳性能。 Redis将繼續添加密鑰，直到達到最大記憶體限制為止，此時，Redis開始以新密鑰以相同的速率逐出密鑰。
如果您将Redis用作緩存，并且看到鍵空間飽和（如上圖所示）以及較低的命中率，則您的用戶端可能會請求舊資料或收回的資料。随着時間的推移跟蹤您的keyspace_misses數量将有助于您查明原因。
另外，如果您将Redis用作資料庫或隊列，則可能不建議使用易失性鍵。随着鍵空間的增長，如果可能的話，您可能需要考慮在框内添加記憶體或在主機之間拆分資料集。添加更多的記憶體是一種簡單有效的解決方案。當需要的資源超過一個框所能提供的資源時，可以通過對資料進行分區或分片來組合多台計算機的資源。有了分區計劃，Redis可以存儲更多密鑰而無需逐出或交換。但是，應用分區計劃比在幾個記憶棒中交換更具挑戰性。
啟用持久性可能是必要的，尤其是在使用Redis的複制功能的情況下。 由于副本會盲目複制對主執行個體所做的任何更改，是以，如果要重新啟動主執行個體（無持久性），則與其連接配接的所有副本都将複制其現在為空的資料集。
如果您将Redis用作緩存或在用例中資料丢失将不那麼重要，則可能不需要持久性。
重要監視的名額：rdb_last_save_time和rdb_changes_since_last_save
通常，最好注意資料集的波動性。 如果伺服器發生故障，兩次寫入磁盤之間的時間間隔過長可能會導緻資料丢失。 在上次儲存時間和故障時間之間對資料集所做的任何更改都将丢失。
監視rdb_changes_since_last_save可讓您更深入地了解資料的波動性。 如果您的資料集在該間隔内沒有太大變化，則兩次寫入之間的長時間間隔不成問題。 跟蹤兩個名額可以使您很好地了解如果在給定的時間點發生故障，您将丢失多少資料。
注意：本節包括使用術語“主”和“從”的名額。 除了引用特定的度量标準名稱外，本文将其替換為“primary” 和 “replica"。
Redis錯誤名額可以提醒您異常情況。 以下名額跟蹤常見錯誤：
主伺服器和副本伺服器之間的連結斷開的時間（以秒為機關）
Resource: Errors
告警名額：rejected_connections
Redis能夠處理許多活動連接配接，預設情況下有10,000個用戶端連接配接可用。 通過更改redis.conf中的maxclient指令，可以将最大連接配接數設定為其他值。 如果您的Redis執行個體目前處于最大連接配接數，則任何新的連接配接嘗試都将斷開。
請注意，您的系統可能不支援您使用maxclient指令請求的連接配接數。 Redis與核心核對以确定可用檔案描述符的數量。 如果可用檔案描述符的數量小于maxclient + 32（Redis保留32個檔案描述符供自己使用），則将忽略maxclient指令，并使用可用檔案描述符的數量。
告警名額：keyspace_misses
每次Redis查找密鑰時，隻有兩種可能的結果：密鑰存在，或者密鑰不存在。 查找不存在的鍵會導緻keyspace_misses計數器增加。 此度量标準始終為非零值表示用戶端正在嘗試在資料庫中查找不存在的鍵。 如果未将Redis用作緩存，則keyspace_misses應該為零或接近零。 請注意，對空鍵調用的任何阻止操作（BLPOP，BRPOP和BRPOPLPUSH）都将導緻keyspace_misses遞增。
告警名額：master_link_down_since_seconds
僅當主節點及其副本之間的連接配接丢失時，此名額才可用。 理想情況下，該值應永遠不超過零-主資料庫和副本資料庫應保持持續通信，以確定副本資料庫不提供過時的資料。 連接配接之間的較大時間間隔應得到解決。 請記住，重新連接配接後，您的主要Redis執行個體将需要投入資源來更新副本上的資料，這可能會導緻延遲增加。
結論
在本文中，我們提到了一些最有用的名額，您可以對其進行監控以在Redis伺服器上保留标簽。 如果您剛開始使用Redis，那麼監視下面的清單中的名額将使您可以很好地了解資料庫基礎架構的運作狀況和性能：
- Number of commands processed per second
- Latency
- Memory fragmentation ratio
- Evictions
- Rejected clients
最終，您将認識到與您自己的基礎結構和用例特别相關的其他名額。 當然，您要監視的内容将取決于您擁有的工具和可用的名額。