1、問題描述
業務反饋，出現很多連接redis的read timed out的報錯
2、問題分析及解決
由於redis是單線程處理的，所有redis接收到命令，都會進入到隊列中，等待執行。
當客戶端，由於等待時間過長，沒有接收到server端返回的數據，就是出現超時的報錯。
程序裏，jedis客戶端，默認的超時時間是2s。
所以，懷疑是redis端在執行緩慢的命令，超過了客戶端能夠等待的最大的時間。
那麼，在redis服務端，命令執行過慢，會在慢日誌中進行記錄。
所以，查看慢日誌
進入到redis客戶端中，執行下面的命令
2.1、查看redis中設置的慢日誌記錄時間
這個參數的意思是，當在redis中執行的命令，超過這個時間，就會記錄慢日誌
10.1x.xxx.138:30001> config get slowlog-log-slower-than "slowlog-log-slower-than" "10000"
查詢結果：10000（微秒,us）= 10毫秒（ms）
表示，當redis中執行的命令，超過10毫秒的，就會被記錄。
2.2、redis默認會記錄多少條慢日誌
xxxxxx:30001> config get slowlog-max-len "slowlog-max-len" "128"
查詢結果是128條。也就是隻會記錄128條慢日誌記錄。
OK，參數已經都明白了，接下去看當前記錄的redis的情況
2.3、查看慢日誌
xxx:30001> slowlog get 128
如果get後面什麼都不加，默認返回10條。
這裏返回全部的128條。
將結果輸出到一個文件裏面，查看結果如下（列出部分數據）：
3965090 # slowlog的id 1700478020 # unix時間戳， 2999271 # 執行命令的時間，單位是微秒（us） KEYS xxcsdfADG:{${ds}_lock}:lock_idx_trans_pk_de* ?:0 3965089 1700478017 5182858 KEYS xxcsdfDATA:{${ds}_lock}:lock_idx_trans_pk_de* ?:0 3965088 1700478012 3007463 KEYS xxcsdfADG:{${ds}_lock}:lock_idx_trans_pk_ds* xxxxx.141:46855 3965087 1700478009 5234263 KEYS xxcsdfDATA:{${ds}_lock}:lock_idx_trans_pk_de* ?:0 3965086 1700478004 3038860 KEYS xxcsdfADG:{${ds}_lock}:lock_idx_trans_pk_de* xxxxx.141:46855
發現有執行，超過2秒的
3965089 1700478017 5182858 # 大於5秒 ，5182858微秒 = 51828毫秒 = 5秒 KEYS xxcsdfDATA:{${ds}_lock}:lock_idx_trans_pk_de* ?:0
這樣就找到執行慢的語句了。
具體的執行時間，可以將時間戳進行轉換
[root@xxcsdfztsjb-node-01 ~]# date -d @1700478017 Mon Nov 20 19:00:17 CST 2023 [root@xxcsdfztsjb-node-01 ~]#
然後，接下來，就基於這個語句讓研發繼續查就好了。
2.4、慢日誌記錄順序說明
redis默認記錄128條，慢日誌，序號 從1到128.
當超過128條的時候，第一條會被首先覆蓋掉，然後以此類推。
也就是說：
執行slowlog get 128時，最上面的記錄是最新的。
這一點，也可以通過unix時間戳轉換工具來進行查看和驗證。