redisson緩存序列化幾枚坑

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

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

2、對于匿名內部類的濫用導致反序列化失敗

你會想，匿名內部類有什么影響？

那么跟著我看下我們時常會寫的一種Map寫法：

MapString, 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了，因為我必須得摟全量。。。通過這個事件也懂得了，代碼開發一定要一邊開發一邊測試（自己測試），不然有的坑，掉進去了都不知道，還在屁顛屁顛的往里刨，最后把自己埋了。

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。