简介Redis中的showlog功能

有人这样描绘四姑娘山:四姑娘山孕育着银色冬天的梦幻,绿色春天的生命,金色秋天的希望,蓝色夏天的憧憬。四姑娘山,走进她,靠近她,你才知道什么是美,这种美带给你的是各种不同的感受,四季轮转中也无改她的美丽,四姑娘山如婉约的少女,又如豪壮的勇士,伫立在天地间,无比的圣洁,不愧是蜀山之后,东方的阿尔卑斯。

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函数:

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脚本每分钟运行一次:


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

你可以基于自己的需要将修改数字. 你的集合有多大,以及它们被删除有多频繁? 因为我们不去太过频繁的做这些类型的产出操作, 我们可以一次只进行一小块的删除操作.

不过这比直接删除更加的慢, 但它在并发的环境下却可以表现得很好.

本文简介Redis中的showlog功能到此结束。漫漫长路,荆棘丛生,待我用双手踏平。小编再次感谢大家对我们的支持!

您可能有感兴趣的文章
Redis数据结构SortedSet的底层原理解析

redis主从哨兵模式如何实现一主二从

RediSearch加RedisJSON大于Elasticsearch的搜索存储引擎

Redis如何存储对象

Redis唯一ID生成器的如何实现