Redis功能強大，數據類型豐富，再快的系統，也經不住瘋狂的濫用。通過禁用部分高風險功能，並掛上開發的枷鎖，業務更能夠以簡潔、通用的思想去考慮問題，而不是綁定在某種實現上。
Redis根據不同的用途，會有不同的持久化策略和逐出策略，所以，在使用和申請 Redis 集羣前，請明確是用來做緩存還是存儲。Redis的集羣有主從和 cluster 兩種模式，各有優缺點。以下規範不區分集羣模式，我們分別從使用場景和操作限制兩方面說明。
使用規範
1、冷熱數據區分
雖然 Redis支持持久化，但將所有數據存儲在 Redis 中，成本非常昂貴。建議將熱數據 (如 QPS超過 5k) 的數據加載到 Redis 中。低頻數據可存儲在 Mysql、 ElasticSearch中。
2、業務數據分離
不要將不相關的數據業務都放到一個 Redis中。一方面避免業務相互影響，另一方面避免單實例膨脹，並能在故障時降低影響面，快速恢復。
3、消息大小限制
由於 Redis 是單線程服務，消息過大會阻塞並拖慢其他操作。保持消息內容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引起網絡帶寬的高佔用，持久化到磁盤時的 IO 問題。
4、連接數限制
連接的頻繁創建和銷燬，會浪費大量的系統資源，極限情況會造成宿主機當機。請確保使用了正確的 Redis 客戶端連接池配置。
5、緩存 Key 設置失效時間
作爲緩存使用的 Key，必須要設置失效時間。失效時間並不是越長越好，請根據業務性質進行設置。注意，失效時間的單位有的是秒，有的是毫秒，這個很多同學不注意容易搞錯。
6、緩存不能有中間態
緩存應該僅作緩存用，去掉後業務邏輯不應發生改變，萬不可切入到業務裏。
緩存的高可用會影響業務；
產生深耦合會發生無法預料的效果；
會對維護行產生膚效果。
擴展方式首選客戶端 hash
如果應用太小就別考慮了，如單 redis 集羣並不能爲你的數據服務，不要着急擴大你的 redis 集羣（包括 M/S 和 Cluster)，集羣越大，在狀態同步和持久化方面的性能越差。 優先使用客戶端 hash 進行集羣拆分。如：根據用戶 id 分 10 個集羣，用戶尾號爲 0 的落在第一個集羣。
操作限制
1、嚴禁使用 Keys
Keys 命令效率極低，屬於 O(N)操作，會阻塞其他正常命令，在 cluster 上，會是災難性的操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用。
2、嚴禁使用 Flush
flush 命令會清空所有數據，屬於高危操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用，僅 DBA 可操作。
3、嚴禁作爲消息隊列使用
如沒有非常特殊的需求，嚴禁將 Redis 當作消息隊列使用。Redis 當作消息隊列使用，會有容量、網絡、效率、功能方面的多種問題。如需要消息隊列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。
4、嚴禁不設置範圍的批量操作
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等一些聚合操作
5、禁用 select 函數
select函數用來切換 database，對於使用方來說，這是很容易發生問題的地方，cluster 模式也不支持多個 database，且沒有任何收益，禁用。
6、禁用事務
redis 本身已經很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數，很少有人這麼幹。
7、禁用 lua 腳本擴展
lua 腳本雖然能做很多看起來很 cool 的事情，但它就像是 SQL 的存儲過程，會引入性能和一些難以維護的問題，禁用。
8、禁止長時間 monitor
monitor函數可以快速看到當前 redis 正在執行的數據流，但是當心，高峯期長時間阻塞在 monitor 命令上，會嚴重影響 redis 的性能。此命令不禁止使用，但使用一定要特別特別注意。
9、Key 規範
Redis 的 Key 一定要規範，這樣在遇到問題時，能夠進行方便的定位。Redis 屬於無 scheme 的 KV 數據庫，所以，我們靠約定來建立其 scheme 語義。其好處：
1、能夠根據某類 key 進行數據清理 2、能夠根據某類 key 進行數據更新 3、能夠方面瞭解到某類 key 的歸屬方和應用場景 4、爲統一化、平臺化做準備，減少技術變更
一般，一個 key 需要帶以下維度：業務、key 用途、變量等，各個維度使用 : 進行分隔，以下是幾個 key 的實例:
面試官問，實際項目中用Redis要注意哪些規範？
最後
適當的約束是架構成熟的必要條件，通過約定能達到規範是集體開發的最高境界。Redis用的多，也要用的穩，給點約束、立點規矩，生活將變的美好。通過二次封裝redis客戶端，直接阻斷，效果更佳。