前情提要：
最近接了大數據項目的postgresql運維，剛接過來他們的報表系統就出現高峰期訪問不了的問題，報表涉及實時數據和離線數據，離線讀pg，實時讀redis。然后自然而然就把redis也挪到我們這邊優化了 -_-! 。在這次優化過程中也是再次深刻感受到redis的各種坑
現象：
大數據報表周末晚上高峰期實時報表打不開，基本上處於不能使用狀態，實時報表主要訪問redis數據，監控發現Redis CPU占用過高，高峰期2個從庫實例的CPU達到100%，由於redis是單進程單線程結構，所以單核CPU達到100%導致查詢阻塞
當前架構：
1主1從 ，應用手動讀寫分離，持久化主從默認都開啟開啟rdb持久化，沒有做aof，參數基本走默認（灰常牛批 -_-！）
問題導致原因排查：
redis持久化導致阻塞
是否存在慢查詢
主從存在頻繁全量同步）
value值是否過大
架構問題，當前所有業務讀取僅在一個從庫讀取
網絡問題
連接數問題
好了，整理出一大堆問題之后，開始各種分析：
首先看的網絡問題，跟運維小伙伴溝通過，結合監控結果發現，網絡基本上沒有問題，網卡流量也遠遠沒有到瓶頸，首先排除網絡問題。但是，在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數據更新操作，設置值參考：每秒的命令產生大小*（以下3個時間之和）
master執行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
復制超時：
repl-timeout
最終參數優化調整如下（主庫）：
repl-backlog-size 512mb
repl-timeout 120
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 0 0 0
client-output-buffer-limit pubsub 32mb 8mb 60
架構問題，其實早在報表高峰期讀取問題出現的初期，大數據的同事就提出增加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，具體策略下面說。
缺點： 1、非實時
2、全量持久化
3、每次保存RDB的時候，Redis都要fork()出一個子進程，並由子進程來進行實際的持久化工作。 在數據集比較龐大時，fork()可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端
aof持久化：每秒寫aof文件，實時性較高，增量寫，順序記錄語句，便於誤操作恢復
缺點：1、bgrewrite重寫，fork進程，短暫阻塞
2、重寫時fork進程可能導致swap和OOM（預留1半內存）
簡單介紹完兩種持久化策略之后，最后給出我實際優化后的策略：
主/從業務庫關閉rdb和aof持久化，新增一台從庫（不參與業務）單獨做rdb持久化，該從庫持久化配置：save 900 1 也就是900秒做一次bgrewrite，最多丟失15分鍾數據
連接數問題，這塊目前來說由於做了負載均衡，高峰期看haproxy入口的連接最大也就去到500-600，還是有阻塞的情況下，每個redis實例connected_clients最多也就到100左右，排除連接數的問題
結論：優化主要避免了持久化，以及頻繁主從全量同步帶來的性能影響。但是實際主要瓶頸還是在慢查詢，如果keys xxx*這種查詢不能避免，那么一定會造成阻塞
下面這張圖應該更加生動：
最后，還有幾個待解決的問題記錄下：
1、主庫的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
解決方式：內存碎片造成，查看資料說是大量寫入造成，目前沒有太好的解決方法，只能通過重啟進程釋放
2、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 ： 禁止驅逐數據,永不過期，返回錯誤
3、redis主從同步原理（全量/增量）
一張圖一目了然：
復制積壓緩沖區=repl-backlog
redis2.8之前不支持增量備份
增量備份的兩個條件
slave帶來的runid是否當前master的runid
slave帶來的復制offset在master的backlog（復制積壓緩沖區）中還能否找到