Redis存在慢查詢(xún)導致請求延時(shí)

由于Redis主線(xiàn)程是單線(xiàn)程的，所以會(huì )存在慢查詢(xún)會(huì )導致redis請求延時(shí)，可以參考：

http://www.pzrlhr.cn/articles/2020/07/23/1595493094855.html

redis存在大value導致請求延時(shí)

可以通過(guò)下面命令查找大value:

redis-cli -p 6379 -h 127.0.0.1 --bigkeys
redis-cli -p 6379 -h 127.0.0.1 --memkeys

fork 耗時(shí)導致高并發(fā)請求延時(shí)

RDB 和 AOF 的時(shí)候會(huì )存在 RDB 快照生成、AOF rewrite，耗費磁盤(pán) IO 的過(guò)程。主進(jìn)程 fork 子進(jìn)程的時(shí)候，子進(jìn)程是需要拷貝父進(jìn)程的空間內存頁(yè)表的，也是會(huì )耗費一定的時(shí)間的一般來(lái)說(shuō)，如果父進(jìn)程內存有 1 個(gè) G 的數據，那么 fork 可能會(huì )耗費在 20ms 左右，如果是 10G~30G，那么就會(huì )耗費 20 * 10，甚至 20 * 30，也就是幾百毫秒的時(shí)間。

info stats 中的 latest_fork_usec，可以看到最近一次 fork 的時(shí)長(cháng)redis 單機 QPS 一般在幾萬(wàn)，fork 可能一下子就會(huì )拖慢幾萬(wàn)條操作的請求時(shí)長(cháng)，從幾毫秒變成 1 秒。

優(yōu)化思路：fork 耗時(shí)跟 redis 主進(jìn)程的內存有關(guān)系，一般控制 redis 的內存在 10GB 以?xún)?；否則 slave -> master 在全量復制等時(shí)候就可能會(huì )出現一些問(wèn)題。

AOF 的阻塞問(wèn)題

redis 將數據寫(xiě)入 AOF 緩沖區，單獨開(kāi)一個(gè)線(xiàn)程做 fsync 操作，每秒一次。但是 redis 主線(xiàn)程會(huì )檢查兩次 fsync 的時(shí)間，如果距離上次 fsync 時(shí)間超過(guò)了 2 秒，那么寫(xiě)請求就會(huì )阻塞everysec，最多丟失 2 秒的數據。一旦 fsync 超過(guò) 2 秒的延時(shí)，整個(gè) redis 就被拖慢。

優(yōu)化思路：優(yōu)化硬盤(pán)寫(xiě)入速度，建議采用 SSD，不要用普通的機械硬盤(pán)，SSD 大幅度提升磁盤(pán)讀寫(xiě)的速度。

主從復制延遲問(wèn)題

主從復制可能會(huì )超時(shí)嚴重，這個(gè)時(shí)候需要良好的監控和報警機制。在 info replication 中，可以看到 master 和 slave 復制的 offset，做一個(gè)差值就可以看到對應的延遲量，如果延遲過(guò)多，那么就進(jìn)行報警（可以寫(xiě)一個(gè) shell 腳本去監控）

最大打開(kāi)文件句柄

報錯如下：

Increased maximum number of open files to 10032 (it was originally set to 1024).

句柄詳解：http://www.freeoa.net/osuport/sysadmin/osfilehdnfd_1155.html

修改參數：

ulimit -n 10032 10032

tcp backlog

報錯提示：

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

TCP backlog 隊列設計初衷是為了緩存服務(wù)器無(wú)法立即處理的握手請求先回顧一下三次握手的過(guò)程：

從服務(wù)器的視角來(lái)看，需要接受兩個(gè)數據包（首個(gè)SYN，最后一個(gè)ACK）TCP backlog創(chuàng )建了兩個(gè)隊列來(lái)負責緩存已經(jīng)收到的首個(gè)SYN和已經(jīng)握手完成待應用層接收的連接負責緩存SYN的隊列叫SYN QUEUE負責緩存已完成連接叫ACCEPT QUEUE.

舉例子來(lái)說(shuō)明：如果坐火車(chē)來(lái)說(shuō)明的話(huà)，在春運時(shí)，火車(chē)站人滿(mǎn)為患，進(jìn)入火車(chē)站分為兩步：

1. 進(jìn)入候車(chē)室（SYN QUEUE）
2. 進(jìn)入站臺 （ACCEPT QUEUE）（握手完成）
3. 坐上火車(chē) （連接被應用程序使用）

一、進(jìn)入候車(chē)室入SYN QUEUE隊列：SYN QUEUE隊列的長(cháng)度可以理解為候車(chē)室的大小專(zhuān)業(yè)術(shù)語(yǔ)叫做BACKLOG，當一個(gè)新的旅客到達時(shí)，安檢員會(huì )根據候車(chē)室人數來(lái)決定是否允許旅客進(jìn)入.

二、登上站臺出SYN QUEUE隊列，進(jìn)入ACCEPT QUEUE隊列：當站臺可以容納旅客的時(shí)候，檢票員會(huì )將候車(chē)室的旅客按照先來(lái)后到的順序，將旅客安置在站臺，等候火車(chē)的到來(lái)，此時(shí)驗證已經(jīng)完成（你的車(chē)票已經(jīng)被剪了），TCP已經(jīng)完成的他的使命

三、擠進(jìn)火車(chē)出ACCEPT QUEUE隊列，當乘務(wù)員終于慢悠悠的打開(kāi)車(chē)廂大門(mén)的時(shí)候，所有旅客有序進(jìn)入火車(chē)中，握手完成

修改方法：

cat /proc/sys/net/core/somaxconn

echo 511 > /proc/sys/net/core/somaxconn

Redis集群主備緩存區滿(mǎn)了導致主備頻繁倒換

這個(gè)問(wèn)題常見(jiàn)于低版本的redis，或者是client-output-buffer-limit replica沒(méi)有使用默認值的時(shí)候

詳細參見(jiàn)：http://www.pzrlhr.cn/articles/2022/02/27/1645957902937.html