這多是最中肯的Redis規範了

更多精彩文章。

《微服務不是所有，只是特定領域的子集》

《「分庫分表" ？選型和流程要慎重，不然會失控》

這麼多監控組件，總有一款適合你

《使用Netty，咱們到底在開發些什麼？》

《這多是最中肯的Redis規範了》

《程序員畫像，十年沉浮》

最有用系列：

《Linux生產環境上，最經常使用的一套「vim「技巧》

《Linux生產環境上，最經常使用的一套「Sed「技巧》

《Linux生產環境上，最經常使用的一套「AWK「技巧》

---

Linux五件套之類的。

《Linux之《荒島餘生》（一）準備篇》

《Linux之《荒島餘生》（二）CPU篇》

《Linux之《荒島餘生》（三）內存篇》

《Linux之《荒島餘生》（四）I/O篇》

《Linux之《荒島餘生》（五）網絡篇》

更多請關注。固然也能夠關注公衆號: xjjdog 。

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 那麼快，慢查詢除了網絡延遲，就屬於這些批量操做函數。大多數線上問題都是因爲這些函數引發。

一、[zset] 嚴禁對 zset 的不設範圍操做

二、ZRANGE、 ZRANGEBYSCORE等多個操做 ZSET 的函數，嚴禁使用 ZRANGE myzset 0 -1 等這種不設置範圍的操做。請指定範圍，如 ZRANGE myzset 0 100。如不肯定長度，可以使用 ZCARD 判斷長度

三、[hash] 嚴禁對大數據量 Key 使用 HGETALL

四、HGETALL會取出相關 HASH 的全部數據，若是數據條數過大，一樣會引發阻塞，請確保業務可控。如不肯定長度，可以使用 HLEN 先判斷長度

五、[key] Redis Cluster 集羣的 mget 操做 Redis Cluster 的 MGET 操做，會到各分片取數據聚合，相比傳統的 M/S架構，性能會降低不少，請提早壓測和評估

六、[其餘] 嚴禁使用 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 語義。其好處：

一、可以根據某類 key 進行數據清理

二、可以根據某類 key 進行數據更新

三、可以方面瞭解到某類 key 的歸屬方和應用場景

四、爲統一化、平臺化作準備，減小技術變動

通常，一個 key 須要帶如下維度：業務、key 用途、變量等，各個維度使用 : 進行分隔，如下是幾個 key 的實例:

user:sex 用戶 10002232 的性別

msg:achi 201712 的用戶發言數量排行榜

End

適當的約束是架構成熟的必要條件，經過約定能達到規範是集體開發的最高境界。Redis用的多，也要用的穩，給點約束、立點規矩，生活將變的美好。經過二次封裝redis客戶端，直接阻斷，效果更佳。