Redis優化

Usher_Ou 2022-01-08 03:15:14 阅读数:106

redis

Redis作為內存數據庫,擁有非常高的性能,單個實例的QPS能够達到10W左右。但我們在使用Redis時,經常時不時會出現訪問延遲很大的情况,如果你不知道Redis的內部實現原理,在排查問題時就會一頭霧水。

很多時候,Redis出現訪問延遲變大,都與我們的使用不當或運維不合理導致的。

這篇文章我們就來分析一下Redis在使用過程中,經常會遇到的延遲問題以及如何定比特和分析。

使用複雜度高的命令

如果在使用Redis時,發現訪問延遲突然增大,如何進行排查?

首先,第一步,建議你去查看一下Redis的慢日志。Redis提供了慢日志命令的統計功能,我們通過以下設置,就可以查看有哪些命令在執行時延遲比較大。

首先設置Redis的慢日志閾值,只有超過閾值的命令才會被記錄,這裏的單比特是微秒,例如設置慢日志的閾值為5毫秒,同時設置只保留最近1000條慢日志記錄:

# 命令執行超過5毫秒記錄慢日志CONFIG SET slowlog-log-slower-than 5000# 只保留最近1000條慢日志CONFIG SET slowlog-max-len 1000

設置完成之後,所有執行的命令如果延遲大於5毫秒,都會被Redis記錄下來,我們執行SLOWLOG get 5查詢最近5條慢日志

127.0.0.1:6379> SLOWLOG get51)1)(integer)32693# 慢日志ID2)(integer)1593763337# 執行時間3)(integer)5299# 執行耗時(微秒)4)1)"LRANGE"# 具體執行的命令和參數2)"user_list_2000"3)"0"4)"-1"2)1)(integer)326922)(integer)15937633373)(integer)50444)1)"GET"2)"book_price_1000"...

通過查看慢日志記錄,我們就可以知道在什麼時間執行哪些命令比較耗時,如果你的業務經常使用O(n)以上複雜度的命令,例如sort、sunion、zunionstore,或者在執行O(n)命令時操作的數據量比較大,這些情况下Redis處理數據時就會很耗時。

如果你的服務請求量並不大,但Redis實例的CPU使用率很高,很有可能是使用了複雜度高的命令導致的。

解决方案就是,不使用這些複雜度較高的命令,並且一次不要獲取太多的數據,每次盡量操作少量的數據,讓Redis可以及時處理返回。

存儲大key

如果查詢慢日志發現,並不是複雜度較高的命令導致的,例如都是SET、DELETE操作出現在慢日志記錄中,那麼你就要懷疑是否存在Redis寫入了大key的情况。

Redis在寫入數據時,需要為新的數據分配內存,當從Redis中删除數據時,它會釋放對應的內存空間。

如果一個key寫入的數據非常大,Redis在分配內存時也會比較耗時。同樣的,當删除這個key的數據時,釋放內存也會耗時比較久。

你需要檢查你的業務代碼,是否存在寫入大key的情况,需要評估寫入數據量的大小,業務層應該避免一個key存入過大的數據量。

那麼有沒有什麼辦法可以掃描現在Redis中是否存在大key的數據嗎?

Redis也提供了掃描大key的方法:

redis-cli -h $host -p $port --bigkeys -i 0.01

使用上面的命令就可以掃描出整個實例key大小的分布情况,它是以類型維度來展示的。

需要注意的是當我們在線上實例進行大key掃描時,Redis的QPS會突增,為了降低掃描過程中對Redis的影響,我們需要控制掃描的頻率,使用-i參數控制即可,它錶示掃描過程中每次掃描的時間間隔,單比特是秒。

使用這個命令的原理,其實就是Redis在內部執行scan命令,遍曆所有key,然後針對不同類型的key執行strlen、llen、hlen、scard、zcard來獲取字符串的長度以及容器類型(list/dict/set/zset)的元素個數。

而對於容器類型的key,只能掃描出元素最多的key,但元素最多的key不一定占用內存最多,這一點需要我們注意下。不過使用這個命令一般我們是可以對整個實例中key的分布情况有比較清晰的了解。

針對大key的問題,Redis官方在4.0版本推出了lazy-free的機制,用於异步釋放大key的內存,降低對Redis性能的影響。即使這樣,我們也不建議使用大key,大key在集群的遷移過程中,也會影響到遷移的性能,這個後面在介紹集群相關的文章時,會再詳細介紹到。

