正文
Redis scan等命令的学习与研究
摘要
背景跟前几天说的一个问题类似.
为了验证自己的设想, 所以晚上继续写脚本进行了一轮次的验证.
不过上次讨论时,打击好像都没听懂我说的
所以这次准备从基础开始讲起.
很多好东西在上来量之后可能会变成坏东西
scan 命令
Redis 在2.8 之后增加了scan命令.
其实scan命令是为了解决keys 命令一次全部键值对扫描导致的O(n)时间复杂度而来.
keys zhaobsh* 会递归查寻所有的键值对, 返回前缀是 zhaobsh的键值对信息.
scan 0 match zhaobsh* count 10000
scan命令仅会在count范围内的键值对进行匹配, 匹配完成后返回键值对信息.
表面上看起来scan是避免了keys 键值对全部扫描的性能损耗, 在大量key的情况下避免太大的延迟.
但是scan 是存在一个游标的.
第一次count范围内 匹配完不仅要返回配置的键值对, 还要返回下一个测试使用的游标.
所以在monitor的命令里面. SCAN 0 为特征, 是一组scan命令.
其他的都会根据scan 0 返回的游标进行递归查询, 理论上 count 10000 时, 有多少万个键值对.
就有有多少个 scan命令数(键值对数量向上取整)
我这边也进行了一定程度的学习与研究
scan 之间会插入一些命令.
通过monitor 监控 scan 非0游标之间的命令数就可以发现.
但是scan命令也是存在一个比keys 命令要差的地方
keys 会直接返回最终的结果, 命令交互也少
scan 命令会多次执行交互, 最终返回结果
scan 仅是避免了被长久的阻塞, 但是实际上他会使用更多的CPU时间和周期来进行键值对查找.
del unlink 命令
del 命令其实比较简单, 就是直接进行了一次 删除
时间复杂度也是 O(1)
但是删除命令 是需要释放内存的.
如果是一个大的key 内存清理也比较费时.
为了提高性能 redis 4.0 时增加了unlink的方法
1：del和unlink的最大区别是del是同步删除，unlink是异步删除
2：对于线上使用删除的尽量不要使用del，因为同步删除可能会造成本身服务停顿，特别是业务量特别依赖redis的服务。
3：redis的value删除之后的内存回收使用的引用计算器算法。
其实不建议进行 del del 同步删除, 尤其是 大key时会有较久的时间等待.
现在del的命令其实很多, 改成unlink 其实也有风险
这里简单做一下实验
先插入1000万key
然后在执行 1000万个unlink的处理.
查看内存情况.
插入完的情况为:
used_memory:857426752
used_memory_human:817.71M
allocator_frag_ratio:1.00
allocator_frag_bytes:3140072
注意 此时我的内存策略为:
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
执行完 unlink的情况为:
used_memory:3216848
used_memory_human:3.07M
mem_fragmentation_ratio:19.43
mem_fragmentation_bytes:58503480
会发现会慢慢的 碎片率会慢慢的下降.
一万个 set 耗时 19秒
一万个 unlink 耗时 18秒
一万个 del 耗时 10秒
关于scan的研究
scan 会有一个间隙执行命令的操作
通过这个间隙, 可以将业务命令添加到redis进行执行.
这种情况下间隙之间执行的命令, 可以进行业务操作与处理.
但是如果scan太多, 可能导致执行命令的管道被scan命令阻塞.
出现耗时严重的问题
关于redis的时间复杂度
1. Redis在进行benchmark压测时能够发现, 可以支撑10万级别的IOPS
换算出来 10微秒执行一个命令
2. 但是我理解这个10微秒, 在redis核心进程中的时间其实很短,估计只有1微秒左右.
其他的时间其实是网络栈交互等等操作.
3. 如果scan的命令数较大,就会发现他的 slowlog 大概是每一万个key 10毫秒
如果是10000万个key 执行 keys * 的耗时为 3.35秒 scan是11秒.
时间复杂度的算法其实是很复杂的 中间有很多损耗, 没法单独进行运算和处理.
