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客戶端，直接阻斷，效果更佳。