前情提要：
最近接了大數(shù)據(jù)項目的postgresql運維，剛接過來他們的報表系統(tǒng)就出現(xiàn)高峰期訪問不了的問題缩幸，報表涉及實時數(shù)據(jù)和離線數(shù)據(jù)千贯，離線讀pg，實時讀redis送朱。然后自然而然就把redis也挪到我們這邊優(yōu)化了娘荡。在這次優(yōu)化過程中也是再次深刻感受到redis的各種坑
現(xiàn)象：
大數(shù)據(jù)報表周末晚上高峰期實時報表打不開干旁，基本上處于不能使用狀態(tài)，實時報表主要訪問redis數(shù)據(jù)炮沐，監(jiān)控發(fā)現(xiàn)Redis?CPU占用過高争群，高峰期2個從庫實例的CPU達到100%，由于redis是單進程單線程結(jié)構(gòu)大年，所以單核CPU達到100%導(dǎo)致查詢阻塞
當(dāng)前架構(gòu)：
1主1從 换薄，應(yīng)用手動讀寫分離，持久化主從默認(rèn)都開啟開啟rdb持久化翔试，沒有做aof轻要，參數(shù)基本走默認(rèn)
問題導(dǎo)致原因排查：
redis持久化導(dǎo)致阻塞
是否存在慢查詢
主從存在頻繁全量同步）
value值是否過大
架構(gòu)問題，當(dāng)前所有業(yè)務(wù)讀取僅在一個從庫讀取
網(wǎng)絡(luò)問題
連接數(shù)問題
整理出一大堆問題之后垦缅，開始盲目分析：
首先看的網(wǎng)絡(luò)問題冲泥，跟運維溝通過，結(jié)合監(jiān)控結(jié)果發(fā)現(xiàn)失都，網(wǎng)絡(luò)基本上沒有問題柏蘑，網(wǎng)卡流量也遠(yuǎn)遠(yuǎn)沒有到瓶頸，首先排除網(wǎng)絡(luò)問題粹庞。但是咳焚，在redis從庫的日志中，發(fā)現(xiàn)有個報錯很頻繁：
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流码？又官？？既然網(wǎng)絡(luò)沒問題漫试，為什么連接斷了六敬。OK，引出主從問題
主從出現(xiàn)了頻繁全量同步驾荣，如上面的日志顯示外构，從庫連接斷開從連并嘗試增量同步失敗，結(jié)果做了全量同步播掷。這個操作開銷很大：主庫bgsave->傳到從庫->從庫加載rbd到內(nèi)存（加載的時候是無法操作redis的）审编。出現(xiàn)這種情況又有幾個原因。歧匈。垒酬。
replication backlog（master端）：用于保存主從同步數(shù)據(jù)的一塊內(nèi)存緩沖區(qū)域（所有客戶端共享該內(nèi)存），達到限制將會重新進行全量同步，這部分內(nèi)存會包含在used_memory_human中勘究，設(shè)置值參考bgrewrite所需的內(nèi)存RDB: 500 MB of memory used by copy-on-write
通過增大repl-backlog-size解決
replication buffer(master端)：redis每個連接都分配了自己的緩沖區(qū)空間（從庫也相當(dāng)于是一個客戶端連接）矮湘。處理完請求后，redis把響應(yīng)數(shù)據(jù)放到緩沖區(qū)中乱顾，然后繼續(xù)下一個請求板祝。repl-buffer存放的數(shù)據(jù)是下面3個時間內(nèi)所有master數(shù)據(jù)更新操作宫静，設(shè)置值參考：每秒的命令產(chǎn)生大小*（以下3個時間之和）
master執(zhí)行rdb bgsave產(chǎn)生snapshot的時間
master發(fā)送rdb到slave網(wǎng)絡(luò)傳輸時間
slave load rdb to memory 的時間
? ? ?主要參數(shù)：
client-output-buffer-limit normal?
client-output-buffer-limit slave?
client-output-buffer-limit pubsub?
復(fù)制超時：
repl-timeout
? ? ? ? 最終參數(shù)優(yōu)化調(diào)整如下（主庫）：
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
架構(gòu)問題走净，其實早在報表高峰期讀取問題出現(xiàn)的初期，大數(shù)據(jù)的同事就提出增加redis從庫實例孤里，做負(fù)載均衡的想法了伏伯。鑒于redis是單線程模型，只能用到一個cpu核心捌袜，多增加幾個實例可以多利用到幾個cpu核心這個想法確實也沒錯说搅。當(dāng)時由于從庫物理機有富余的內(nèi)存資源，所以臨時新增了三個從庫實例虏等，并添加haproxy輪詢訪問后端4個redis實例弄唧。整體架構(gòu)變?yōu)?主4從+haproxy做從庫負(fù)載均衡。但是霍衫，cpu高主要還是跟具體的業(yè)務(wù)查詢有關(guān)候引，架構(gòu)擴展應(yīng)該是在單實例優(yōu)化到最佳之后才考慮的。這就好比在mysql當(dāng)中敦跌，有大量慢查詢導(dǎo)致cpu過高澄干，光靠擴展從庫而不去先優(yōu)化SQL，擴展到什么時候是個頭呢柠傍？
慢查詢問題：某個促銷活動的晚上麸俘，大數(shù)據(jù)報表果然又準(zhǔn)時出現(xiàn)打開慢的現(xiàn)象。redis依然是cpu占用率爆滿惧笛。話不多說進入redis 从媚，slowlog get 50 , 發(fā)現(xiàn)慢查詢中基本都是keys xxx* 這樣的查詢，這患整。拜效。。我?guī)缀蹩隙╟pu占用率跟這種慢查詢有很大關(guān)系了并级。執(zhí)行時間在0.5秒左右拂檩，0.5秒對于redis來說應(yīng)該是非常慢了。如果這樣的查詢比較多的話嘲碧，那么redis確實很可能出現(xiàn)阻塞稻励，在看了下value值的大小，應(yīng)該還好不算大。redis slowlog默認(rèn)只保存在內(nèi)存望抽，只保留當(dāng)前的128條加矛，所以這也算是個小小的麻煩，不太好統(tǒng)計慢查詢發(fā)生的頻率
持久化策略：
? ?? ?????rdb持久化：每次都是全量的bgsave煤篙，具體策略下面說斟览。
? ? ? ? ? ?????缺點： 1、非實時 ??
? ? ? ? ? ? ? ? ? ? ? ? ? 2辑奈、全量持久化 ??
3苛茂、每次保存RDB的時候，Redis都要fork()出一個子進程鸠窗，并由子進程來進行實際的持久化工作妓羊。 在數(shù)據(jù)集比較龐大時，fork()可能會非常耗時稍计，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端
? ? ? ? ? aof持久化：每秒寫aof文件躁绸，實時性較高，增量寫臣嚣，順序記錄語句净刮，便于誤操作恢復(fù)
? ? ? ? ? ? ? ?缺點：1、bgrewrite重寫硅则，fork進程淹父，短暫阻塞
? ? ? ? ? ? ? ? ? ? ? ? ?2、重寫時fork進程可能導(dǎo)致swap和OOM（預(yù)留1半內(nèi)存）
? ? ? ? ? 簡單介紹完兩種持久化策略之后抢埋，最后給出我實際優(yōu)化后的策略：
? 主/從業(yè)務(wù)庫關(guān)閉rdb和aof持久化弹灭，新增一臺從庫（不參與業(yè)務(wù)）單獨做rdb持久化，該從庫持久化配置：save 900 1 ?也就是900秒做一次bgrewrite揪垄，最多丟失15分鐘數(shù)據(jù)
連接數(shù)問題穷吮，這塊目前來說由于做了負(fù)載均衡，高峰期看haproxy入口的連接最大也就去到500-600饥努，還是有阻塞的情況下捡鱼，每個redis實例connected_clients最多也就到100左右，排除連接數(shù)的問題
結(jié)論：優(yōu)化主要避免了持久化酷愧，以及頻繁主從全量同步帶來的性能影響驾诈。但是實際主要瓶頸還是在慢查詢，如果keys xxx*這種查詢不能避免溶浴，那么一定會造成阻塞
下面這張圖應(yīng)該更加生動：
最后乍迄，還有幾個待解決的問題記錄下：
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
? ? ?解決方式：內(nèi)存碎片造成闯两，查看資料說是大量寫入造成褥伴，目前沒有太好的解決方法，只能通過重啟進程釋放
2漾狼、redis過期的key會不會自動刪除重慢？策略如何配置
redis過期的key當(dāng)內(nèi)存使用maxmemory才會進行刪除
maxmemory-policy 六種方式：
volatile-lru：（默認(rèn)值）從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
volatile-ttl ： 從已設(shè)置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰
allkeys-lru ： 從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰
allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰
noeviction ： 禁止驅(qū)逐數(shù)據(jù),永不過期，返回錯誤
3逊躁、redis主從同步原理（全量/增量）
? ?? ?????一張圖一目了然：
? ? ? ? ? 復(fù)制積壓緩沖區(qū)=repl-backlog
? ? ?redis2.8之前不支持增量備份
? ? ?增量備份的兩個條件
slave帶來的runid是否當(dāng)前master的runid
slave帶來的復(fù)制offset在master的backlog（復(fù)制積壓緩沖區(qū)）中還能否找到
