Redis 很屌，不懂使用規范就糟蹋了

本文轉載自查看原文 2021-12-02 16:52 170 Java/ Redis/ 后端

這可能是最中肯的 Redis 使用規范了

碼哥，昨天我被公司 Leader 批評了。

我在單身紅娘婚戀類型互聯網公司工作，在雙十一推出下單就送女朋友的活動。

誰曾想，凌晨 12 點之后，用戶量暴增，出現了一個技術故障，用戶無法下單，當時老大火冒三丈！

經過查找發現 Redis 報 Could not get a resource from the pool。

獲取不到連接資源，並且集群中的單台 Redis 連接量很高。

於是各種更改最大連接數、連接等待數，雖然報錯信息頻率有所緩解，但還是持續報錯。

后來經過線下測試，發現存放 Redis 中的字符數據很大，平均 1s 返回數據。

碼哥，可以分享下使用 Redis 的規范么？我想做一個唯快不破的真男人！

通過 Redis 為什么這么快？這篇文章我們知道 Redis 為了高性能和節省內存費勁心思。

所以，只有規范的使用 Redis，才能實現高性能和節省內存，否則再屌的 Redis 也禁不起我們瞎折騰。

Redis 使用規范圍繞如下幾個緯度展開：

鍵值對使用規范；
命令使用規范；
數據保存規范；
運維規范。

鍵值對使用規范

有兩點需要注意：

好的 key 命名，才能提供可讀性強、可維護性高的 key，便於定位問題和尋找數據。
value要避免出現 bigkey、選擇高效的序列化和壓縮、使用對象共享池、選擇高效恰當的數據類型（可參考《Redis 實戰篇：巧用數據類型實現億級數據統計》）。

key 命名規范

規范的 key命名，在遇到問題的時候能夠方便定位。Redis 屬於沒有 Scheme的 NoSQL數據庫。

所以要靠規范來建立其 Scheme 語意，就好比根據不同的場景我們建立不同的數據庫。

敲黑板

把「業務模塊名」作為前綴（好比數據庫 Scheme），通過「冒號」分隔，再加上「具體業務名」。

這樣我們就可以通過 key 前綴來區分不同的業務數據，清晰明了。

總結起來就是：「業務名:表名:id」

比如我們要統計公眾號屬於技術類型的博主「碼哥字節」的粉絲數。

set 公眾號:技術類:碼哥字節 100000

碼哥，key 太長的話有什么問題么？

key 是字符串，底層的數據結構是 SDS，SDS 結構中會包含字符串長度、分配空間大小等元數據信息。

字符串長度增加，SDS 的元數據也會占用更多的內存空間。

所以當字符串太長的時候，我們可以采用適當縮寫的形式。

不要使用 bigkey

碼哥，我就中招了，導致報錯獲取不到連接。

因為 Redis 是單線程執行讀寫指令，如果出現bigkey 的讀寫操作就會阻塞線程，降低 Redis 的處理效率。

bigkey包含兩種情況：

鍵值對的 value很大，比如 value保存了 2MB的 String數據；
鍵值對的 value是集合類型，元素很多，比如保存了 5 萬個元素的 List 集合。

雖然 Redis 官方說明了 key和string類型 value限制均為512MB。

防止網卡流量、慢查詢，string類型控制在10KB以內，hash、list、set、zset元素個數不要超過 5000。

碼哥，如果業務數據就是這么大咋辦？比如保存的是《金ping梅》這個大作。

我們還可以通過 gzip 數據壓縮來減小數據大小:

/**
 * 使用gzip壓縮字符串
 */
public static String compress(String str) {
    if (str == null || str.length() == 0) {
        return str;
    }

    try (ByteArrayOutputStream out = new ByteArrayOutputStream();
    GZIPOutputStream gzip = new GZIPOutputStream(out)) {
        gzip.write(str.getBytes());
    } catch (IOException e) {
        e.printStackTrace();
    }
    return new sun.misc.BASE64Encoder().encode(out.toByteArray());
}

/**
 * 使用gzip解壓縮
 */
public static String uncompress(String compressedStr) {
    if (compressedStr == null || compressedStr.length() == 0) {
        return compressedStr;
    }
    byte[] compressed = new sun.misc.BASE64Decoder().decodeBuffer(compressedStr);;
    String decompressed = null;
    try (ByteArrayOutputStream out = new ByteArrayOutputStream();
    ByteArrayInputStream in = new ByteArrayInputStream(compressed);
    GZIPInputStream ginzip = new GZIPInputStream(in);) {
        byte[] buffer = new byte[1024];
        int offset = -1;
        while ((offset = ginzip.read(buffer)) != -1) {
            out.write(buffer, 0, offset);
        }
        decompressed = out.toString();
    } catch (IOException e) {
        e.printStackTrace();
    }
    return decompressed;
}

集合類型

如果集合類型的元素的確很多，我們可以將一個大集合拆分成多個小集合來保存。

使用高效序列化和壓縮方法

為了節省內存，我們可以使用高效的序列化方法和壓縮方法去減少 value的大小。

protostuff和 kryo這兩種序列化方法，就要比 Java內置的序列化方法效率更高。

上述的兩種序列化方式雖然省內存，但是序列化后都是二進制數據，可讀性太差。

通常我們會序列化成 JSON或者 XML，為了避免數據占用空間大，我們可以使用壓縮工具（snappy、 gzip）將數據壓縮再存到 Redis 中。

使用整數對象共享池

Redis 內部維護了 0 到 9999 這 1 萬個整數對象，並把這些整數作為一個共享池使用。

即使大量鍵值對保存了 0 到 9999 范圍內的整數，在 Redis 實例中，其實只保存了一份整數對象，可以節省內存空間。

需要注意的是，有兩種情況是不生效的：

Redis 中設置了 maxmemory，而且啟用了 LRU策略（allkeys-lru 或 volatile-lru 策略），那么，整數對象共享池就無法使用了。

這是因為 LRU 需要統計每個鍵值對的使用時間，如果不同的鍵值對都復用一個整數對象就無法統計了。
如果集合類型數據采用 ziplist 編碼，而集合元素是整數，這個時候，也不能使用共享池。

因為 ziplist 使用了緊湊型內存結構，判斷整數對象的共享情況效率低。

命令使用規范

有的命令的執行會造成很大的性能問題，我們需要格外注意。

生產禁用的指令

Redis 是單線程處理請求操作，如果我們執行一些涉及大量操作、耗時長的命令，就會嚴重阻塞主線程，導致其它請求無法得到正常處理。

KEYS：該命令需要對 Redis 的全局哈希表進行全表掃描，嚴重阻塞 Redis 主線程；

應該使用 SCAN 來代替，分批返回符合條件的鍵值對，避免主線程阻塞。
FLUSHALL：刪除 Redis 實例上的所有數據，如果數據量很大，會嚴重阻塞 Redis 主線程；
FLUSHDB，刪除當前數據庫中的數據，如果數據量很大，同樣會阻塞 Redis 主線程。

加上 ASYNC 選項，讓 FLUSHALL，FLUSHDB 異步執行。

我們也可以直接禁用，用rename-command命令在配置文件中對這些命令進行重命名，讓客戶端無法使用這些命令。