本文轉載自公眾號：小姐姐味道
redis 功能強大，數(shù)據(jù)類型豐富，再快的系統(tǒng)，也經不住瘋狂的濫用。通過禁用部分高風險功能，并掛上開發(fā)的枷鎖，業(yè)務更能夠以簡潔、通用的思想去考慮問題，而不是綁定在某種實現(xiàn)上。
Redis 根據(jù)不同的用途，會有不同的持久化策略和逐出策略，所以，在使用和申請 Redis 集群前，請明確是用來做緩存還是存儲。redis 的集群有主從和 cluster 兩種模式，各有優(yōu)缺點。以下規(guī)范不區(qū)分集群模式，我們分別從使用場景和操作限制兩方面說明。
使用規(guī)范
冷熱數(shù)據(jù)區(qū)分
雖然 redis支持持久化，但將所有數(shù)據(jù)存儲在 redis 中，成本非常昂貴。建議將熱數(shù)據(jù) (如 QPS超過 5k) 的數(shù)據(jù)加載到 redis 中。低頻數(shù)據(jù)可存儲在 Mysql、 ElasticSearch中。
業(yè)務數(shù)據(jù)分離
不要將不相關的數(shù)據(jù)業(yè)務都放到一個 Redis中。一方面避免業(yè)務相互影響，另一方面避免單實例膨脹，并能在故障時降低影響面，快速恢復。
消息大小限制
由于 Redis 是單線程服務，消息過大會阻塞并拖慢其他操作。保持消息內容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引起網(wǎng)絡帶寬的高占用，持久化到磁盤時的 IO 問題。
連接數(shù)限制
連接的頻繁創(chuàng)建和銷毀，會浪費大量的系統(tǒng)資源，極限情況會造成宿主機當機。請確保使用了正確的 Redis 客戶端連接池配置。
緩存 Key 設置失效時間
作為緩存使用的 Key，必須要設置失效時間。失效時間并不是越長越好，請根據(jù)業(yè)務性質進行設置。注意，失效時間的單位有的是秒，有的是毫秒，這個很多同學不注意容易搞錯。
緩存不能有中間態(tài)
緩存應該僅作緩存用，去掉后業(yè)務邏輯不應發(fā)生改變，萬不可切入到業(yè)務里。第一，緩存的高可用會影響業(yè)務；第二，產生深耦合會發(fā)生無法預料的效果；第三，會對維護行產生膚效果。
擴展方式首選客戶端 hash
小應用就算了
如單 redis 集群并不能為你的數(shù)據(jù)服務，不要著急擴大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在狀態(tài)同步和持久化方面的性能越差。 優(yōu)先使用客戶端 hash 進行集群拆分。如：根據(jù)用戶 id 分 10 個集群，用戶尾號為 0 的落在第一個集群。
操作限制
嚴禁使用 Keys
Keys 命令效率極低，屬于 O(N)操作，會阻塞其他正常命令，在 cluster 上，會是災難性的操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用。
嚴禁使用 Flush
flush 命令會清空所有數(shù)據(jù)，屬于高危操作。嚴禁使用，DBA 應該 rename 此命令，從根源禁用，僅 DBA 可操作。
嚴禁作為消息隊列使用
如沒有非常特殊的需求，嚴禁將 Redis 當作消息隊列使用。Redis 當作消息隊列使用，會有容量、網(wǎng)絡、效率、功能方面的多種問題。如需要消息隊列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。
嚴禁不設置范圍的批量操作
redis 那么快，慢查詢除了網(wǎng)絡延遲，就屬于這些批量操作函數(shù)。大多數(shù)線上問題都是由于這些函數(shù)引起。
1、[zset] 嚴禁對 zset 的不設范圍操作
ZRANGE、 ZRANGEBYSCORE等多個操作 ZSET 的函數(shù)，嚴禁使用 ZRANGE myzset 0 -1 等這種不設置范圍的操作。請指定范圍，如 ZRANGE myzset 0 100。如不確定長度，可使用 ZCARD 判斷長度
2、[hash] 嚴禁對大數(shù)據(jù)量 Key 使用 HGETALL
HGETALL會取出相關 HASH 的所有數(shù)據(jù)，如果數(shù)據(jù)條數(shù)過大，同樣會引起阻塞，請確保業(yè)務可控。如不確定長度，可使用 HLEN 先判斷長度
3、[key] Redis Cluster 集群的 mget 操作
Redis Cluster 的 MGET 操作，會到各分片取數(shù)據(jù)聚合，相比傳統(tǒng)的 M/S架構，性能會下降很多，請?zhí)崆皦簻y和評估
4、[其他] 嚴禁使用 sunion, sinter, sdiff等一些聚合操作
禁用 select 函數(shù)
select函數(shù)用來切換 database，對于使用方來說，這是很容易發(fā)生問題的地方，cluster 模式也不支持多個 database，且沒有任何收益，禁用。
禁用事務
redis 本身已經很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數(shù)，很少有人這么干。
禁用 lua 腳本擴展
lua 腳本雖然能做很多看起來很 cool 的事情，但它就像是 SQL 的存儲過程，會引入性能和一些難以維護的問題，禁用。
禁止長時間 monitor
monitor函數(shù)可以快速看到當前 redis 正在執(zhí)行的數(shù)據(jù)流，但是當心，高峰期長時間阻塞在 monitor 命令上，會嚴重影響 redis 的性能。此命令不禁止使用，但使用一定要特別特別注意。
Key 規(guī)范
Redis 的 Key 一定要規(guī)范，這樣在遇到問題時，能夠進行方便的定位。Redis 屬于無 scheme 的 KV 數(shù)據(jù)庫，所以，我們靠約定來建立其 scheme 語義。其好處：
- 能夠根據(jù)某類 key 進行數(shù)據(jù)清理
- 能夠根據(jù)某類 key 進行數(shù)據(jù)更新
- 能夠方面了解到某類 key 的歸屬方和應用場景
- 為統(tǒng)一化、平臺化做準備，減少技術變更
一般，一個 key 需要帶以下維度：業(yè)務、key 用途、變量等，各個維度使用 : 進行分隔，以下是幾個 key 的實例:
user:sex 用戶 10002232 的性別
msg:achi 201712 的用戶發(fā)言數(shù)量排行榜
End
適當?shù)募s束是架構成熟的必要條件，通過約定能達到規(guī)范是集體開發(fā)的最高境界。Redis用的多，也要用的穩(wěn)，給點約束、立點規(guī)矩，生活將變的美好。通過二次封裝redis客戶端，直接阻斷，效果更佳。
以上就是W3Cschool編程獅關于Redis規(guī)范，這可能是最中肯的了的相關介紹了，希望對大家有所幫助。
