Redis規範有哪些

redis 功能強大，資料類型豐富，再快的系統，也經不住瘋狂的濫用。透過停用部分高風險功能，並掛上開發的枷鎖，業務更能夠以簡潔、通用的想法去考慮問題，而不是綁定在某種實作上。

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

使用規範

冷熱資料區分

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

業務資料分離

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

訊息大小限制

由於 Redis 是單執行緒服務，訊息過大會阻塞並拖曳其他操作。保持訊息內容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單一紀錄。訊息過大也會造成網路頻寬的高佔用，持久化到磁碟時的 IO 問題。

連線數限制

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

快取 Key 設定失效時間

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

快取不能有中間態

快取應該只做快取用，去掉後業務邏輯不應該改變，萬不可切入到業務裡。第一，緩存的高可用會影響業務；第二，產生深耦合會發生無法預料的效果；第三，會對維護行產生膚效果。

擴充方式首選客戶端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，且沒有任何收益，停用。 <h4>停用交易</h4> <p><code>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規範有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！