一個服務，邏輯很簡單，從redis讀取數據返回給調用方；每次調用處理正常時間在0～20左右，沒有超過150的.然而最近頻頻報超時，查了下發現超時的請求響應時間竟然有1000多ms，百思不得其解。大腿指出，可能是dump導致的超時。果然不讀取dump的主redis后立馬好了，超時由400減少到9，到底是怎么回事呢？哈哈，我百度了一下
一 redis-dump
redis-dump是一個借助第三方的工具，用來實現redis的備份和還原，即實現redis的持久化。redis持久化有兩種方式：RDB和AOF
其中，RDB方式按照一定的時間間隔對數據集創建基於時間點的快照。是Redis數據集的基於時間點的緊湊的副本，非常適合於備份場景。比如每個小時對RDB文件做一次小的歸檔，每天對RDB文件做一次大的歸檔，每月對RDB文件做一次更大的歸檔。這樣可以在必要的時刻選擇不同的備份版本進行數據恢復。由於是一個緊湊的文件，易於傳輸到遠程數據中心或Amazon S3，因此RDB非常適合於災難回復。
二 服務超時日志分析
該服務使用用rdb模式進行redis的持久化，每900ms進行一次備份，通過日志信息發現，超時通常發生在bgsave時。bgsave命令會fork一個子進程，子進程會將redis數據庫信息dump到rdb文件中。服務中使用的主redis每隔一段時間進行一次離線數據備份，由於現在的redis中數據量較大，在此期間程序中通過主redis的節點進行查詢的速度會受到影響。
三 超時原因，redis讀取超時還可能有以下原因
1. 網絡。Redis的處理與網絡息息相關，如果網絡出現閃斷則容易發生redis超時的狀況。如果出現這種狀況首先應查看redis機器網絡帶寬信息，判斷是否有閃斷情況發生。
2. 內存。redis所有的數據都放在內存里，當物理內存不夠時，linux os會使用swap內存，導致內存交換發生，這時如果有redis調用命令就會產生redis超時。這里可以通過調整/proc/sys/vm/swappiness參數，來設置物理內存使用超過多少就會進行swap。
3. 3. Redis單進程處理命令。Redis支持udp和tcp兩種連接，redis客戶端向redis服務器發送包含redis命令的信息，redis服務器收到信息后解析命令后執行相應的操作，redis處理命令是串行的，一些慢命令例如sort，hgetall,union,mget都會使得單命令處理時間較長，容易引起后續命令time out.所以我們第一需要從業務上盡量避免使用慢命令，如將hash格式改為kv自行解析，第二增加redis實例個數，每個redis服務器調用盡量少的慢命令。
具體這塊內容我了解的不是很清楚，后續完善吧，mark。