配运基础数据缓存瘦身实践
![]()
Tech
导读
通过redis scan命令实现对字典数据的遍历，从而对得到的数据进行处理；介绍了redis字典的几种状态：扩容后，缩容后，rehashing；探究scan命令的底层原理，如何保证字典状态变化时遍历数据的完整性。
在现代物流的实际作业流程中，会有大量关系到运营相关信息的数据产生，如商家，车队，站点，分拣中心，客户等等相关的信息数据，这些数据直接支撑起了物流的整个业务流转，具有十分重要的地位，那么对于这一类数据我们需要提供基本的增删改查存的能力。
在基础数据的常规能力当中，数据的存取是最基础也是最重要的能力，为了整体提高数据的读取能力，缓存技术在基础数据的场景中得到了广泛的使用，下面会重点展示一下配运组近期针对数据缓存做的瘦身实践。
这次优化我们挑选了商家基础资料和C后台2个系统进行了缓存数据的优化试点，从结果看取得了非常显著的成果，节省了大量的硬件资源成本，下面的数据是优化前后的缓存使用情况对比：
商家基础资料Redis数据量由45G降为8G；
C后台Redis数据量由132G降为7G；
从结果看这个优化的力度太大了，相信大家对如何实现的更加好奇了，那接下来就让我们一步步来看是如何做到的吧！
首先目前的商家基础资料使用@Cache注解组件作为缓存方式，它会将从db中查出的值放入本地缓存及jimdb中，由于该组件早期的版本没有jimdb的默认过期时间且使用注解时也未显式声明，造成早期大量的key没有过期时间，从而形成了大量的僵尸key。
所以如果我们可以找到这些僵尸key并进行优化，那么就可以将缓存进行一个整体的瘦身，那首先要怎么找出这些key呢?
可能很多同学会想到简单粗暴的keys命令，遍历出所有的key依次判断是否有过期时间，但Redis是单线程执行，keys命令会以阻塞的方式执行，遍历方式实现的复杂度是O(n)，库中的key越多，阻塞的时间会越长，通常我们的数据量都会在几十G以上，显然这种方式是无法接受的。
Redis在2.8版本提供了scan命令，相较于keys命令的优劣势如下：
优势
（1）scan命令的时间复杂度虽然也是O(N)，但它是分次进行的，不会阻塞线程；
（2）scan命令提供了类似sql中limit参数，可以控制每次返回结果的最大条数。
劣势
（1）返回的数据有可能会重复，至于原因可以看文章最后的扩展部分；
（2）scan命令只保证在命令开始执行前所有存在的key都会被遍历，在执行期间新增或删除的数据，是不确定的，即可能返回，也可能不返回。
目前看来，这是个不错的选择，让我们来看下命令的基本语法：
SCAN cursor [MATCH pattern] [COUNT count]
cursor：游标
pattern：匹配的模式
count：指定从数据集里返回多少元素，默认值为10
首先感觉上就是根据游标进行增量式迭代，让我们实际操作下：
scan 0 match * count 51) "14"2) 1) "key6"2) "key8"3) "key9"4) "key3"5) "key5"scan 14 match * count 51) "15"2) 1) "key4"2) "key2"3) "key1"4) "key7"5) "key10"scan 15 match * count 51) "0"2) (empty list or set)
根据游标进行增量式迭代的命令
看来我们只需要设置好匹配的key的前缀，循环遍历删除key即可。
可以通过Controller或者调用jsf接口来触发，使用云redis-API，demo如下：
//参数设置ScanOptions options = ScanOptions.scanOptions().match(String.format("%s*", keyPrefix)).count(10000).build();KeyScanResult<String> scanResult = jimClient.scan(null, options);//挖坑处😝while (CollectionUtils.isNotEmpty(scanResult.getResult())) {//遍历结果for (String key : scanResult.getResult()) {try {//判断是否设置过期时间Long ttl = jimClient.ttl(key);if (ttl < 0) {jimClient.del(key);logger.info("清理无用redis,keyPrefix={},key={},ttl={},删除条数={}", keyPrefix, key, ttl, succ++);}} catch (Exception e) {logger.error("清理redis异常:keyPrefix={},key={},失败次数={}", keyPrefix, key, fail++, e);}}//重新获取游标scanResult = jimClient.scan(scanResult.getCursor(), options);}
根据key前缀匹配及删除数据的源码
好的，大功告成。在管理端执行randomkey命令查看。发现依然存在大量的无用key，貌似还有不少漏网之鱼，这里又是怎么回事呢？
下面又到了喜闻乐见的踩坑环节。
通过增加日发现，返回的结果集为空，但游标并未结束！
其实不难发现scan命令跟我们在数据库中按条件分页查询是有别的：
mysql是根据条件查询出数据；
scan命令是按字典槽数依次遍历，从结果中再匹配出符合条件的数据返回给客户端，那么很有可能在多次的迭代扫描时没有符合条件的数据。
我们修改代码使用scanResult.isFinished()方法判断是否已经迭代完成。
//参数设置ScanOptions options = ScanOptions.scanOptions().match(String.format("%s*", keyPrefix)).count(10000).build();KeyScanResult<String> scanResult = jimClient.scan(null, options);while (!scanResult.isFinished()) {if (CollectionUtils.isNotEmpty(scanResult.getResult())) {//扫描结束for (String key : scanResult.getResult()) {//过期时间try {Long ttl = jimClient.ttl(key);//没有过期时间if (ttl < 0) {jimClient.del(key);logger.info("清理无用redis,keyPrefix={},key={},ttl={},删除条数={}", keyPrefix, key, ttl, succ++);}} catch (Exception e) {logger.error("清理redis异常:keyPrefix={},key={},失败次数={}", keyPrefix, key, fail++, e);}}}//重新获取游标scanResult = jimClient.scan(scanResult.getCursor(), options);}
更改迭代是否完成的判断条件
至此程序运行正常，之后通过传入不同的匹配字符，达到清除缓存的目的。
首先我们看下scan命令的遍历顺序：
127.0.0.1:6379> keys *1) "thirdKey"2) "secondKey"3) "firstKey"127.0.0.1:6379> scan 0 match * count 11) "2"2) 1) "thirdKey"127.0.0.1:6379> scan 2 match * count 11) "1"2) 1) "secondKey"127.0.0.1:6379> scan 1 match * count 11) "0"2) 1) "firstKey"127.0.0.1:6379>
查看scan命令的遍历顺序
Redis中有3个key，我们用scan命令查看发现遍历顺序为0->2->1，是不是感到奇怪，为什么不是按0->1->2的顺序？
我们都知道HashMap中由于存在hash冲突，当负载因子超过某个阈值时，出于对链表性能的考虑会进行Resize操作。Redis也一样，底层的字典表会有动态变换，这种扫描顺序也是为了应对这些复杂的场景。
3.1.1 字典表的几种状态及使用顺序扫描会出现的问题
（1）字典表没有扩容：
字段tablesize保持不变，顺序扫描没有问题。
（2）字典表已扩容完成：
图1 字典表已扩容完成
假设字典tablesize从8变为16，之前已经访问过3号桶，现在0~3号桶的数据已经rehash到8~11号桶，若果按顺序继续访问4~15号桶，那么这些元素就重复遍历了。
（3）字典表已缩容完成
图2 字典表已缩容完成
假设字典tablesize从16缩小到8，同样已经访问过3号桶，这时8~11号桶的元素被rehash到0号桶，若按顺序访问，则遍历会停止在7号桶，则这些数据就遗漏掉了。
（4）字典表正在Rehashing
Rehashing的状态则会出现以上两种问题，即要么重复扫描，要么遗漏数据。
3.1.2 反向二进制迭代器算法思想
我们将Redis扫描的游标与顺序扫描的游标转换成二进制作对比：
图3 Redis扫描的游标与顺序扫描的游标转换成二进制对比
高位顺序访问是按照字典sizemask（掩码），在有效位上高位加1。
举个例子,我们看下Scan的扫描方式：
1）字典tablesize为8，游标从0开始扫描；
2）返回客户端的游标为6后，字典tablesize扩容到之前的2倍，并且完成Rehash；
3）客户端发送命令scan 6；
图4 高位顺序访问中scan的扫描方式
这时scan命令会将6号桶中链表全部取出返回客户端，并且将当前游标的二进制高位加一计算出下次迭代的起始游标。通过上图我们可以发现扩容后8，12，10号槽位的数据是从之前0，4，2号槽位迁移过去的，这些槽位的数据已经遍历过，所以这种遍历顺序就避免了重复扫描。
字典缩容的情况类似，但重复数据的出现正是在这种情况下：
还以上图为例，再看下缩容时Scan的扫描方式：
1）字典tablesize的初始大小为16，游标从0开始扫描；
2）返回客户端的游标为14后，字典tablesize缩容到之前的1/2，并完成Rehash；
3）客户端发送命令scan 14；
这时字典表已完成缩容，之前6和14号桶的数据已经Rehash到新表的6号桶中，那14号桶都没有了，要怎么处理呢？我们继续在源码中找答案：
if (!dictIsRehashing(d)) {t0 = &(d->ht[0]);m0 = t0->sizemask;/* Emit entries at cursor */if (bucketfn) bucketfn(privdata, &t0->table[v & m0]);de = t0->table[v & m0];while (de) {next = de->next;fn(privdata, de);de = next;}/* Set unmasked bits so incrementing the reversed cursor* operates on the masked bits */v |= ~m0;/* Increment the reverse cursor */v = rev(v);v++;v = rev(v);}
redis扫描计算目标桶的源码
即在找目标桶时总是用当前hashtaba的sizemask（掩码）来计算，v=14即二进制000 1110，当前字典表的掩码从15变成了7即二进制0000 0111，v&m0的值为6，也就是说在新表上还要扫一遍6号桶。但是缩容后旧表6和14号桶的数据都已迁移到了新表的6号桶中，所以这时扫描的结果就出现了重复数据，重复的部分为上次未缩容前已扫描过的6号桶的数据。
当字典缩容时，高位桶中的数据会合并进低位桶中(6,14)->6，scan命令要保证不遗漏数据，所以要得到缩容前14号桶中的数据，要重新扫描6号桶，所以出现了重复数据。Redis也挺难的，毕竟鱼和熊掌不可兼得。