一次線上redis實例cpu佔用率太高問題優化

前情提要：

最近接了大數據項目的postgresql運維，剛接過來他們的報表系統就出現高峯期訪問不了的問題，報表涉及實時數據和離線數據，離線讀pg，實時讀redis。而後天然而然就把redis也挪到咱們這邊優化了 -_-! 。在此次優化過程當中也是再次深入感覺到redis的各類坑

現象：

大數據報表週末晚上高峯期實時報表打不開，基本上處於不能使用狀態，實時報表主要訪問redis數據，監控發現Redis CPU佔用太高，高峯期2個從庫實例的CPU達到100%，因爲redis是單進程單線程結構，因此單核CPU達到100%致使查詢阻塞

當前架構：

1主1從 ，應用手動讀寫分離，持久化主從默認都開啓開啓rdb持久化，沒有作aof，參數基本走默認（灰常牛批 -_-！）

問題致使緣由排查：

1. redis持久化致使阻塞
2. 是否存在慢查詢
3. 主從存在頻繁全量同步）
4. value值是否過大
5. 架構問題，當前全部業務讀取僅在一個從庫讀取
6. 網絡問題
7. 鏈接數問題

分析：

首先看的網絡問題，跟運維小夥伴溝經過，結合監控結果發現，網絡基本上沒有問題，網卡流量也遠遠沒有到瓶頸，首先排除網絡問題。可是，在redis從庫的日誌中，發現有個報錯很頻繁：

47960:S 16 Apr 12:05:36.951 # Connection with master lost.
47960:S 16 Apr 12:05:36.951 * Caching the disconnected master state.
47960:S 16 Apr 12:05:37.799 * Connecting to MASTER 192.168.63.2:6379
47960:S 16 Apr 12:05:37.799 * MASTER <-> SLAVE sync started
47960:S 16 Apr 12:05:37.799 * Non blocking connect for SYNC fired the event.
47960:S 16 Apr 12:05:42.871 * Master replied to PING, replication can continue...
47960:S 16 Apr 12:05:42.873 * Trying a partial resynchronization (request 2cf6338d2d3a72131d5f2f18a0bd8c271302e058:228189063173).
47960:S 16 Apr 12:05:43.085 * Full resync from master: 2cf6338d2d3a72131d5f2f18a0bd8c271302e058:228814173990
47960:S 16 Apr 12:05:43.085 * Discarding previously cached master state.

看字面意思就是主從鏈接斷開了，從庫嘗試作增量同步還不成功，最後作了全量同步。
WTF？？？既然網絡沒問題，爲何鏈接斷了。OK，引出主從問題

而後主從出現了頻繁全量同步，如上面的日誌顯示，從庫鏈接斷開從連並嘗試增量同步失敗，結果作了全量同步。這個操做開銷很大：主庫bgsave->傳到從庫->從庫加載rbd到內存（加載的時候是沒法操做redis的）。出現這種狀況又有幾個緣由。。。

• replication backlog（master端）：用於保存主從同步數據的一塊內存緩衝區域（全部客戶端共享該內存），達到限制將會從新進行全量同步，這部份內存會包含在used_memory_human中，設置值參考bgrewrite所需的內存RDB: 500 MB of memory used by copy-on-write

repl-backlog-size

• replication buffer(master端)：redis每一個鏈接都分配了本身的緩衝區空間（從庫也至關因而一個客戶端鏈接）。處理完請求後，redis把響應數據放到緩衝區中，而後繼續下一個請求。repl-buffer存放的數據是下面3個時間內全部master數據更新操做，設置值參考：每秒的命令產生大小*（mast執行rdb bgsave產生snapshot的時間 + master發送rdb到slave網絡傳輸時間 + slave load rdb to memory 的時間）

client-output-buffer-limit normal 
client-output-buffer-limit slave    
client-output-buffer-limit pubsub

