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。

碼哥，如果業務資料就是這麼大咋辦？比如儲存的是《金瓶梅》這個大作。

我們還可以通過 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命令在配置檔案中對這些命令進行重新命名，讓客戶端無法使用這些命令。