記一次事故看 Redis 開發規範
快點關注我們吧
一、背景
某一天中午,收到反饋,app卡頓甚至無響應,隨即監控中心報出大量慢請求。慢請求來源直指網關和 DP(集中鑑權中心)佔慢請求總數的 80%以上。
二、事故處理
-
10 分鐘,收集事故現場(thread dump,heap dump)重啟網關,慢請求暫時恢復
-
20 分鐘,定位為 darkportal 所使用的 redis 集羣異常(響應時間 200ms)
-
30 分鐘,分析 redis 和其他業務線共用,會受業務線影響,決定申請新的 redis 實例,將 dp 的 redis 遷移到新集羣。
-
24 小時,redis 遷移完成,慢請求消失。
三、Root Cause 分析
24hDP應用的三波慢請求
Redis 響應時間異常
發現 Redis 中大量的慢查詢
通過 slowlog-log-slower-than 等命令查詢慢查詢,發現大量明令禁止在生產環境使用的命令在這段 時間被執行。
結論
由於darkportal的redis 和其他業務線共用,業務線應用引入了大量的耗時操作,最終引發故障。這 也給我們敲響警鐘。
管理角度,梳理核心應用,積極將 redis 等基礎組件隔離,敦促業務線加大力度做代碼 review。
運維角度,服務端禁用高危命令,做好中間件和核心接口的監控
四、處理方案
1. 【服務端】服務器端禁用高危險性命令
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""
2. 【客户端】在客户端 SDK 中過濾掉高危命令
3. 【吿警和預防】加大監控力度,尤其是中間件和核心業務接口的監控
4. 【業務隔離】這次故障另一個關鍵點是,錯誤發生在非核心業務,卻影響了核心業務,應將核心業務的 redis 獨立出來,避免相互干擾和故障的放大,尤其是要避免非核心業務故障對核心業務的影響。(不 僅限於 redis)
五、Redis 開發和使用規範
1.key名設計
1) 【建議】: 可讀性和可管理性
以業務名(或數據庫名)為前綴(防止 key 衝突),用冒號分隔,比如業務名:
表名:id
ugc:video:1
2)【建議】:簡潔性
保證語義的前提下,控制 key 的長度,當 key 較多時,內存佔用也不容忽視,例如:
user:{uid}:friends:messages:{mid}
u:{uid}:fr:m:{mid}
3) 【強制】:不要包含特殊字符
反例:包含空格、換行、單雙引號以及其他轉義字符
2. value 設計
1) 【強制】:拒絕 bigkey
bigkey 會導致內存分佈不均勻,操作較慢會導致阻塞,對單線程而言阻塞的危害不言而喻,同時 也可能會導致網絡阻塞。string 類型控制在 10KB 以內,非字符串類型(hash、list、set、zset)元素個數不要超過 5000。反例:一個包含 200 萬個元素的 list。
非字符串的 bigkey,不要使用 del 刪除,使用 hscan、sscan、zscan 方式漸進式刪除,同時要注 意防止 bigkey 過期時間自動刪除問題(例如一個 200 萬的 zset 設置 1 小時過期,會觸發 del 操作,造 成阻塞,而且該操作不會不出現在慢查詢中(latency 可查))
2) 【推薦】:選擇適合的數據類型
例如:實體類型(要合理控制和使用數據結構內存編碼優化配置,例如 ziplist,但也要注意節省內 存和性能之間的平衡)反例:
set user:1:name tom
set user:1:age 19
set user:1:favor football
正例:
set user:1:name tom
set user:1:age 19
set user:1:favor football
3) 【推薦】:控制 key 的生命週期。
建議使用 expire 設置過期時間(條件允許可以打散過期時間,防止集中過期,bigkey 需特殊處理 參考附錄),不過期的數據重點關注 idletime。
3、命令使用
1. 【推薦】 O(N)命令關注 N 的數量
例如 hgetall、lrange、smembers、zrange、sinter 等並非不能使用,但是需要明確 N 的值。有遍歷的 需求可以使用 hscan、sscan、zscan 代替。
2. 【推薦】:禁用命令
禁止線上使用 keys、flushall、flushdb 等,通過 redis 的 rename 機制禁掉命令,或者使用 scan 的 方式漸進式處理。
3. 【推薦】合理使用 select
redis 的多數據庫較弱,使用數字進行區分,很多客户端支持較差,同時多業務用多數據庫實際還是單 線程處理,會有干擾。
4. 【推薦】使用批量操作提高效率
原生命令:例如 mget、mset。
非原生命令:可以使用 pipeline 提高效率。
但要注意控制一次批量操作的元素個數(例如 500 以內,實際也和元素字節數有關)。
注意兩者不同:
1. 原生是原子操作,pipeline 是非原子操作。
2. pipeline 可以打包不同的命令,原生做不到
3. pipeline 需要客户端和服務端同時支持。
5. 【建議】Redis 事務功能較弱,不建議過多使用
Redis 的事務功能較弱(不支持回滾),而且集羣版本(自研和官方)要求一次事務操作的 key 必須在一個 slot 上(可以使用 hashtag 功能解決)
6. 【建議】Redis 集羣版本在使用 Lua 上有特殊要求:
1) 所有 key 都應該由 KEYS 數組來傳遞,redis.call/pcall 裏面調用的 redis 命令,key 的位置, 必須是 KEYS array, 否則直接返回 error,
"-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array"
2) 所有 key,必須在 1 個 slot 上,否則直接返回 error,
"-ERR eval/evalsha command keys must in same slot"
7. 【建議】必要情況下使用 monitor 命令時,要注意不要長時間使用。
六、客户端使用
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.【推薦】設置合理的密碼
如有必要可以使用 SSL 加密訪問
5.【建議】選擇合適的內存淘汰策略(maxmemory-policy)
默認策略是 volatile-lru,即超過最大內存後,在過期鍵中使用 lru 算法進行 key 的剔除,保證不過
期數據不被刪除,但是可能會出現 OOM 問題。(注:這不一定適合所有場景)
其他策略如下:
1) allkeys-lru:根據 LRU 算法刪除鍵,不管數據有沒有設置超時屬性,直到騰出足夠空間為止。
2) allkeys-random:隨機刪除所有鍵,直到騰出足夠空間為止。
3) volatile-random:隨機刪除過期鍵,直到騰出足夠空間為止。
4) volatile-ttl:根據鍵值對象的 ttl 屬性,刪除最近將要過期數據。如果沒有,回退到 noeviction
策略。
5) noeviction:不會剔除任何數據,拒絕所有寫入操作並返回客户端錯誤信息"(error) OOM command
not allowed when used memory",此時 Redis 只響應讀操作。
七 、附錄:正確刪除 bigkey
下面操作可以使用 pipeline 加速。redis 4.0 已經支持 key 的異步刪除,歡迎使用。
1.Hash 刪除: hscan+hdelpublic void delBigHash(String host, int port, String password, String bigHashKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult<Entry<String, String>> scanResult = jedis.hscan(bigHashKey, cursor, scanParams);
List<Entry<String, String>> entryList = scanResult.getResult();
if (entryList != null && !entryList.isEmpty()) {
for (Entry<String, String> entry : entryList) {
jedis.hdel(bigHashKey, entry.getKey());
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//刪除 bigkey
jedis.del(bigHashKey);
}
2. List 刪除: Itrim
public void delBigList(String host, int port, String password, String bigListKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
long llen = jedis.llen(bigListKey);
int counter = 0;
int left = 100;
while (counter < llen) {
//每次從左側截掉 100 個
jedis.ltrim(bigListKey, left, llen);
counter += left;
}
//最終刪除 key
jedis.del(bigListKey);
}
3. Set 刪除: sscan + srem
public void delBigSet(String host, int port, String password, String bigSetKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult<String> scanResult = jedis.sscan(bigSetKey, cursor, scanParams);
List<String> memberList = scanResult.getResult();
if (memberList != null && !memberList.isEmpty()) {
for (String member : memberList) {
jedis.srem(bigSetKey, member);
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//刪除 bigkey
jedi
4. SortedSet 刪除: zscan + zrem
public void delBigZset(String host, int port, String password, String bigZsetKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult<Tuple> scanResult = jedis.zscan(bigZsetKey, cursor, scanParams);
List<Tuple> tupleList = scanResult.getResult();
if (tupleList != null && !tupleList.isEmpty()) {
for (Tuple tuple : tupleList) {
jedis.zrem(bigZsetKey, tuple.getElement());
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//刪除 bigkey
jedis.del(bigZsetKey);
關注我獲得
更多精彩