1、問題描述
某系統在2017/07/21監控高耗時交易時發現在兩個時間點快取操作耗時較高，詳情如下：
時間點一:2017/07/21 15:24:51
logtime=2017-07-21 15:24:51.242 costtime=372.078ms class=com.dap.cache.api.cacheclien
時間點二: 2017/07/21 15:31:16
logtime=2017-07-21 15:31:16.412 costtime=455.279ms class=com.dap.cache.api.cacheclient
2、排查過程
2.1慢日誌配置
生產環境redis配置了慢日誌引數
檢視redis慢日誌配置，登陸redis伺服器，使用redis-cli客戶端連線redis server
127.0.0.1:6301> config get slow*
1) "slowlog-log-slower-than"
2) "10000"
3) "slowlog-max-len"
4) "1000"
127.0.0.1:6301>
慢日誌說明:
config get slow* 查詢有關慢日誌的配置資訊
查詢結果第一條: 1) "slowlog-log-slower-than" 慢日誌閾值配置項
查詢結果第二條: 2) "10000" 閾值 ,單位微秒，此處為10毫秒，即超過10毫秒的操作都會記錄下來
查詢結果第三條: 3) "slowlog-max-len" 慢日誌記錄儲存數量，如果儲存數量已滿，會刪除最早的記錄，最新的記錄追加進來
查詢結果第四條: 4) "1000" 慢日誌記錄儲存數量的閾值，此處儲存1000條記錄
檢視慢日誌記錄
檢視redis慢日誌記錄，登陸redis伺服器，使用redis-cli客戶端連線redis server
生產環境有三個節點，慢日誌記錄分別如下:
節點一:
127.0.0.1:6301> slowlog get
1) 1) (integer) 68
2) (integer) 1500873303
3) (integer) 25972
4) 1) "bgrewriteaof"
2) 1) (integer) 67
2) (integer) 1500778503
3) (integer) 25279
4) 1) "bgrewriteaof"
3) 1) (integer) 66
2) (integer) 1500680103
3) (integer) 24432
4) 1) "bgrewriteaof"
4) 1) (integer) 65
2) (integer) 1500621891
3) (integer) 1186934
4) 1) "keys"
2) "*cap:*"
5) 1) (integer) 64
2) (integer) 1500621779
3) (integer) 1190078
4) 1) "keys"
2) "*"
6) 1) (integer) 63
2) (integer) 1500602102
3) (integer) 22998
4) 1) "bgrewriteaof"
7) 1) (integer) 62
2) (integer) 1500530702
3) (integer) 22807
4) 1) "bgrewriteaof"
8) 1) (integer) 61
2) (integer) 1500458102
3) (integer) 21908
4) 1) "bgrewriteaof"
9) 1) (integer) 60
2) (integer) 1500424802
3) (integer) 21208
4) 1) "bgrewriteaof"
10) 1) (integer) 59
2) (integer) 1500352202
3) (integer) 20436
4) 1) "bgrewriteaof"
127.0.0.1:6301>
慢日誌說明:
slowlog get 查詢當前所有的慢日誌記錄
顯示結果列表，最左側 1) 到 10) 有10條記錄
已第四條慢日誌為例說明如下:
4) 1) (integer) 65
2) (integer) 1500621891
3) (integer) 1186934
4) 1) "keys"
2) "*cap:*"
4) 1) (integer) 65
值65資料型別為integer，表示該條日誌的id
2) (integer) 1500621891
值1500621891資料型別為integer，表示操作redis的unix時間戳，單位秒。
3) (integer) 1186934
操作耗時，單位微秒
4) 1) "keys"
操作redis的命令 keys
2) "*cap:*"
操作redis的命令keys 的引數，即查詢所有包含cap字串的key
把操作redis的unix時間戳換算成北京時間為 2017/7/21 15:24:51 ，與某系統交易耗時的日誌時間點一吻合。某系統交易耗時時間點二的問題也是如此。
結論：redis命令keys * 、 keys ***** 會遍歷所有key，以查詢符合條件的key，當資料量較大時該命令比較耗時，因為redis是單執行緒，當該命令執行的過程當中會阻塞其他命令請求，如果此時應用系統請求redis，所有的請求都會等待。在生環境中，嚴禁使用keys * 、 keys *****，最好的辦法是禁用相關命令。
補充說明：慢日誌中的"bgrewriteaof"是redis fork的另外的執行緒在執行aof檔案重新，該操作不會影響應用對redis的讀寫請求。
redis排重 使用Redis實現實時排名
redis用途很廣泛，分布式使用者session快取 爬蟲url佇列 活動頁面的動態列表資訊等。使用redis實現排行榜系統也是很常見的方案。假如設計乙個積分排名系統。如果積分資料都存放在資料庫中，積分的更新是動態的，每次訪問排行頁面都需要對資料進行重新排序，在真實的產品應用中幾乎是不可接受的。re...
redis排重 使用 Redis 實現排行榜功能
排行榜功能是乙個很普遍的需求。使用 redis 中有序集合的特性來實現排行榜是又好又快的選擇。一般排行榜都是有實效性的，比如 使用者積分榜 如果沒有實效性一直按照總榜來排，可能榜首總是幾個老使用者，對於新使用者來說，那真是太令人沮喪了。首先，來個 今日積分榜 吧，排序規則是今日使用者新增積分從多到少...
redis排重 使用redis進行排行榜的小秘訣
前言 在日常一些簡單的活動開發中，我經常會碰到需要對使用者的分值等進行排行，此時一般會選擇redis的有序集合對使用者的分數進行儲存，但是不同的場景排行榜的方式也略有不同，以下根據自己日常的開發進行了一下歸納總結 redis 有序集合 sorted set 首先簡單介紹下什麼是有序集合。redis ...