关于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了，因为我必须得搂全量。。。通过这个事件也懂得了，代码开发一定要一边开发一边测试（自己测试），不然有的坑，掉进去了都不知道，还在屁颠屁颠的往里刨，最后把自己埋了。