Redis規(guī)范，這可能是最中肯的了

本文轉(zhuǎn)載自公眾號：小姐姐味道

redis 功能強大，數(shù)據(jù)類型豐富，再快的系統(tǒng)，也經(jī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 是單線程服務，消息過大會阻塞并拖慢其他操作。保持消息內(nèi)容在 1KB 以下是個好的習慣。嚴禁超過 50KB 的單條記錄。消息過大還會引起網(wǎng)絡帶寬的高占用，持久化到磁盤時的 IO 問題。

連接數(shù)限制

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

緩存 Key 設置失效時間

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

緩存不能有中間態(tài)

緩存應該僅作緩存用，去掉后業(yè)務邏輯不應發(fā)生改變，萬不可切入到業(yè)務里。第一，緩存的高可用會影響業(yè)務；第二，產(chǎn)生深耦合會發(fā)生無法預料的效果；第三，會對維護行產(chǎn)生膚效果。

擴展方式首選客戶端 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架構(gòu)，性能會下降很多，請?zhí)崆皦簻y和評估

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

禁用 select 函數(shù)

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

禁用事務

redis 本身已經(jīng)很快了，如無大的必要，建議捕獲異常進行回滾，不要使用事務函數(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 語義。其好處：

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

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

user:sex 用戶 10002232 的性別

msg:achi 201712 的用戶發(fā)言數(shù)量排行榜

End

適當?shù)募s束是架構(gòu)成熟的必要條件，通過約定能達到規(guī)范是集體開發(fā)的最高境界。Redis用的多，也要用的穩(wěn)，給點約束、立點規(guī)矩，生活將變的美好。通過二次封裝redis客戶端，直接阻斷，效果更佳。

以上就是W3Cschool編程獅關于Redis規(guī)范，這可能是最中肯的了的相關介紹了，希望對大家有所幫助。