文章目錄

一、鍵值設計

1.key名設計

【強制】以英文字母開頭，命名中只能出現小寫字母、數字、英文點號.和英文半形冒號:

【強制】不該使用含義不清的key以及特別長的key名

【強制】禁止使用Redis保留字命名key

【強制】命名規範：業務模組名:業務邏輯含義:其他

1)業務模組名：具體的功能模組
2)業務邏輯含義段：
【強制】不同業務邏輯含義使用英文半形冒號(:)分割，
【強制】同一業務邏輯含義段的單詞之間使用英文半形點號 (.)分割，用來表示一個完整的語義

示例： user:basic.info:1 注：1是使用者id

【推薦】簡潔性

保證語義的前提下，控制key的長度，當key較多時，記憶體佔用也不容忽視，例如：

user:{uid}:friends:messages:{mid}簡化為u:{uid}:fr:m:{mid}

2.value設計

【強制】拒絕bigkey

string型別控制在10KB以內，hash、list、set、zset元素個數不要超5000。以防止網絡卡流量、慢查詢。反例：一個包含200萬個元素的list。非字串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題（例如一個200萬的zset設定1小時過期，會觸發del操作，造成阻塞。）

【強制】禁止在Redis中儲存敏感的明文資料

【推薦】選擇適合的資料型別

例如：
反例：

set user:1:name tom
set user:1:age 19
set user:1:favor football

正例：

hmset user:1 name tom age 19 favor football

3.【強制】關於過期時間

Redis key一定要設定過期時間。要跟自己的業務場景，需要對key設定合理的過期時間。可以在寫入key時，就要追加過期時間；也可以在需要寫入另一個key時，刪除上一個key。
說明：
(1)若不設定的話，這些key會一直佔用記憶體不釋放，隨著時間的推移會越來越大，直到達到伺服器的記憶體上限，導致伺服器宕機等重大事故；

二、命令使用

1.【推薦】 O(N)命令關注N的數量

例如hgetall、lrange、smembers、zrange、sinter等並非不能使用，但是需要明確N的值。有遍歷的需求可以使用hscan、sscan、zscan代替。

【強制】嚴禁對 zset 的不設範圍操作

zrange、zrangebyscore等多個操作 zset 的函式，嚴禁使用 zrange myzset 0 -1 等這種不設定範圍的操作。請指定範圍，如zrange myzset 0 100。如不確定長度，可使用 zcard 判斷長度。

【強制】嚴禁對大資料量 key 使用 hgetall

hgetall會取出相關 HASH 的所有資料，如果資料條數過大，同樣會引起阻塞，請確保業務可控。如不確定長度，可使用hlen先判斷長度。

2.【強制】禁用命令

禁止線上使用keys、flushall、flushdb等，通過Redis的rename機制禁掉命令，或者使用scan的方式漸進式處理。

反例：使用keys 正則匹配操作查詢某個key

3.【推薦】使用批量操作提高效率

原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。

但要注意控制一次批量操作的元素個數（例如500以內，實際也和元素位元組數有關）。
注意兩者不同：

1. 原生是原子操作，pipeline是非原子操作。
2. pipeline可以打包不同的命令，原生做不到
3. pipeline需要客戶端和服務端同時支援。

注意：Redis-Cluster架構下如需使用pipeline，需要客戶端的支援（比如開源的jedis沒有提供叢集模式下pipeline介面的實現，需要自己改造封裝）

4.【推薦】Redis事務功能較弱，不推薦過多使用

Redis的事務功能較弱（不支援回滾），而且叢集版本要求一次事務操作的key必須在一個slot上（可以使用hashtag功能解決）

5.【慎用】關於hashtag功能

hashtag功能可讓相關key落位在同一個slot，集中在同一節點，不大推薦使用。
如果確實需要用，需控制同一hashtag的數量。

6.【推薦】根據業務場景選擇資料型別

目前Redis支援的資料庫結構型別較多：字串(String)，雜湊(Hash)，列表(List)，集合(Set)，有序集合(Sorted Set)， Bitmap， HyperLogLog和地理空間索引(geospatial)等，需要根據業務場景選擇合適的型別。
在不能確定其它複雜資料結構⼀定優於String型別時，避免使用Redis的複雜資料結構。 每種資料結構都有相應的使⽤場景，String型別是Redis中最簡單的資料型別，推薦使用String型別。 但是考慮到具體的業務場景，綜合評估效能、儲存網路等方面之後使用適當的資料結構。 需要根據業務場景選擇合適的型別，常見的如：String可以用作普通的K-V、簡單資料類型別等；Hash可以用作物件如使用者等，包含較多屬性的資訊；List可以用作息佇列、關注列表等；Set可以用於推薦；Sorted Set可以用於排行等。

三、客戶端使用

1.【推薦】避免多個應用使用一個Redis例項

正例：不相干的業務拆分，公共資料做服務化。

2.【推薦】使用連線池

使用帶有連線池的資料庫，可以有效控制連線，同時提高效率，標準使用方式：

執行命令如下：
Jedis jedis = null;
try {
  jedis = jedisPool.getResource();
  //具體的命令
  jedis.executeCommand()
} catch (Exception e) {
  logger.error("op key {} error: " + e.getMessage()， key， e);
} finally {
  //注意這裡不是關閉連線，在JedisPool模式下，Jedis會被歸還給資源池。
  if (jedis != null) 
    jedis.close();
}

3.【推薦】高流量時做好熔斷

高併發下推薦客戶端新增熔斷功能（例如netflix hystrix）

4.【強制】auth訪問

Redis叢集應設定密碼訪問

5.【推薦】記憶體策略

根據自身業務型別，選好maxmemory-policy（最大記憶體淘汰策略），設定好過期時間。
預設策略是volatile-lru，即超過最大記憶體後，在過期鍵中使用lru演算法進行key的剔除，保證不過期資料不被刪除，但是可能會出現OOM問題。
其它策略如下：

• allkeys-lru：根據LRU演算法刪除鍵，不管資料有沒有設定超時屬性，直到騰出足夠空間為止。
• allkeys-random：隨機刪除所有鍵，直到騰出足夠空間為止。
• volatile-random：隨機刪除過期鍵，直到騰出足夠空間為止。
• volatile-ttl：根據鍵值物件的ttl屬性，刪除最近將要過期資料。如果沒有，回退到noeviction策略。
• noeviction：不會剔除任何資料，拒絕所有寫入操作並返回客戶端錯誤資訊"(error) OOM command not allowed when used memory"，此時Redis只響應讀操作。

6.【推薦】注意key的過期時間設定

在某些業務高峰期（如運營活動時的線上報名），key值過期時間設定過短或者過於集中容易造成快取穿透，導致大量請求直接打到 MySql資料庫。

7.【慎用】將Redis做為訊息佇列

如沒有非常特殊的需求，嚴禁將Redis 當作訊息佇列使用。Redis 當作訊息佇列使用，會有容量、網路、效率、功能方面的多種問題。

四、參考文獻