redis优化场景之批量处理
redis 查询优化–批量处理
背景
redis 在项目中是很常用的一个缓存工具,但是目前在我们系统中的一个使用场景中,竟然发现方法中执行最耗时的地方就是redis在调用get方法的时候,用 jprofile分析一下方法的执行,发现redis的这个方法被调用了上万次。是在嵌套循环中调用的。当时想着这么多网络IO肯定是不行的,咋整呢。
(图片来源网络,侵删)
突然脑袋灵光乍现,想到了redis 的keys命令,批量把redis 的缓存都拿出来放到本地,然后从本地获取。但是这样等于把redis中的内存都放到本地了,有点离谱。
redis 有一个 scan 命令,和keys命令用法相似。都有用于检索键的功能。但是有区别:
Redis 的 SCAN 命令和 KEYS 命令都有用于检索键的功能,但它们在工作原理和适用场景上有很大不同。以下是它们的主要区别:
KEYS 命令
- 功能: KEYS pattern 命令会返回与给定模式匹配的所有键。
- 性能: KEYS 命令会对 Redis 数据库进行全量扫描。对于大数据集,这可能会导致性能问题,因为它会阻塞 Redis 服务器,直到扫描完成。
- 使用场景: KEYS 适合在开发和调试过程中使用,但在生产环境中不推荐使用,特别是在数据集较大的情况下,因为它会影响 Redis 的性能。
SCAN 命令
- 功能: SCAN cursor [MATCH pattern] [COUNT count] 命令是一个基于游标的迭代器,允许逐步扫描 Redis 数据库中的键。它不会一次性返回所有匹配的键,而是通过多次调用逐步返回。
- 性能: SCAN 命令的设计目的是避免阻塞 Redis 服务器。它分批次返回结果,并在每次调用后提供一个新的游标(cursor),下次调用时使用这个游标继续扫描。因此,SCAN 命令对 Redis 服务器的性能影响较小,适合在生产环境中使用。
- 使用场景: SCAN 适合在需要逐步遍历大数据集的情况下使用,尤其是在生产环境中。它可以与其他操作并行执行,不会导致阻塞。
所以使用Scan 命令,把方法中的redis中设置的key以固定模式进行定义,比如以ESP 开头,然后用SCAN 命令,把这个ESP 开头的key拿出来,放到本地。此方法的性能问题就迎刃而解了。
代码如下
public void refreshLocalCache(Map localCache) {
String cursor = "0";
List keys = new ArrayList();
// 先循环获取所有的key
do {
Map.Entry scanResult = stringRedisTemplate.execute(
(RedisCallback) connection -> {
ScanOptions options = ScanOptions.scanOptions().match("ESP*").count(1000).build();
Cursor cursor1 = connection.scan(options);
Set keysSet = new HashSet();
while (cursor1.hasNext()) {
keysSet.add(cursor1.next());
}
return Map.entry(String.valueOf(cursor1.getCursorId()), keysSet);
});
if (scanResult != null) {
cursor = scanResult.getKey();
Set keysSet = scanResult.getValue();
if (keysSet != null && !keysSet.isEmpty()) {
for (byte[] key : keysSet) {
keys.add(new String(key, StandardCharsets.UTF_8));
}
}
}
} while (!"0".equals(cursor));
// 使用 multiGet 批量获取key对象的value
List values = stringRedisTemplate.opsForValue().multiGet(keys);
if (values != null) {
for (int i = 0; i
思路就是:
1、 使用sacn 命令,先拿到这个esp开头的所有的key
2、使用multiGet 批量拿到这些key的value值
3、把这一批的缓存放到本地,后续方法从本地缓存中拿到缓存值。
主打一个减少网络请求
免责声明:我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理! 图片声明:本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库和百度,360,搜狗等多加搜索引擎自动关键词搜索配图,如有侵权的图片,请第一时间联系我们,邮箱:ciyunidc@ciyunshuju.com。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!
