?這可能是最中肯的 Redis 使用規(guī)范了

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

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

誰(shuí)曾想，凌晨 12 點(diǎn)之后，用戶(hù)量暴增，出現(xiàn)了一個(gè)技術(shù)故障，用戶(hù)無(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ò)線(xiàn)下測(cè)試，發(fā)現(xiàn)存放 Redis 中的字符數(shù)據(jù)很大，平均 1s 返回?cái)?shù)據(jù)。

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

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ù)類(lèi)型（可參考《Redis 實(shí)戰(zhàn)篇：巧用數(shù)據(jù)類(lèi)型實(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ù)類(lèi)型的博主「碼哥字節(jié)」的粉絲數(shù)。

set?公眾號(hào):技術(shù)類(lèi):碼哥字節(jié)?100000


?碼哥，key 太長(zhǎng)的話(huà)有什么問(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 是單線(xiàn)程執(zhí)行讀寫(xiě)指令，如果出現(xiàn)bigkey 的讀寫(xiě)操作就會(huì)阻塞線(xiàn)程，降低 Redis 的處理效率。

bigkey包含兩種情況：

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

雖然 Redis 官方說(shuō)明了 key和string類(lèi)型 value限制均為512MB。

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

?碼哥，如果業(yè)務(wù)數(shù)據(jù)就是這么大咋辦？比如保存的是《金瓶梅》這個(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;
}

集合類(lèi)型

如果集合類(lèi)型的元素的確很多，我們可以將一個(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. 如果集合類(lèi)型數(shù)據(jù)采用 ziplist 編碼，而集合元素是整數(shù)，這個(gè)時(shí)候，也不能使用共享池。

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

命令使用規(guī)范

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

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

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

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

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

• FLUSHALL：刪除 Redis 實(shí)例上的所有數(shù)據(jù)，如果數(shù)據(jù)量很大，會(huì)嚴(yán)重阻塞 Redis 主線(xiàn)程；

• FLUSHDB，刪除當(dāng)前數(shù)據(jù)庫(kù)中的數(shù)據(jù)，如果數(shù)據(jù)量很大，同樣會(huì)阻塞 Redis 主線(xiàn)程。

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

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

慎用 MONITOR 命令

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

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

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

慎用全量操作命令

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

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

?碼哥，如果業(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ò)多客戶(hù)端連接導(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。