Redis 有一個實用的slowlog功能，正如你可以猜到的，可以讓你檢查運行緩慢的查詢. Slowlog 將會記錄運行時間超過Y微秒的最后X條查詢. X 和 Y 可以在 redis.conf 或者在運行時通過 CONFIG 命令:
 
 

進行設(shè)置。

slowlog-log-slower-than 是用來設(shè)置微秒數(shù)的, 因此上面的設(shè)置將記錄執(zhí)行時間超過5秒的查詢. 要獲取記錄的日志，你可以使用 SLOWLOG GET X 命令, 這里 X 是你想要獲取的記錄條數(shù):
 
 

它將會展示一個唯一的id，時間戳和發(fā)生的查詢，查詢執(zhí)行所花掉的時間和實際被執(zhí)行的命令+參數(shù). 你可以通過SLOWLOG RESET擦出日志.

最后一次查看slowlog，我很不淡定的看到DEL命令的執(zhí)行竟然花了超過20毫秒的時間. 還記得嗎，Redis是單線程的，因此這樣會阻塞（并且嚴重的有礙）我們系統(tǒng)的并發(fā). 還有，因為這是一個寫操作，它將會在向所有從屬Redis服務(wù)復(fù)制的時候阻塞這一復(fù)制過程. 額，到底這是咋回事呢?

也許除了我之外所有人都知道這個問題了，但是這證明了Redis的DEL命令的時間復(fù)雜度對于字符串和哈希值而言是O(1)，而對于list、set和sorted set而言則是O(N) (這里的 N 是集合中數(shù)據(jù)項的數(shù)目). 你會刪除一個包含數(shù)百萬條數(shù)據(jù)的set嗎? 那就等著阻塞吧.

我們的解決方案很簡單: 不去刪除這些數(shù)據(jù)項，而是將它們重命名，并且在后臺作業(yè)中用小而可間斷的塊去執(zhí)行對它們的刪除操作. 首先，是我們的delayed_delete函數(shù):
 

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, 但如果你使用了的話，你也應(yīng)該向其加入這方面的支持).

下一步我們安排了一個Ruby腳本每分鐘運行一次:

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

你可以基于自己的需要將修改數(shù)字. 你的集合有多大，以及它們被刪除有多頻繁? 因為我們不去太過頻繁的做這些類型的產(chǎn)出操作, 我們可以一次只進行一小塊的刪除操作.

不過這種方法比直接刪除更加的慢, 但它在并發(fā)的環(huán)境下卻可以表現(xiàn)得很好.