一次線上Redis類轉換異常排查引發的思考

之前同事反饋說線上遇到Redis反序列化異常問題，異常如下：

XxxClass1 cannot be cast to XxxClass2

已知資訊如下：

• 該異常不是必現的，偶爾才會出現；
• 出現該異常後重啟應用或者過一會就好了；
• 序列化協議使用了hessian。

因為偶爾出現，首先看了報異常那塊業務邏輯是不是有問題，看了一遍也發現什麼問題。看了下對應日誌，發現是在Redis讀超時之後才出現的該異常，因此懷疑redis client操作邏輯那塊導致的（公司架構組對redis做了一層封裝），發現獲取/釋放redis連線如下程式碼：

try {
    jedis = jedisPool.getResource();
    // jedis業務讀寫操作
} catch (Exception e) {
    // 異常處理
} finally {
    if (jedis != null) {
        // 歸還給連線池
        jedisPool.returnResourceObject(jedis);
    }
}

初步認定原因為：發生了讀寫超時的連線，直接歸還給連線池，下次使用該連線時讀取到了上一次Redis返回的資料。因此本地驗證下，示例程式碼如下：

@Data
@NoArgsConstructor
@AllArgsConstructor
static class Person implements Serializable {
    private String name;
    private int age;
}
@Data
@NoArgsConstructor
@AllArgsConstructor
static class Dog implements Serializable {
    private String name;
}

public static void main(String[] args) throws Exception {
    JedisPoolConfig config = new JedisPoolConfig();
    config.setMaxTotal(1);
    JedisPool jedisPool = new JedisPool(config, "192.168.193.133", 6379, 2000, "123456");

    Jedis jedis = jedisPool.getResource();
    jedis.set("key1".getBytes(), serialize(new Person("luoxn28", 26)));
    jedis.set("key2".getBytes(), serialize(new Dog("tom")));
    jedisPool.returnResourceObject(jedis);

    try {
        jedis = jedisPool.getResource();
        Person person = deserialize(jedis.get("key1".getBytes()), Person.class);
        System.out.println(person);
    } catch (Exception e) {
        // 發生了異常之後，未對該連線做任何處理
        System.out.println(e.getMessage());
    } finally {
        if (jedis != null) {
            jedisPool.returnResourceObject(jedis);
        }
    }

    try {
        jedis = jedisPool.getResource();
        Dog dog = deserialize(jedis.get("key2".getBytes()), Dog.class);
        System.out.println(dog);
    } catch (Exception e) {
        System.out.println(e.getMessage());
    } finally {
        if (jedis != null) {
            jedisPool.returnResourceObject(jedis);
        }
    }
}

連線超時時間設定2000ms，為了方便測試，可以在redis伺服器上使用gdb命令斷住redis程式（如果redis部署在Linux系統上的話，還可以使用iptable命令在防火牆禁止某個回包），比如在執行 jedis.get("key1".getBytes() 程式碼前，對redis程式使用gdb命令斷住，那麼就會導致讀取超時，然後就會觸發如下異常：

Person cannot be cast to Dog

既然已經知道了該問題原因並且本地復現了該問題，對應解決方案是，在發生異常時歸還給連線池時關閉該連線即可(jedis.close內部已經做了判斷)，程式碼如下：

try {
    jedis = jedisPool.getResource();
    // jedis業務讀寫操作
} catch (Exception e) {
    // 異常處理
} finally {
    if (jedis != null) {
        // 歸還給連線池
        jedis.close();
    }
}

至此，該問題解決。注意，因為使用了hessian序列化（其包含了型別資訊，類似的有Java本身序列化機制），所有會報類轉換異常；如果使用了json序列化（其只包含物件屬性資訊），反序列化時不會報異常，只不過因為不同類的屬性不同，會導致反序列化後的物件屬性為空或者屬性值混亂，使用時會導致問題，並且這種問題因為沒有報異常所以更不容易發現。

 

既然說到了Redis的連線，要知道的是，Redis基於RESP(Redis Serialization Protocol)協議來通訊，並且通訊方式是停等方式，也就說一次通訊獨佔一個連線直到client讀取到返回結果之後才能釋放該連線讓其他執行緒使用。小夥伴們可以思考一下，Redis通訊能否像dubbo那樣使用單連線+序列號（標識單次通訊）通訊方式呢？理論上是可以的，不過由於RESP協議中並沒有一個"序列號"的欄位，所以直接靠原生的通訊方法來實現是不現實的。不過我們可以通過echo命令傳遞並返回"序列號"+正常的讀寫方式來實現，這裡要保證二者執行的原子性，可以通過lua指令碼或者事務來實現，事務方式如下：

MULTI
ECHO "唯一序列號"
GET key1
EXEC

然後客戶端收到的結果是一個 [ "唯一序列號", "value1" ]的列表，你可以根據前一項識別出這是你傳送的哪個請求。

為什麼Redis通訊方式並沒有採用類似於dubbo這種通訊方式呢，個人認為有以下幾點：

• 使用停等這種通訊方式實現簡單，並且協議欄位儘可能緊湊；
• Redis都是記憶體操作，處理效能較強，停等協議不會造成客戶端等待時間較長；
• 目前來看，通訊方式這塊不是Redis使用上的效能瓶頸，這一點很重要。

 

推薦閱讀：

• 別再問我ConcurrentHashMap了

• 分散式鎖設計與實現

• ConcurrentHashMap竟然也有死迴圈問題？

• 你的ThreadLocal執行緒安全麼

 歡迎小夥伴掃描以下二維碼閱讀更多精彩好文。