关于redisson缓存序列化的几枚大坑说明
redisson缓存序列化几枚坑
1、返回值为Map<T, K> 的方法增加@Cacheable后,T和K被类型擦出了,为啥?
redisson结合Spring使用时,会有RedissonSpringCacheManager,将redissonClient自动注入,另外还有codec的概念,即序列化和反序列化,可以查看实现类,就几种实现,假设我们使用org.redisson.codec.JsonJacksonCodec,可以看到,decode中,仅一个Object.class,即范型信息并未带入,故出现了问题
2、对于匿名内部类的滥用导致反序列化失败
你会想,匿名内部类有什么影响?
那么跟着我看下我们时常会写的一种Map写法:
Map<String, Object> map = new HashMap(){{put("mykey", "test");}};
这种方式有什么问题呢,这就涉及到匿名内部类声明方式在实际编译时是如何存在于class文件中的
... $1 extends HashMap{ ... } ...
也就是新生成了一个匿名类型,而这个类型在反序列化时是没办法找到构造函数的,故而是有问题的。
按上面写法后,序列化时,存储的是xxx$1这个匿名类型,所以反序列化也就失败了。
redis的坑(序列化、scan)
最近做的一个项目用到redis,需要使用redis对数据进行缓存,用户的动作也会更新redis中的数据,为了方便管理,采用了hash的方式。神坑就此开始。
最开始是序列化的坑
使用包装的ByteArrayRedisTemplate时,对象存入redis之后,rdm可以查看到,但是程序里面取出来是乱码,使用原生的RedisTemplate就不会出现这个问题,后来发现是对象包装的问题,原生的RedisTemplate中支持将value设置为对象,但是包装的ByteArrayRedisTemplate只能用byte[],所以我这边先把对象转为json,然后json转为byte[],再写入redis,取数据的时候,查redis的结果是byte[],然后转为json,再转为对象,就没问题了。
但是!!!不知道什么原因,这样做之后rdm中查不到这个key了,可能是redis版本和rdm版本不兼容的问题,这个有待验证。你看到的一切不一定存在,你看不到的也不一定不存在,当个码农还要思考这些哲学问题。。。
还有一个坑
spring整合的redis是不支持scan指令的,而且不只是scan指令,基本上所有搂全量的指令都被禁止,当然,像keys之类的指令还是能用,但是在生产环境下千万不要使用,因为很容易阻塞,业务动不动就停几秒,很尴尬。而且现在大部分在生产环境下使用的redis都是用codis包装的,codis更绝,直接禁止使用那些指令,同志们可以自己动手搜一下,被禁止的指令还是挺多得,我第一次看还以为自己看错了,尼玛禁了一大半,搂全量的指令全部被禁。不过这样做的好处就是数据安全,使用scan指令的漏洞捞数据的软件也不在少数。
最后项目只能放弃使用redis了,因为我必须得搂全量。。。通过这个事件也懂得了,代码开发一定要一边开发一边测试(自己测试),不然有的坑,掉进去了都不知道,还在屁颠屁颠的往里刨,最后把自己埋了。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。