Redis功能強大，那也頂不住被濫用啊！

Redis功能強大，數據類型豐富，再快的系統，也經不住瘋狂的濫用。通過禁用部分高風險功能，并掛上開發的枷鎖，業務更能夠以簡潔、通用的思想去考慮問題，而不是綁定在某種實現上。

Redis根據不同的用途，會有不同的持久化策略和逐出策略，所以，在使用和申請 Redis 集群前，請明確是用來做緩存還是存儲。Redis的集群有主從和 cluster 兩種模式，各有優缺點。以下規范不區分集群模式，我們分別從使用場景和操作限制兩方面說明。

使用規范

冷熱數據區分

雖然 Redis支持持久化，但將所有數據存儲在 Redis 中，成本非常昂貴。建議將熱數據 (如 QPS超過 5k) 的數據加載到 Redis 中。低頻數據可存儲在 Mysql、 ElasticSearch中。

業務數據分離

不要將不相關的數據業務都放到一個 Redis中。一方面避免業務相互影響，另一方面避免單實例膨脹，并能在故障時降低影響面，快速恢復。

消息大小限制

由于 Redis 是單線程服務，消息過大會阻塞并拖慢其他操作。保持消息內容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引起網絡帶寬的高占用，持久化到磁盤時的 IO 問題。

連接數限制

連接的頻繁創建和銷毀，會浪費大量的系統資源，極限情況會造成宿主機當機。請確保使用了正確的 Redis 客戶端連接池配置。

緩存 Key 設置失效時間

作為緩存使用的 Key，必須要設置失效時間。失效時間并不是越長越好，請根據業務性質進行設置。注意，失效時間的單位有的是秒，有的是毫秒，這個很多同學不注意容易搞錯。

緩存不能有中間態

緩存應該僅作緩存用，去掉后業務邏輯不應發生改變，萬不可切入到業務里。

1、緩存的高可用會影響業務；

2、產生深耦合會發生無法預料的效果；

3、會對維護行產生膚效果。

擴展方式首選客戶端 hash

如果應用太小就別考慮了，如單 redis 集群并不能為你的數據服務，不要著急擴大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在狀態同步和持久化方面的性能越差。優先使用客戶端 hash 進行集群拆分。如：根據用戶 id 分 10 個集群，用戶尾號為 0 的落在第一個集群。

操作限制

嚴禁使用 Keys

Keys 命令效率極低，屬于 O(N)操作，會阻塞其他正常命令，在 cluster 上，會是災難性的操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用。

嚴禁使用 Flush

flush 命令會清空所有數據，屬于高危操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用，僅 DBA 可操作。

嚴禁作為消息隊列使用

如沒有非常特殊的需求，嚴禁將 Redis 當作消息隊列使用。Redis 當作消息隊列使用，會有容量、網絡、效率、功能方面的多種問題。如需要消息隊列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。

嚴禁不設置范圍的批量操作

redis 那么快，慢查詢除了網絡延遲，就屬于這些批量操作函數。大多數線上問題都是由于這些函數引起。

1、[zset] 嚴禁對 zset 的不設范圍操作

ZRANGE、 ZRANGEBYSCORE等多個操作 ZSET 的函數，嚴禁使用 ZRANGE myzset 0 -1 等這種不設置范圍的操作。請指定范圍，如 ZRANGE myzset 0 100。如不確定長度，可使用 ZCARD 判斷長度

2、[hash] 嚴禁對大數據量 Key 使用 HGETALL

HGETALL會取出相關 HASH 的所有數據，如果數據條數過大，同樣會引起阻塞，請確保業務可控。如不確定長度，可使用 HLEN 先判斷長度

3、[key] Redis Cluster 集群的 mget 操作

Redis Cluster 的 MGET 操作，會到各分片取數據聚合，相比傳統的 M/S架構，性能會下降很多，請提前壓測和評估

4、[其他] 嚴禁使用 sunion, sinter, sdiff等一些聚合操作

禁用 select 函數

select函數用來切換 database，對于使用方來說，這是很容易發生問題的地方，cluster 模式也不支持多個 database，且沒有任何收益，禁用。

禁用事務

redis 本身已經很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數，很少有人這么干。

禁用 lua 腳本擴展

lua 腳本雖然能做很多看起來很 cool 的事情，但它就像是 SQL 的存儲過程，會引入性能和一些難以維護的問題，禁用。

禁止長時間 monitor

monitor函數可以快速看到當前 redis 正在執行的數據流，但是當心，高峰期長時間阻塞在 monitor 命令上，會嚴重影響 redis 的性能。此命令不禁止使用，但使用一定要特別特別注意。

Key 規范

Redis 的 Key 一定要規范，這樣在遇到問題時，能夠進行方便的定位。Redis 屬于無 scheme 的 KV 數據庫，所以，我們靠約定來建立其 scheme 語義。其好處：

1、能夠根據某類 key 進行數據清理 2、能夠根據某類 key 進行數據更新 3、能夠方面了解到某類 key 的歸屬方和應用場景 4、為統一化、平臺化做準備，減少技術變更

一般，一個 key 需要帶以下維度：業務、key 用途、變量等，各個維度使用 : 進行分隔，以下是幾個 key 的實例:

user:sex 用戶 10002232 的性別 msg:achi 201712 的用戶發言數量排行榜

最后

適當的約束是架構成熟的必要條件，通過約定能達到規范是集體開發的最高境界。Redis用的多，也要用的穩，給點約束、立點規矩，生活將變的美好。通過二次封裝redis客戶端，直接阻斷，效果更佳。