redisson緩存序列化幾枚坑

1、返回值為Map<T, K> 的方法增加@Cacheable后，T和K被類型擦出了，為啥？

redisson結(jié)合Spring使用時(shí)，會(huì)有RedissonSpringCacheManager，將redissonClient自動(dòng)注入，另外還有codec的概念，即序列化和反序列化，可以查看實(shí)現(xiàn)類，就幾種實(shí)現(xiàn)，假設(shè)我們使用org.redisson.codec.JsonJacksonCodec，可以看到，decode中，僅一個(gè)Object.class，即范型信息并未帶入，故出現(xiàn)了問題

2、對(duì)于匿名內(nèi)部類的濫用導(dǎo)致反序列化失敗

你會(huì)想，匿名內(nèi)部類有什么影響？

那么跟著我看下我們時(shí)常會(huì)寫的一種Map寫法：

Map<String, Object> map = new HashMap(){{put("mykey", "test");}};

這種方式有什么問題呢，這就涉及到匿名內(nèi)部類聲明方式在實(shí)際編譯時(shí)是如何存在于class文件中的

...
$1 extends HashMap{
    ...
}
...

也就是新生成了一個(gè)匿名類型，而這個(gè)類型在反序列化時(shí)是沒辦法找到構(gòu)造函數(shù)的，故而是有問題的。

按上面寫法后，序列化時(shí)，存儲(chǔ)的是xxx$1這個(gè)匿名類型，所以反序列化也就失敗了。

redis的坑（序列化、scan）

最近做的一個(gè)項(xiàng)目用到redis，需要使用redis對(duì)數(shù)據(jù)進(jìn)行緩存，用戶的動(dòng)作也會(huì)更新redis中的數(shù)據(jù)，為了方便管理，采用了hash的方式。神坑就此開始。

最開始是序列化的坑

使用包裝的ByteArrayRedisTemplate時(shí)，對(duì)象存入redis之后，rdm可以查看到，但是程序里面取出來是亂碼，使用原生的RedisTemplate就不會(huì)出現(xiàn)這個(gè)問題，后來發(fā)現(xiàn)是對(duì)象包裝的問題，原生的RedisTemplate中支持將value設(shè)置為對(duì)象，但是包裝的ByteArrayRedisTemplate只能用byte[]，所以我這邊先把對(duì)象轉(zhuǎn)為json，然后json轉(zhuǎn)為byte[]，再寫入redis，取數(shù)據(jù)的時(shí)候，查redis的結(jié)果是byte[]，然后轉(zhuǎn)為json，再轉(zhuǎn)為對(duì)象，就沒問題了。

但是！?。〔恢朗裁丛?，這樣做之后rdm中查不到這個(gè)key了，可能是redis版本和rdm版本不兼容的問題，這個(gè)有待驗(yàn)證。你看到的一切不一定存在，你看不到的也不一定不存在，當(dāng)個(gè)碼農(nóng)還要思考這些哲學(xué)問題。。。

還有一個(gè)坑

spring整合的redis是不支持scan指令的，而且不只是scan指令，基本上所有摟全量的指令都被禁止，當(dāng)然，像keys之類的指令還是能用，但是在生產(chǎn)環(huán)境下千萬不要使用，因?yàn)楹苋菀鬃枞?，業(yè)務(wù)動(dòng)不動(dòng)就停幾秒，很尷尬。而且現(xiàn)在大部分在生產(chǎn)環(huán)境下使用的redis都是用codis包裝的，codis更絕，直接禁止使用那些指令，同志們可以自己動(dòng)手搜一下，被禁止的指令還是挺多得，我第一次看還以為自己看錯(cuò)了，尼瑪禁了一大半，摟全量的指令全部被禁。不過這樣做的好處就是數(shù)據(jù)安全，使用scan指令的漏洞撈數(shù)據(jù)的軟件也不在少數(shù)。

最后項(xiàng)目只能放棄使用redis了，因?yàn)槲冶仨毜脫俊?。。通過這個(gè)事件也懂得了，代碼開發(fā)一定要一邊開發(fā)一邊測(cè)試（自己測(cè)試），不然有的坑，掉進(jìn)去了都不知道，還在屁顛屁顛的往里刨，最后把自己埋了。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論