前情提要：
最近接了大數(shù)據(jù)項(xiàng)目的postgresql運(yùn)維，剛接過來(lái)他們的報(bào)表系統(tǒng)就出現(xiàn)高峰期訪問不了的問題，報(bào)表涉及實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)，離線讀pg，實(shí)時(shí)讀redis。然后自然而然就把redis也挪到我們這邊優(yōu)化了。在這次優(yōu)化過程中也是再次深刻感受到redis的各種坑
現(xiàn)象：
大數(shù)據(jù)報(bào)表周末晚上高峰期實(shí)時(shí)報(bào)表打不開，基本上處于不能使用狀態(tài)，實(shí)時(shí)報(bào)表主要訪問redis數(shù)據(jù)，監(jiān)控發(fā)現(xiàn)Redis?CPU占用過高，高峰期2個(gè)從庫(kù)實(shí)例的CPU達(dá)到100%，由于redis是單進(jìn)程單線程結(jié)構(gòu)，所以單核CPU達(dá)到100%導(dǎo)致查詢阻塞
當(dāng)前架構(gòu)：
1主1從 ，應(yīng)用手動(dòng)讀寫分離，持久化主從默認(rèn)都開啟開啟rdb持久化，沒有做aof，參數(shù)基本走默認(rèn)
問題導(dǎo)致原因排查：
redis持久化導(dǎo)致阻塞
是否存在慢查詢
主從存在頻繁全量同步）
value值是否過大
架構(gòu)問題，當(dāng)前所有業(yè)務(wù)讀取僅在一個(gè)從庫(kù)讀取
網(wǎng)絡(luò)問題
連接數(shù)問題
整理出一大堆問題之后，開始盲目分析：
首先看的網(wǎng)絡(luò)問題，跟運(yùn)維溝通過，結(jié)合監(jiān)控結(jié)果發(fā)現(xiàn)，網(wǎng)絡(luò)基本上沒有問題，網(wǎng)卡流量也遠(yuǎn)遠(yuǎn)沒有到瓶頸，首先排除網(wǎng)絡(luò)問題。但是，在redis從庫(kù)的日志中，發(fā)現(xiàn)有個(gè)報(bào)錯(cuò)很頻繁：
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.
? ? ? ?? 看字面意思就是主從連接斷開了，從庫(kù)嘗試做增量同步還不成功，最后做了全量同步。
? ? ? ?? WTF？？？既然網(wǎng)絡(luò)沒問題，為什么連接斷了。OK，引出主從問題
主從出現(xiàn)了頻繁全量同步，如上面的日志顯示，從庫(kù)連接斷開從連并嘗試增量同步失敗，結(jié)果做了全量同步。這個(gè)操作開銷很大：主庫(kù)bgsave->傳到從庫(kù)->從庫(kù)加載rbd到內(nèi)存（加載的時(shí)候是無(wú)法操作redis的）。出現(xiàn)這種情況又有幾個(gè)原因。。。
replication backlog（master端）：用于保存主從同步數(shù)據(jù)的一塊內(nèi)存緩沖區(qū)域（所有客戶端共享該內(nèi)存），達(dá)到限制將會(huì)重新進(jìn)行全量同步，這部分內(nèi)存會(huì)包含在used_memory_human中，設(shè)置值參考bgrewrite所需的內(nèi)存RDB: 500 MB of memory used by copy-on-write
通過增大repl-backlog-size解決
replication buffer(master端)：redis每個(gè)連接都分配了自己的緩沖區(qū)空間（從庫(kù)也相當(dāng)于是一個(gè)客戶端連接）。處理完請(qǐng)求后，redis把響應(yīng)數(shù)據(jù)放到緩沖區(qū)中，然后繼續(xù)下一個(gè)請(qǐng)求。repl-buffer存放的數(shù)據(jù)是下面3個(gè)時(shí)間內(nèi)所有master數(shù)據(jù)更新操作，設(shè)置值參考：每秒的命令產(chǎn)生大小*（以下3個(gè)時(shí)間之和）
master執(zhí)行rdb bgsave產(chǎn)生snapshot的時(shí)間
master發(fā)送rdb到slave網(wǎng)絡(luò)傳輸時(shí)間
slave load rdb to memory 的時(shí)間
? ? ?主要參數(shù)：
client-output-buffer-limit normal?
client-output-buffer-limit slave?
client-output-buffer-limit pubsub?
復(fù)制超時(shí)：
repl-timeout
? ? ? ? 最終參數(shù)優(yōu)化調(diào)整如下（主庫(kù)）：
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)問題，其實(shí)早在報(bào)表高峰期讀取問題出現(xiàn)的初期，大數(shù)據(jù)的同事就提出增加redis從庫(kù)實(shí)例，做負(fù)載均衡的想法了。鑒于redis是單線程模型，只能用到一個(gè)cpu核心，多增加幾個(gè)實(shí)例可以多利用到幾個(gè)cpu核心這個(gè)想法確實(shí)也沒錯(cuò)。當(dāng)時(shí)由于從庫(kù)物理機(jī)有富余的內(nèi)存資源，所以臨時(shí)新增了三個(gè)從庫(kù)實(shí)例，并添加haproxy輪詢?cè)L問后端4個(gè)redis實(shí)例。整體架構(gòu)變?yōu)?主4從+haproxy做從庫(kù)負(fù)載均衡。但是，cpu高主要還是跟具體的業(yè)務(wù)查詢有關(guān)，架構(gòu)擴(kuò)展應(yīng)該是在單實(shí)例優(yōu)化到最佳之后才考慮的。這就好比在mysql當(dāng)中，有大量慢查詢導(dǎo)致cpu過高，光靠擴(kuò)展從庫(kù)而不去先優(yōu)化SQL，擴(kuò)展到什么時(shí)候是個(gè)頭呢？
慢查詢問題：某個(gè)促銷活動(dòng)的晚上，大數(shù)據(jù)報(bào)表果然又準(zhǔn)時(shí)出現(xiàn)打開慢的現(xiàn)象。redis依然是cpu占用率爆滿。話不多說進(jìn)入redis ，slowlog get 50 , 發(fā)現(xiàn)慢查詢中基本都是keys xxx* 這樣的查詢，這。。。我?guī)缀蹩隙╟pu占用率跟這種慢查詢有很大關(guān)系了。執(zhí)行時(shí)間在0.5秒左右，0.5秒對(duì)于redis來(lái)說應(yīng)該是非常慢了。如果這樣的查詢比較多的話，那么redis確實(shí)很可能出現(xiàn)阻塞，在看了下value值的大小，應(yīng)該還好不算大。redis slowlog默認(rèn)只保存在內(nèi)存，只保留當(dāng)前的128條，所以這也算是個(gè)小小的麻煩，不太好統(tǒng)計(jì)慢查詢發(fā)生的頻率
持久化策略：
? ?? ?????rdb持久化：每次都是全量的bgsave，具體策略下面說。
? ? ? ? ? ?????缺點(diǎn)： 1、非實(shí)時(shí) ??
? ? ? ? ? ? ? ? ? ? ? ? ? 2、全量持久化 ??
3、每次保存RDB的時(shí)候，Redis都要fork()出一個(gè)子進(jìn)程，并由子進(jìn)程來(lái)進(jìn)行實(shí)際的持久化工作。 在數(shù)據(jù)集比較龐大時(shí)，fork()可能會(huì)非常耗時(shí)，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端
? ? ? ? ? aof持久化：每秒寫aof文件，實(shí)時(shí)性較高，增量寫，順序記錄語(yǔ)句，便于誤操作恢復(fù)
? ? ? ? ? ? ? ?缺點(diǎn)：1、bgrewrite重寫，fork進(jìn)程，短暫阻塞
? ? ? ? ? ? ? ? ? ? ? ? ?2、重寫時(shí)fork進(jìn)程可能導(dǎo)致swap和OOM（預(yù)留1半內(nèi)存）
? ? ? ? ? 簡(jiǎn)單介紹完兩種持久化策略之后，最后給出我實(shí)際優(yōu)化后的策略：
? 主/從業(yè)務(wù)庫(kù)關(guān)閉rdb和aof持久化，新增一臺(tái)從庫(kù)（不參與業(yè)務(wù)）單獨(dú)做rdb持久化，該從庫(kù)持久化配置：save 900 1 ?也就是900秒做一次bgrewrite，最多丟失15分鐘數(shù)據(jù)
連接數(shù)問題，這塊目前來(lái)說由于做了負(fù)載均衡，高峰期看haproxy入口的連接最大也就去到500-600，還是有阻塞的情況下，每個(gè)redis實(shí)例connected_clients最多也就到100左右，排除連接數(shù)的問題
結(jié)論：優(yōu)化主要避免了持久化，以及頻繁主從全量同步帶來(lái)的性能影響。但是實(shí)際主要瓶頸還是在慢查詢，如果keys xxx*這種查詢不能避免，那么一定會(huì)造成阻塞
下面這張圖應(yīng)該更加生動(dòng)：
最后，還有幾個(gè)待解決的問題記錄下：
1、主庫(kù)的used_memory_peak_human達(dá)到60.97G，實(shí)際上主庫(kù)的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)存碎片造成，查看資料說是大量寫入造成，目前沒有太好的解決方法，只能通過重啟進(jìn)程釋放
2、redis過期的key會(huì)不會(huì)自動(dòng)刪除？策略如何配置
redis過期的key當(dāng)內(nèi)存使用maxmemory才會(huì)進(jìn)行刪除
maxmemory-policy 六種方式：
volatile-lru：（默認(rèn)值）從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰
volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰
volatile-ttl ： 從已設(shè)置過期時(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ù),永不過期，返回錯(cuò)誤
3、redis主從同步原理（全量/增量）
? ?? ?????一張圖一目了然：
? ? ? ? ? 復(fù)制積壓緩沖區(qū)=repl-backlog
? ? ?redis2.8之前不支持增量備份
? ? ?增量備份的兩個(gè)條件
slave帶來(lái)的runid是否當(dāng)前master的runid
slave帶來(lái)的復(fù)制offset在master的backlog（復(fù)制積壓緩沖區(qū)）中還能否找到
