昨天我被公司 Leader 批評了。
我在單身紅娘婚戀類型互聯網公司工作，在雙十一推出下單就送女朋友的活動。
誰曾想，凌晨 12 點之後，用戶量暴增，出現了一個技術故障，用戶無法下單，當時老大火冒三丈！
經過查找發現 Redis 報 Could not get a resource from the pool。
獲取不到連接資源，並且集羣中的單臺 Redis 連接量很高。
於是各種更改最大連接數、連接等待數，雖然報錯信息頻率有所緩解，但還是持續報錯。
後來經過線下測試，發現存放 Redis 中的字符數據很大，平均 1s 返回數據。
❝
可以分享下使用 Redis 的規範麼？我想做一個唯快不破的真男人！
通過 Redis 爲什麼這麼快？這篇文章我們知道 Redis 爲了高性能和節省內存費勁心思。
所以，只有規範的使用 Redis，才能實現高性能和節省內存，否則再屌的 Redis 也禁不起我們瞎折騰。
Redis 使用規範圍繞如下幾個緯度展開：
鍵值對使用規範；
命令使用規範；
數據保存規範；
運維規範。
鍵值對使用規範
有兩點需要注意：
好的 key 命名，才能提供可讀性強、可維護性高的 key，便於定位問題和尋找數據。
value要避免出現 bigkey、選擇高效的序列化和壓縮、使用對象共享池、選擇高效恰當的數據類型
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命令在配置文件中對這些命令進行重命名，讓客戶端無法使用這些命令。
慎用 MONITOR 命令
MONITOR 命令會把監控到的內容持續寫入輸出緩衝區。
如果線上命令的操作很多，輸出緩衝區很快就會溢出了，這就會對 Redis 性能造成影響，甚至引起服務崩潰。
所以，除非十分需要監測某些命令的執行（例如，Redis 性能突然變慢，我們想查看下客戶端執行了哪些命令）我們才使用。
慎用全量操作命令
比如獲取集合中的所有元素（HASH 類型的 hgetall、List 類型的 lrange、Set 類型的 smembers、zrange 等命令）。
這些操作會對整個底層數據結構進行全量掃描 ，導致阻塞 Redis 主線程。
❝
如果業務場景就是需要獲取全量數據咋辦？
有兩個方式可以解決：
使用 SSCAN、HSCAN等命令分批返回集合數據；
把大集合拆成小集合，比如按照時間、區域等劃分。
數據保存規範
冷熱數據分離
雖然 Redis 支持使用 RDB 快照和 AOF 日誌持久化保存數據，但是，這兩個機制都是用來提供數據可靠性保證的，並不是用來擴充數據容量的。
不要什麼數據都存在 Redis，應該作爲緩存保存熱數據，這樣既可以充分利用 Redis 的高性能特性，還可以把寶貴的內存資源用在服務熱數據上。
業務數據隔離
不要將不相關的數據業務都放到一個 Redis 中。一方面避免業務相互影響，另一方面避免單實例膨脹，並能在故障時降低影響面，快速恢復。
設置過期時間
在數據保存時，我建議你根據業務使用數據的時長，設置數據的過期時間。
寫入 Redis 的數據會一直佔用內存，如果數據持續增多，就可能達到機器的內存上限，造成內存溢出，導致服務崩潰。
控制單實例的內存容量
建議設置在 2~6 GB 。這樣一來，無論是 RDB 快照，還是主從集羣進行數據同步，都能很快完成，不會阻塞正常請求的處理。
防止緩存雪崩
避免集中過期 key 導致緩存雪崩。
❝
什麼是緩存雪崩？
當某一個時刻出現大規模的緩存失效的情況，那麼就會導致大量的請求直接打在數據庫上面，導致數據庫壓力巨大，如果在高併發的情況下，可能瞬間就會導致數據庫宕機。
運維規範
使用 Cluster 集羣或者哨兵集羣，做到高可用；
實例設置最大連接數，防止過多客戶端連接導致實例負載過高，影響性能。
不開啓 AOF 或開啓 AOF 配置爲每秒刷盤，避免磁盤 IO 拖慢 Redis 性能。
設置合理的 repl-backlog，降低主從全量同步的概率
設置合理的 slave client-output-buffer-limit，避免主從複製中斷情況發生。
根據實際場景設置合適的內存淘汰策略。
使用連接池操作 Redis。