集中過期

有時你會發現,平時在使用Redis時沒有延時比較大的情况,但在某個時間點突然出現一波延時,而且報慢的時間點很有規律,例如某個整點,或者間隔多久就會發生一次。

如果出現這種情况,就需要考慮是否存在大量key集中過期的情况。

如果有大量的key在某個固定時間點集中過期,在這個時間點訪問Redis時,就有可能導致延遲增加。

Redis的過期策略采用主動過期+懶惰過期兩種策略:

•主動過期:Redis內部維護一個定時任務,默認每隔100毫秒會從過期字典中隨機取出20個key,删除過期的key,如果過期key的比例超過了25%,則繼續獲取20個key,删除過期的key,循環往複,直到過期key的比例下降到25%或者這次任務的執行耗時超過了25毫秒,才會退出循環

•懶惰過期:只有當訪問某個key時,才判斷這個key是否已過期,如果已經過期,則從實例中删除

注意,Redis的主動過期的定時任務,也是在Redis主線程中執行的,也就是說如果在執行主動過期的過程中,出現了需要大量删除過期key的情况,那麼在業務訪問時,必須等這個過期任務執行結束,才可以處理業務請求。此時就會出現,業務訪問延時增大的問題,最大延遲為25毫秒。

而且這個訪問延遲的情况,不會記錄在慢日志裏。慢日志中只記錄真正執行某個命令的耗時,Redis主動過期策略執行在操作命令之前,如果操作命令耗時達不到慢日志閾值,它是不會計算在慢日志統計中的,但我們的業務卻感到了延遲增大。

此時你需要檢查你的業務,是否真的存在集中過期的代碼,一般集中過期使用的命令是expireat或pexpireat命令,在代碼中搜索這個關鍵字就可以了。

如果你的業務確實需要集中過期掉某些key,又不想導致Redis發生抖動,有什麼優化方案?

解决方案是,在集中過期時增加一個隨機時間,把這些需要過期的key的時間打散即可。

偽代碼可以這麼寫:

# 在過期時間點之後的5分鐘內隨機過期掉redis.expireat(key, expire_time + random(300))

這樣Redis在處理過期時,不會因為集中删除key導致壓力過大,阻塞主線程。

另外,除了業務使用需要注意此問題之外,還可以通過運維手段來及時發現這種情况。

做法是我們需要把Redis的各項運行數據監控起來,執行info可以拿到所有的運行數據,在這裏我們需要重點關注expired_keys這一項,它代錶整個實例到目前為止,累計删除過期key的數量。

我們需要對這個指標監控,當在很短時間內這個指標出現突增時,需要及時報警出來,然後與業務報慢的時間點對比分析,確認時間是否一致,如果一致,則可以認為確實是因為這個原因導致的延遲增大。

實例內存達到上限

有時我們把Redis當做純緩存使用,就會給實例設置一個內存上限maxmemory,然後開啟LRU淘汰策略。

當實例的內存達到了maxmemory後,你會發現之後的每次寫入新的數據,有可能變慢了。

導致變慢的原因是,當Redis內存達到maxmemory後,每次寫入新的數據之前,必須先踢出一部分數據,讓內存維持在maxmemory之下。

這個踢出舊數據的邏輯也是需要消耗時間的,而具體耗時的長短,要取决於配置的淘汰策略:

•allkeys-lru:不管key是否設置了過期,淘汰最近最少訪問的key

•volatile-lru:只淘汰最近最少訪問並設置過期的key

•allkeys-random:不管key是否設置了過期,隨機淘汰

•volatile-random:只隨機淘汰有設置過期的key

•allkeys-ttl:不管key是否設置了過期,淘汰即將過期的key

•noeviction:不淘汰任何key,滿容後再寫入直接報錯

•allkeys-lfu:不管key是否設置了過期,淘汰訪問頻率最低的key(4.0+支持)

•volatile-lfu:只淘汰訪問頻率最低的過期key(4.0+支持)

備注:allkeys-xxx錶示從所有的鍵值中淘汰數據,而volatile-xxx錶示從設置了過期鍵的鍵值中淘汰數據。

具體使用哪種策略,需要根據業務場景來决定。

