[[433097]]

昨天我被公司 Leader 批評(píng)了。

我在單身紅娘婚戀類型互聯(lián)網(wǎng)公司工作，在雙十一推出下單就送女朋友的活動(dòng)。

誰(shuí)曾想，凌晨 12 點(diǎn)之后，用戶量暴增，出現(xiàn)了一個(gè)技術(shù)故障，用戶無(wú)法下單，當(dāng)時(shí)老大火冒三丈！

經(jīng)過(guò)查找發(fā)現(xiàn) Redis 報(bào) Could not get a resource from the pool。

獲取不到連接資源，并且集群中的單臺(tái) Redis 連接量很高。

于是各種更改最大連接數(shù)、連接等待數(shù)，雖然報(bào)錯(cuò)信息頻率有所緩解，但還是持續(xù)報(bào)錯(cuò)。

后來(lái)經(jīng)過(guò)線下測(cè)試，發(fā)現(xiàn)存放 Redis 中的字符數(shù)據(jù)很大，平均 1s 返回?cái)?shù)據(jù)。

    ❝    可以分享下使用 Redis 的規(guī)范么？我想做一個(gè)唯快不破的真男人！

通過(guò) Redis 為什么這么快？這篇文章我們知道 Redis 為了高性能和節(jié)省內(nèi)存費(fèi)勁心思。

所以，只有規(guī)范的使用 Redis，才能實(shí)現(xiàn)高性能和節(jié)省內(nèi)存，否則再屌的 Redis 也禁不起我們瞎折騰。

Redis 使用規(guī)范圍繞如下幾個(gè)緯度展開(kāi)：

•  鍵值對(duì)使用規(guī)范
•  命令使用規(guī)范
•  數(shù)據(jù)保存規(guī)范
•  運(yùn)維規(guī)范

鍵值對(duì)使用規(guī)范

有兩點(diǎn)需要注意：

1.  好的 key 命名，才能提供可讀性強(qiáng)、可維護(hù)性高的 key，便于定位問(wèn)題和尋找數(shù)據(jù)。
2.  value要避免出現(xiàn) bigkey、選擇高效的序列化和壓縮、使用對(duì)象共享池、選擇高效恰當(dāng)?shù)臄?shù)據(jù)類型（可參考《Redis 實(shí)戰(zhàn)篇：巧用數(shù)據(jù)類型實(shí)現(xiàn)億級(jí)數(shù)據(jù)統(tǒng)計(jì)》）。

key 命名規(guī)范

規(guī)范的 key命名，在遇到問(wèn)題的時(shí)候能夠方便定位。Redis 屬于 沒(méi)有 Scheme的 NoSQL數(shù)據(jù)庫(kù)。

所以要靠規(guī)范來(lái)建立其 Scheme 語(yǔ)意，就好比根據(jù)不同的場(chǎng)景我們建立不同的數(shù)據(jù)庫(kù)。

敲黑板

把「業(yè)務(wù)模塊名」作為前綴（好比數(shù)據(jù)庫(kù) Scheme），通過(guò)「冒號(hào)」分隔，再加上「具體業(yè)務(wù)名」。

這樣我們就可以通過(guò) key 前綴來(lái)區(qū)分不同的業(yè)務(wù)數(shù)據(jù)，清晰明了。

總結(jié)起來(lái)就是：「業(yè)務(wù)名:表名:id」

比如我們要統(tǒng)計(jì)公眾號(hào)屬于技術(shù)類型的博主「Java技術(shù)?！沟奈恼聰?shù)。 

set 公眾號(hào):技術(shù)類:Java技術(shù)棧 100000 

    ❝    key 太長(zhǎng)的話有什么問(wèn)題么？

key 是字符串，底層的數(shù)據(jù)結(jié)構(gòu)是 SDS，SDS 結(jié)構(gòu)中會(huì)包含字符串長(zhǎng)度、分配空間大小等元數(shù)據(jù)信息。

字符串長(zhǎng)度增加，SDS 的元數(shù)據(jù)也會(huì)占用更多的內(nèi)存空間。

所以當(dāng)字符串太長(zhǎng)的時(shí)候，我們可以采用適當(dāng)縮寫(xiě)的形式。

不要使用 bigkey

    ❝    我就中招了，導(dǎo)致報(bào)錯(cuò)獲取不到連接。