關於架構問題，其實早在報表高峯期讀取問題出現的初期，大數據的同事就提出增長redis從庫實例，作負載均衡的想法了。鑑於redis是單線程模型，只能用到一個cpu核心，多增長几個實例能夠多利用到幾個cpu核心這個想法確實也沒錯。當時因爲從庫物理機有富餘的內存資源，因此臨時新增了三個從庫實例，並添加haproxy輪詢訪問後端4個redis實例。總體架構變爲1主4從+haproxy作從庫負載均衡。可是我始終認爲，cpu高主要仍是跟具體的業務查詢有關，架構擴展應該是在單實例優化到最佳以後才考慮的。這就比如在mysql當中，有大量慢查詢致使cpu太高，你光靠擴展從庫而不去先優化SQL，擴展到何時是個頭呢？

慢查詢問題：某個促銷活動的晚上，大數據報表果真又準時出現打開慢的現象。redis依然是cpu佔用率爆滿。話很少說進入redis ，slowlog get 50 , 發現慢查詢中基本都是keys xxx* 這樣的查詢，這。。。我幾乎確定cpu佔用率跟這種慢查詢有很大關係了。執行時間在0.5秒左右，0.5秒對於redis來講應該是很是慢了。若是這樣的查詢比較多的話，那麼redis確實極可能出現阻塞，在看了下value值的大小，應該還好不算大。redis slowlog默認只保存在內存，只保留當前的128條，因此這也算是個小小的麻煩，不太好統計慢查詢發生的頻率

持久化策略：

rdb持久化：每次都是全量的bgsave，具體策略下面說。
缺點：
非實時
全量持久化
每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工做。 在數據集比較龐大時， fork()可能會很是耗時，形成服務器在某某毫秒內中止處理客戶端

aof持久化：每秒寫aof文件，實時性較高，增量寫，順序記錄語句，便於誤操做恢復
缺點：
bgrewrite重寫，fork進程，短暫阻塞
重寫時fork進程可能致使swap和OOM（預留1半內存）

簡單介紹完兩種持久化策略以後，最後給出我實際優化後的策略：
主/從業務庫關閉rdb和aof持久化，新增一臺從庫（不參與業務）單獨作rdb持久化，該從庫持久化配置：save 900 1 也就是900秒作一次bgrewrite，最多丟失15分鐘數據

鏈接數問題：
這塊目前來講因爲作了負載均衡，高峯期看haproxy入口的鏈接最大也就去到500-600，仍是有阻塞的狀況下，每一個redis實例connected_clients最多也就到100左右（能夠經過client list查看具體鏈接），排除鏈接數的問題。

結論

優化主要避免了持久化，以及頻繁主從全量同步帶來的性能影響。可是實際主要瓶頸仍是在慢查詢，若是keys xxx*這種查詢不能避免，那麼必定會形成阻塞

下面這張圖應該更加生動：

FAQ

一、主庫的used_memory_peak_human達到60.97G，實際上主庫的maxmemory只配置了32G

127.0.0.1:6379> info memory

Memory
used_memory:3531621728
used_memory_human:3.29G
used_memory_rss:70885924864
used_memory_peak:65461144384
used_memory_peak_human:60.97G
used_memory_lua:36864
mem_fragmentation_ratio:20.07
mem_allocator:libc

解決方式：內存碎片形成，查看資料說是大量寫入形成，目前沒有太好的解決方法，只能經過重啓進程釋放

二、redis過時的key會不會自動刪除？策略如何配置

redis過時的key當內存使用maxmemory纔會進行刪除

maxmemory-policy 六種方式：

* volatile-lru：（默認值）從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
* volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰
* volatile-ttl ： 從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰
* allkeys-lru ： 從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
* allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
* noeviction ： 禁止驅逐數據,永不過時，返回錯誤

三、redis主從同步原理（全量/增量）

一張圖一目瞭然：

複製積壓緩衝區=repl-backlog

redis2.8以前不支持增量備份
增量備份的兩個條件

1. slave帶來的runid是否當前master的runid
2. slave帶來的複製offset在master的backlog（複製積壓緩衝區）中還可否找到