我們最常使用的一般是allkeys-lru或volatile-lru策略,它們的處理邏輯是,每次從實例中隨機取出一批key(可配置),然後淘汰一個最少訪問的key,之後把剩下的key暫存到一個池子中,繼續隨機取出一批key,並與之前池子中的key比較,再淘汰一個最少訪問的key。以此循環,直到內存降到maxmemory之下。

如果使用的是allkeys-random或volatile-random策略,那麼就會快很多,因為是隨機淘汰,那麼就少了比較key訪問頻率時間的消耗了,隨機拿出一批key後直接淘汰即可,因此這個策略要比上面的LRU策略執行快一些。

但以上這些邏輯都是在訪問Redis時,真正命令執行之前執行的,也就是它會影響我們訪問Redis時執行的命令。

另外,如果此時Redis實例中有存儲大key,那麼在淘汰大key釋放內存時,這個耗時會更加久,延遲更大,這需要我們格外注意。

如果你的業務訪問量非常大,並且必須設置maxmemory限制實例的內存上限,同時面臨淘汰key導致延遲增大的的情况,要想緩解這種情况,除了上面說的避免存儲大key、使用隨機淘汰策略之外,也可以考慮拆分實例的方法來緩解,拆分實例可以把一個實例淘汰key的壓力分攤到多個實例上,可以在一定程度降低延遲。

fork耗時嚴重

如果你的Redis開啟了自動生成RDB和AOF重寫功能,那麼有可能在後臺生成RDB和AOF重寫時導致Redis的訪問延遲增大,而等這些任務執行完畢後,延遲情况消失。

遇到這種情况,一般就是執行生成RDB和AOF重寫任務導致的。

生成RDB和AOF都需要父進程fork出一個子進程進行數據的持久化,在fork執行過程中,父進程需要拷貝內存頁錶給子進程,如果整個實例內存占用很大,那麼需要拷貝的內存頁錶會比較耗時,此過程會消耗大量的CPU資源,在完成fork之前,整個實例會被阻塞住,無法處理任何請求,如果此時CPU資源緊張,那麼fork的時間會更長,甚至達到秒級。這會嚴重影響Redis的性能。

我們可以執行info命令,查看最後一次fork執行的耗時latest_fork_usec,單比特微秒。這個時間就是整個實例阻塞無法處理請求的時間。

除了因為備份的原因生成RDB之外,在主從節點第一次建立數據同步時,主節點也會生成RDB文件給從節點進行一次全量同步,這時也會對Redis產生性能影響。

要想避免這種情况,我們需要規劃好數據備份的周期,建議在從節點上執行備份,而且最好放在低峰期執行。如果對於丟失數據不敏感的業務,那麼不建議開啟AOF和AOF重寫功能。

另外,fork的耗時也與系統有關,如果把Redis部署在虛擬機上,那麼這個時間也會增大。所以使用Redis時建議部署在物理機上,降低fork的影響。

綁定CPU

很多時候,我們在部署服務時,為了提高性能,降低程序在使用多個CPU時上下文切換的性能損耗,一般會采用進程綁定CPU的操作。

但在使用Redis時,我們不建議這麼幹,原因如下:

綁定CPU的Redis,在進行數據持久化時,fork出的子進程,子進程會繼承父進程的CPU使用偏好,而此時子進程會消耗大量的CPU資源進行數據持久化,子進程會與主進程發生CPU爭搶,這也會導致主進程的CPU資源不足訪問延遲增大。

所以在部署Redis進程時,如果需要開啟RDB和AOF重寫機制,一定不能進行CPU綁定操作!

開啟AOF

上面提到了,當執行AOF文件重寫時會因為fork執行耗時導致Redis延遲增大,除了這個之外,如果開啟AOF機制,設置的策略不合理,也會導致性能問題。

開啟AOF後,Redis會把寫入的命令實時寫入到文件中,但寫入文件的過程是先寫入內存,等內存中的數據超過一定閾值或達到一定時間後,內存中的內容才會被真正寫入到磁盤中。

AOF為了保證文件寫入磁盤的安全性,提供了3種刷盤機制:

•appendfsync always:每次寫入都刷盤,對性能影響最大,占用磁盤IO比較高,數據安全性最高

•appendfsync everysec:1秒刷一次盤,對性能影響相對較小,節點宕機時最多丟失1秒的數據

