Redis scan等命令的学习与研究

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秒.

时间复杂度的算法其实是很复杂的 中间有很多损耗, 没法单独进行运算和处理.