共计 2942 个字符，预计需要花费 8 分钟才能阅读完成。
作者：京东物流 张仲良
一、背景:
在古代物流的理论作业流程中，会有大量关系到经营相干信息的数据产生，如商家，车队，站点，分拣核心，客户等等相干的信息数据，这些数据间接撑持齐了物流的整个业务流转，具备非常重要的位置，那么对于这一类数据咱们须要提供根本的增删改查存的能力，目前京东物流的根底数据是由中台配运组来整体负责。
在根底数据的惯例能力当中，数据的存取是最根底也是最重要的能力，为了整体进步数据的读取能力，缓存技术在根底数据的场景中失去了宽泛的应用，上面会重点展现一下配运组近期针对数据缓存做的瘦身实际。
二、计划:
这次优化咱们筛选了商家根底材料和 C 后盾 2 个零碎进行了缓存数据的优化试点，从后果看获得了十分显著的成绩，节俭了大量的硬件资源老本，上面的数据是优化前后的缓存应用状况比照：
商家根底材料 Redis 数据量由 45G 降为 8G;
C 后盾 Redis 数据量由 132G 降为 7G;
从后果看这个优化的力度太大了，置信大家对如何实现的更加好奇了，那接下来就让咱们一步步来看是如何做到的吧！
首先目前的商家根底材料应用 @Caceh 注解组件作为缓存形式，它会将从 db 中查出的值放入本地缓存及 jimdb 中，因为该组件晚期的版本没有 jimdb 的默认过期工夫且应用注解时也未显式申明，造成晚期大量的 key 没有过期工夫，从而造成了大量的僵尸 key。
所以如果咱们能够找到这些僵尸 key 并进行优化，那么就能够将缓存进行一个整体的瘦身，那首先要怎么找出这些 key 呢?
2.1 keys 命令
可能很多同学会想到简略粗犷的 keys 命令, 遍历出所有的 key 顺次判断是否有过期工夫, 但 Redis 是单线程执行,keys 命令会以阻塞的形式执行, 遍历形式实现的复杂度是 O(n), 库中的 key 越多, 阻塞的工夫会越长, 通常咱们的数据量都会在几十 G 以上, 显然这种形式是无奈承受的。
2.2 scan 命令
redis 在 2.8 版本提供了 scan 命令, 相较于 keys 命令的劣势:
- scan 命令的工夫复杂度尽管也是 O(N)，但它是分次进行的，不会阻塞线程。
- scan 命令提供了相似 sql 中 limit 参数，能够管制每次返回后果的最大条数。
当然也有毛病:
- 返回的数据有可能会反复, 至于起因能够看文章最初的扩大局部。
- scan 命令只保障在命令开始执行前所有存在的 key 都会被遍历, 在执行期间新增或删除的数据, 是不确定的即可能返回, 也可能不返回。
2.3 根本语法
目前看来这是个不错的抉择, 让咱们来看下命令的根本语法:
SCAN cursor [MATCH pattern] [COUNT count]
- cursor：游标
- pattern：匹配的模式
- count：指定从数据集里返回多少元素，默认值为 10
2.4 实际
首先感觉上就是依据游标进行增量式迭代, 让咱们实际操作下:
看来咱们只须要设置好匹配的 key 的前缀, 循环遍历删除 key 即可。
能够通过 Controller 或者调用 jsf 接口来触发, 应用云 redis-API,demo 如下:
好的, 功败垂成. 在治理端执行 randomkey 命令查看. 发现仍然存在大量的无用 key, 貌似还有不少漏网之鱼, 这里又是怎么回事呢？
上面又到了脍炙人口的踩坑环节。
2.5 避坑指南
通过减少日发现, 返回的后果集为空, 但游标并未完结!
其实不难发现 scan 命令跟咱们在数据库中按条件分页查问是有别的,mysql 是依据条件查问出数据,scan 命令是按字典槽数顺次遍历, 从后果中再匹配出符合条件的数据返回给客户端, 那么很有可能在屡次的迭代扫描时没有符合条件的数据。
咱们批改代码应用 scanResult.isFinished()办法判断是否曾经迭代实现。
至此程序运行失常, 之后通过传入不同的匹配字符, 达到分明缓存的目标。
三、课后扩大
这里咱们探讨反复数据的问题: 为什么遍历出的数据可能会反复?
3.1 反复的数据
首先咱们看下 scan 命令的遍历程序:
Redis 中有 3 个 key, 咱们用 scan 命令查看发现遍历顺为 0 ->2->1->3, 是不是感到奇怪, 为什么不是按 0 ->1->2->3 的程序?
咱们都晓得 HashMap 中因为存在 hash 抵触, 当负载因子超过某个阈值时, 出于对链表性能的思考会进行 Resize 操作.Redis 也一样, 底层的字典表会有动静变换, 这种扫描程序也是为了应答这些简单的场景。
3.1.1 字典表的几种状态及应用程序扫描会呈现的问题
- 字典表没有扩容
字段 tablesize 放弃不变, 程序扫描没有问题 - 字典表已扩容实现
假如字典 tablesize 从 8 变为 16, 之前曾经拜访过 3 号桶, 当初 0~3 号桶的数据曾经 rehash 到 8~11 号桶, 若果按程序持续拜访 4~15 号桶, 那么这些元素就反复遍历了。
- 字典表已缩容实现
假如字典 tablesize 从 16 放大到 8, 同样曾经拜访过 3 号桶, 这时 8~11 号桶的元素被 rehash 到 0 号桶, 若按程序拜访, 则遍历会进行在 7 号桶, 则这些数据就遗漏掉了。
- 字典表正在 Rehashing
Rehashing 的状态则会呈现以上两种问题即要么反复扫描, 要么脱漏数据。
3.1.2 反向二进制迭代器算法思维
咱们将 Redis 扫描的游标与程序扫描的游标转换成二进制作比照:
高位程序拜访是依照字典 sizemask(掩码), 在无效位上高位加 1。
举个例子, 咱们看下 Scan 的扫描形式:
1. 字典 tablesize 为 8, 游标从 0 开始扫描;
2. 返回客户端的游标为 6 后, 字典 tablesize 扩容到之前的 2 倍, 并且实现 Rehash;
3. 客户端发送命令 scan 6;
这时 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 号桶都没有了, 要怎么解决呢? 咱们持续在源码中找答案:
即在找指标桶时总是用以后 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 也挺难的, 毕竟鱼和熊掌不可兼得。**
总结
通过本次 Redis 瘦身实际, 尽管是个很小的工具, 但的确带来的显著的成果, 节约资源降低成本, 并且在排查问题中又学习到了命令底层奇妙的设计思维, 收货颇丰, 最初欢送感兴趣的小伙伴一起交换提高。