•appendfsync no:按照操作系統的機制刷盤,對性能影響最小,數據安全性低,節點宕機丟失數據取决於操作系統刷盤機制

當使用第一種機制appendfsync always時,Redis每處理一次寫命令,都會把這個命令寫入磁盤,而且這個操作是在主線程中執行的。

內存中的的數據寫入磁盤,這個會加重磁盤的IO負擔,操作磁盤成本要比操作內存的代價大得多。如果寫入量很大,那麼每次更新都會寫入磁盤,此時機器的磁盤IO就會非常高,拖慢Redis的性能,因此我們不建議使用這種機制。

與第一種機制對比,appendfsync everysec會每隔1秒刷盤,而appendfsync no取决於操作系統的刷盤時間,安全性不高。因此我們推薦使用appendfsync everysec這種方式,在最壞的情况下,只會丟失1秒的數據,但它能保持較好的訪問性能。

當然,對於有些業務場景,對丟失數據並不敏感,也可以不開啟AOF。

使用Swap

如果你發現Redis突然變得非常慢,每次訪問的耗時都達到了幾百毫秒甚至秒級,那此時就檢查Redis是否使用到了Swap,這種情况下Redis基本上已經無法提供高性能的服務。

我們知道,操作系統提供了Swap機制,目的是為了當內存不足時,可以把一部分內存中的數據換到磁盤上,以達到對內存使用的緩沖。

但當內存中的數據被換到磁盤上後,訪問這些數據就需要從磁盤中讀取,這個速度要比內存慢太多!

尤其是針對Redis這種高性能的內存數據庫來說,如果Redis中的內存被換到磁盤上,對於Redis這種性能極其敏感的數據庫,這個操作時間是無法接受的。

我們需要檢查機器的內存使用情况,確認是否確實是因為內存不足導致使用到了Swap。

如果確實使用到了Swap,要及時整理內存空間,釋放出足够的內存供Redis使用,然後釋放Redis的Swap,讓Redis重新使用內存。

釋放Redis的Swap過程通常要重啟實例,為了避免重啟實例對業務的影響,一般先進行主從切換,然後釋放舊主節點的Swap,重新啟動服務,待數據同步完成後,再切換回主節點即可。

可見,當Redis使用到Swap後,此時的Redis的高性能基本被廢掉,所以我們需要提前預防這種情况。

我們需要對Redis機器的內存和Swap使用情况進行監控,在內存不足和使用到Swap時及時報警出來,及時進行相應的處理。

網卡負載過高

如果以上產生性能問題的場景,你都規避掉了,而且Redis也穩定運行了很長時間,但在某個時間點之後開始,訪問Redis開始變慢了,而且一直持續到現在,這種情况是什麼原因導致的?

之前我們就遇到這種問題,特點就是從某個時間點之後就開始變慢,並且一直持續。這時你需要檢查一下機器的網卡流量,是否存在網卡流量被跑滿的情况。

網卡負載過高,在網絡層和TCP層就會出現數據發送延遲、數據丟包等情况。Redis高性能除了內存之外,就在於網絡IO,請求量突增會導致網卡負載變高。

如果出現這種情况,你需要排查這個機器上的哪個Redis實例的流量過大占滿了網絡帶寬,然後確認流量突增是否屬於業務正常情况,如果屬於那就需要及時擴容或遷移實例,避免這個機器的其他實例受到影響。

運維層面,我們需要對機器的各項指標增加監控,包括網絡流量,在達到閾值時提前報警,及時與業務確認並擴容。

總結

以上我們總結了Redis中常見的可能導致延遲增大甚至阻塞的場景,這其中既涉及到了業務的使用問題,也涉及到Redis的運維問題。

可見,要想保證Redis高性能的運行,其中涉及到CPU、內存、網絡,甚至磁盤的方方面面,其中還包括操作系統的相關特性的使用。

作為開發人員,我們需要了解Redis的運行機制,例如各個命令的執行時間複雜度、數據過期策略、數據淘汰策略等,使用合理的命令,並結合業務場景進行優化。

作為DBA運維人員,需要了解數據持久化、操作系統fork原理、Swap機制等,並對Redis的容量進行合理規劃,預留足够的機器資源,對機器做好完善的監控,才能保證Redis的穩定運行

版权声明:本文为[Usher_Ou]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201080315143883.html