1、fork耗時導致高並發請求延時
RDB和AOF的時候，其實會有生成RDB快照，AOF rewrite，耗費磁盤IO的過程，主進程fork子進程 fork的時候，子進程是需要拷貝父進程的空間內存頁表的，也是會耗費一定的時間的 一般來說，如果父進程內存有1個G的數據，那么fork可能會耗費在20ms左右，如果是10G~30G，那么就會耗費20 * 10，甚至20 * 30，也就是幾百毫秒的時間 info stats中的latest_fork_usec，可以看到最近一次form的時長 redis單機QPS一般在幾萬，fork可能一下子就會拖慢幾萬條操作的請求時長，從幾毫秒變成1秒 優化思路 fork耗時跟redis主進程的內存有關系，一般控制redis的內存在10GB以內，slave -> master，全量復制
2、AOF的阻塞問題
redis將數據寫入AOF緩沖區，單獨開一個現場做fsync操作，每秒一次
但是redis主線程會檢查兩次fsync的時間，如果距離上次fsync時間超過了2秒，那么寫請求就會阻塞
everysec，最多丟失2秒的數據
一旦fsync超過2秒的延時，整個redis就被拖慢
優化思路
優化硬盤寫入速度，建議采用SSD，不要用普通的機械硬盤，SSD，大幅度提升磁盤讀寫的速度
3、主從復制延遲問題
主從復制可能會超時嚴重，這個時候需要良好的監控和報警機制
在info replication中，可以看到master和slave復制的offset，做一個差值就可以看到對應的延遲量
如果延遲過多，那么就進行報警
4、主從復制風暴問題
如果一下子讓多個slave從master去執行全量復制，一份大的rdb同時發送到多個slave，會導致網絡帶寬被嚴重占用
如果一個master真的要掛載多個slave，那盡量用樹狀結構，不要用星型結構
5、vm.overcommit_memory
0: 檢查有沒有足夠內存，沒有的話申請內存失敗 1: 允許使用內存直到用完為止 2: 內存地址空間不能超過swap + 50% 如果是0的話，可能導致類似fork等操作執行失敗，申請不到足夠的內存空間 cat /proc/sys/vm/overcommit_memory echo "vm.overcommit_memory=1" >> /etc/sysctl.conf sysctl vm.overcommit_memory=1
6、swapiness
cat /proc/version，查看linux內核版本 如果linux內核版本<3.5，那么swapiness設置為0，這樣系統寧願swap也不會oom killer（殺掉進程） 如果linux內核版本>=3.5，那么swapiness設置為1，這樣系統寧願swap也不會oom killer 保證redis不會被殺掉 echo 0 > /proc/sys/vm/swappiness echo vm.swapiness=0 >> /etc/sysctl.conf
7、最大打開文件句柄
ulimit -n 10032 10032 自己去上網搜一下，不同的操作系統，版本，設置的方式都不太一樣
8、tcp backlog
cat /proc/sys/net/core/somaxconn echo 511 > /proc/sys/net/core/somaxconn
