一、實現(xiàn)目標

簡潔，高效，可維護

二、鍵值設計規(guī)約

1 、 Redis key命名風格

【推薦】Redis key命名需具有可讀性以及可管理性，不該使用含義不清的key以及特別長的key名；

【強制】以英文字母開頭，命名中只能出現(xiàn)小寫字母、數(shù)字、英文點號(.)和英文半角冒號(??；

【強制】不要包含特殊字符，如下劃線、空格、換行、單雙引號以及其他轉義字符；

2 、命名規(guī)范

【強制】命名規(guī)范：業(yè)務模塊名:業(yè)務邏輯含義:其他:value類型

1 ）業(yè)務模塊名：具體的功能模塊

2）邏輯含義段：

【強制】不同業(yè)務邏輯含義使用英文半角冒號(:)分割，

【強制】同一業(yè)務邏輯含義段的單詞之間使用英文半角點號 (.)分割，用來表示一個完整的語義

3）value類型：

【強制】Redis key命名以key所代表的value類型結尾，以提高可讀性；

示例：user:basic.info:{userid}:string

3 、 value 設計

【強制】：拒絕bigkey(防止網(wǎng)卡流量、慢查詢)。

String類型控制在10KB以內(nèi)，Hash、List、Set、ZSet元素個數(shù)不要超過5000。

三、業(yè)務規(guī)范

1、【強制】使用Redis進行緩存時，必須進行申請。申請之前，需要拿出使用的合理方案，然后進行評估，避免隨意使用。

2、【強制】Redis應用場景應該是純緩存服務，功能主要是緩存數(shù)據(jù)，緩存數(shù)據(jù)可丟失，除特殊需求外，需提供可行性、可實施的方案。

3、【強制】 關于過期時間

Redis key一定要設置過期時間。要跟自己的業(yè)務場景，需要對key設置合理的過期時間?？梢栽趯懭雓ey時，就要追加過期時間；也可以在需要寫入另一個key時，刪除上一個key。

說明：

(1)若不設置的話，這些key會一直占用內(nèi)存不釋放，隨著時間的推移會越來越大，直到達到服務器的內(nèi)存上限，導致服務器宕機等重大事故；

(2)對于key的超時時長設置，可根據(jù)業(yè)務場景進行評估，設置合理有效期；

(3)某些業(yè)務的確需要長期有效，可以判斷即將到期時，重新設置有效期，避免引起熱點key問題。

4、【推薦】Redis的使用，應該考慮冷熱數(shù)據(jù)分離，不該將所有數(shù)據(jù)全部放到Redis中，對于使用不頻繁，且無關緊要的信息存入MySQL，或日志文件中，Redis的數(shù)據(jù)存儲全部都是在內(nèi)存中的，成本昂貴。

5、【推薦】Redis有數(shù)據(jù)丟失風險，程序處理數(shù)據(jù)時，應該考慮丟失后的重新加載過程。

6、【強制】禁止大key

大key數(shù)據(jù)存?Redis，除了帶來極大的內(nèi)存占用外，在并發(fā)高時，很容易就會將網(wǎng)卡流量占滿，進而造成整個服務器上的所有服務不可用。雖然Redis支持512MB大小的string，但是假設1mb的string大key，每秒重復寫入10次，就會導致寫入網(wǎng)絡IO達10MB;

(1)讀寫大key會導致超時嚴重，網(wǎng)卡流量占滿,甚至阻塞服務,更甚者導致宕機風險。

(2)如果刪除大key，DEL命令可能阻塞Redis進程數(shù)十秒，使得其他請求阻塞，對應用程序和Redis集群可用性造成嚴重的影響。

(3)每個key不要超過10Kb。

7、【強制】Redis一定不可使用Keys正則匹配操作。

8、【推薦】選擇合適的數(shù)據(jù)類型。

目前Redis支持的數(shù)據(jù)庫結構類型較多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空間索引（geospatial）等,需要根據(jù)業(yè)務場景選擇合適的類型。

在不能確定其它復雜數(shù)據(jù)結構?定優(yōu)于String類型時，避免使用Redis的復雜數(shù)據(jù)結構。 每種數(shù)據(jù)結構都有相應的使?場景，String類型是Redis中最簡單的數(shù)據(jù)類型，建議使用String類型。 但是考慮到具體的業(yè)務場景，綜合評估性能、存儲網(wǎng)絡等方面之后使用適當?shù)臄?shù)據(jù)結構。 需要根據(jù)業(yè)務場景選擇合適的類型，常見的如：String可以用作普通的K-V、簡單數(shù)據(jù)類類型等；Hash可以用作對象如居民、醫(yī)生等，包含較多屬性的信息；List可以用作息隊列、醫(yī)生同行/關注列表等；Set可以用于推薦；Sorted Set可以用于排行等。

9、【推薦】關于集合類操作

出現(xiàn)問題最多的就是超時問題，因為使用了O(N)的操作，導致服務超時，甚至服務不可用。

使用Set，Zset，List，Hash等集合類的O(N)操作時要評估當前元素個數(shù)的規(guī)模以及將來的增長規(guī)模，對于短期就可能變?yōu)榇蠹系膋ey，要預估O(N)操作的元素數(shù)量，避免全量操作，可以使用HSCAN，SSCAN，ZSCAN進行漸進操作。集合元素數(shù)量過大在使用過程中會影響Redis的實際性能，Hash類元素個數(shù)建議盡量不要超過100，集合類、鏈表類數(shù)據(jù)盡量不要超過10k。元素數(shù)量過大可考慮拆分成多個key進行處理。

到此這篇關于redis key命名規(guī)范的設計的文章就介紹到這了,更多相關redis key命名規(guī)范內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論