因?yàn)?Redis 是單線程執(zhí)行讀寫(xiě)指令，如果出現(xiàn)bigkey 的讀寫(xiě)操作就會(huì)阻塞線程，降低 Redis 的處理效率。

bigkey包含兩種情況：

•  鍵值對(duì)的 value很大，比如 value保存了 2MB的 String數(shù)據(jù)；
•  鍵值對(duì)的 value是集合類型，元素很多，比如保存了 5 萬(wàn)個(gè)元素的 List 集合。

雖然 Redis 官方說(shuō)明了 key和string類型 value限制均為512MB。最新 Redis 面試題整理好了，點(diǎn)擊Java面試庫(kù)小程序在線刷題。

防止網(wǎng)卡流量、慢查詢，string類型控制在10KB以內(nèi)，hash、list、set、zset元素個(gè)數(shù)不要超過(guò) 5000。

   ❝    如果業(yè)務(wù)數(shù)據(jù)就是這么大咋辦？比如保存的是《XXX》這個(gè)大作。

我們還可以通過(guò) gzip 數(shù)據(jù)壓縮來(lái)減小數(shù)據(jù)大小: 

/**  
 * 使用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;  
} 

集合類型

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

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

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

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

上述的兩種序列化方式雖然省內(nèi)存，但是序列化后都是二進(jìn)制數(shù)據(jù)，可讀性太差。

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

使用整數(shù)對(duì)象共享池

Redis 內(nèi)部維護(hù)了 0 到 9999 這 1 萬(wàn)個(gè)整數(shù)對(duì)象，并把這些整數(shù)作為一個(gè)共享池使用。

即使大量鍵值對(duì)保存了 0 到 9999 范圍內(nèi)的整數(shù)，在 Redis 實(shí)例中，其實(shí)只保存了一份整數(shù)對(duì)象，可以節(jié)省內(nèi)存空間。

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

    1.  Redis 中設(shè)置了 maxmemory，而且啟用了 LRU策略（allkeys-lru 或 volatile-lru 策略），那么，整數(shù)對(duì)象共享池就無(wú)法使用了。

        ❝        這是因?yàn)?LRU 需要統(tǒng)計(jì)每個(gè)鍵值對(duì)的使用時(shí)間，如果不同的鍵值對(duì)都復(fù)用一個(gè)整數(shù)對(duì)象就無(wú)法統(tǒng)計(jì)了。

    2.  如果集合類型數(shù)據(jù)采用 ziplist 編碼，而集合元素是整數(shù)，這個(gè)時(shí)候，也不能使用共享池。

        ❝        因?yàn)?ziplist 使用了緊湊型內(nèi)存結(jié)構(gòu)，判斷整數(shù)對(duì)象的共享情況效率低。

命令使用規(guī)范

有的命令的執(zhí)行會(huì)造成很大的性能問(wèn)題，我們需要格外注意。

生產(chǎn)禁用的指令

Redis 是單線程處理請(qǐng)求操作，如果我們執(zhí)行一些涉及大量操作、耗時(shí)長(zhǎng)的命令，就會(huì)嚴(yán)重阻塞主線程，導(dǎo)致其它請(qǐng)求無(wú)法得到正常處理。

•  KEYS：該命令需要對(duì) Redis 的全局哈希表進(jìn)行全表掃描，嚴(yán)重阻塞 Redis 主線程；

        ❝        應(yīng)該使用 SCAN 來(lái)代替，分批返回符合條件的鍵值對(duì)，避免主線程阻塞。

•  FLUSHALL：刪除 Redis 實(shí)例上的所有數(shù)據(jù)，如果數(shù)據(jù)量很大，會(huì)嚴(yán)重阻塞 Redis 主線程；
•  FLUSHDB，刪除當(dāng)前數(shù)據(jù)庫(kù)中的數(shù)據(jù)，如果數(shù)據(jù)量很大，同樣會(huì)阻塞 Redis 主線程。

        ❝        加上 ASYNC 選項(xiàng)，讓 FLUSHALL，F(xiàn)LUSHDB 異步執(zhí)行。

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

慎用 MONITOR 命令

MONITOR 命令會(huì)把監(jiān)控到的內(nèi)容持續(xù)寫(xiě)入輸出緩沖區(qū)。

如果線上命令的操作很多，輸出緩沖區(qū)很快就會(huì)溢出了，這就會(huì)對(duì) Redis 性能造成影響，甚至引起服務(wù)崩潰。

所以，除非十分需要監(jiān)測(cè)某些命令的執(zhí)行（例如，Redis 性能突然變慢，我們想查看下客戶端執(zhí)行了哪些命令）我們才使用。

慎用全量操作命令

比如獲取集合中的所有元素（HASH 類型的 hgetall、List 類型的 lrange、Set 類型的 smembers、zrange 等命令）。

這些操作會(huì)對(duì)整個(gè)底層數(shù)據(jù)結(jié)構(gòu)進(jìn)行全量掃描 ，導(dǎo)致阻塞 Redis 主線程。

    ❝    如果業(yè)務(wù)場(chǎng)景就是需要獲取全量數(shù)據(jù)咋辦？

有兩個(gè)方式可以解決：

1.   使用 SSCAN、HSCAN等命令分批返回集合數(shù)據(jù)；
2.   把大集合拆成小集合，比如按照時(shí)間、區(qū)域等劃分。

數(shù)據(jù)保存規(guī)范

冷熱數(shù)據(jù)分離

雖然 Redis 支持使用 RDB 快照和 AOF 日志持久化保存數(shù)據(jù)，但是，這兩個(gè)機(jī)制都是用來(lái)提供數(shù)據(jù)可靠性保證的，并不是用來(lái)擴(kuò)充數(shù)據(jù)容量的。

不要什么數(shù)據(jù)都存在 Redis，應(yīng)該作為緩存保存熱數(shù)據(jù)，這樣既可以充分利用 Redis 的高性能特性，還可以把寶貴的內(nèi)存資源用在服務(wù)熱數(shù)據(jù)上。

業(yè)務(wù)數(shù)據(jù)隔離

不要將不相關(guān)的數(shù)據(jù)業(yè)務(wù)都放到一個(gè) Redis 中。一方面避免業(yè)務(wù)相互影響，另一方面避免單實(shí)例膨脹，并能在故障時(shí)降低影響面，快速恢復(fù)。

設(shè)置過(guò)期時(shí)間

在數(shù)據(jù)保存時(shí)，我建議你根據(jù)業(yè)務(wù)使用數(shù)據(jù)的時(shí)長(zhǎng)，設(shè)置數(shù)據(jù)的過(guò)期時(shí)間。

寫(xiě)入 Redis 的數(shù)據(jù)會(huì)一直占用內(nèi)存，如果數(shù)據(jù)持續(xù)增多，就可能達(dá)到機(jī)器的內(nèi)存上限，造成內(nèi)存溢出，導(dǎo)致服務(wù)崩潰。

控制單實(shí)例的內(nèi)存容量

建議設(shè)置在 2~6 GB 。這樣一來(lái)，無(wú)論是 RDB 快照，還是主從集群進(jìn)行數(shù)據(jù)同步，都能很快完成，不會(huì)阻塞正常請(qǐng)求的處理。

防止緩存雪崩

避免集中過(guò)期 key 導(dǎo)致緩存雪崩。

    ❝    什么是緩存雪崩？

當(dāng)某一個(gè)時(shí)刻出現(xiàn)大規(guī)模的緩存失效的情況，那么就會(huì)導(dǎo)致大量的請(qǐng)求直接打在數(shù)據(jù)庫(kù)上面，導(dǎo)致數(shù)據(jù)庫(kù)壓力巨大，如果在高并發(fā)的情況下，可能瞬間就會(huì)導(dǎo)致數(shù)據(jù)庫(kù)宕機(jī)。

運(yùn)維規(guī)范

1.   使用 Cluster 集群或者哨兵集群，做到高可用；
2.   實(shí)例設(shè)置最大連接數(shù)，防止過(guò)多客戶端連接導(dǎo)致實(shí)例負(fù)載過(guò)高，影響性能。
3.   不開(kāi)啟 AOF 或開(kāi)啟 AOF 配置為每秒刷盤(pán)，避免磁盤(pán) IO 拖慢 Redis 性能。
4.   設(shè)置合理的 repl-backlog，降低主從全量同步的概率
5.   設(shè)置合理的 slave client-output-buffer-limit，避免主從復(fù)制中斷情況發(fā)生。
6.   根據(jù)實(shí)際場(chǎng)景設(shè)置合適的內(nèi)存淘汰策略。
7.   使用連接池操作 Redis。