這篇文章主要介紹了簡介Redis中的showlog功能,作者同時對比了DEL命令的性能,需要的朋友可以參考下
Redis 有一個實用的slowlog功能,正如你可以猜到的,可以讓你檢查運行緩慢的查詢. Slowlog 將會記錄運行時間超過Y微秒的最後X條查詢. X 和 Y 可以在 redis.conf 或者在運行時通過 CONFIG 命令:
代碼如下:
CONFIG SET slowlog-log-slower-than 5000
CONFIG SET slowlog-max-len 25
進行設置。
slowlog-log-slower-than 是用來設置微秒數的, 因此上面的設置將記錄執行時間超過5秒的查詢. 要獲取記錄的日志,你可以使用 SLOWLOG GET X 命令, 這裡 X 是你想要獲取的記錄條數:
代碼如下:
SLOWLOG GET 10
它將會展示一個唯一的id,時間戳和發生的查詢,查詢執行所花掉的時間和實際被執行的命令+參數. 你可以通過SLOWLOG RESET擦出日志.
最後一次查看slowlog,我很不淡定的看到DEL命令的執行竟然花了超過20毫秒的時間. 還記得嗎,Redis是單線程的,因此這樣會阻塞(並且嚴重的有礙)我們系統的並發. 還有,因為這是一個寫操作,它將會在向所有從屬Redis服務復制的時候阻塞這一復制過程. 額,到底這是咋回事呢?
也許除了我之外所有人都知道這個問題了,但是這證明了Redis的DEL命令的時間復雜度對於字符串和哈希值而言是O(1),而對於list、set和sorted set而言則是O(N) (這裡的 N 是集合中數據項的數目). 你會刪除一個包含數百萬條數據的set嗎? 那就等著阻塞吧.
我們的解決方案很簡單: 不去刪除這些數據項,而是將它們重命名,並且在後台作業中用小而可間斷的塊去執行對它們的刪除操作. 首先,是我們的delayed_delete函數:
?
1 2 3 4 5 6 7 8 9 10 local key = KEYS[1] local data_type = redis.call('type', key).ok if data_type == 'set' or data_type == 'zset' then local temp = 'gc:tmp:' .. redis.call('incr', 'gc:ids') .. ':' .. key redis.call('rename', key, temp) return redis.call('sadd', 'gc:' .. data_type, temp) end return redis.call('del', key)這將會將集合重命名,並且將新的名稱添加到gc:set 或者 gc:zset set中 (我們沒有使用 list, 但如果你使用了的話,你也應該向其加入這方面的支持).
下一步我們安排了一個Ruby腳本每分鐘運行一次:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 require 'redis' r = Redis.new(driver: :hiredis) r.srandmember('gc:set', 10000).each do |set| items = r.srandmember(set, 5000) if items.nil? || items.length == 0 r.srem('gc:set', set) next end r.srem(set, items) end r.srandmember('gc:zset', 10000).each do |zset| if r.zremrangebyrank(zset, 0, 5000) < 5000 r.srem('gc:zset', zset) end end你可以基於自己的需要將修改數字. 你的集合有多大,以及它們被刪除有多頻繁? 因為我們不去太過頻繁的做這些類型的產出操作, 我們可以一次只進行一小塊的刪除操作.
不過這種方法比直接刪除更加的慢, 但它在並發的環境下卻可以表現得很好.