本文作為學習筆記翼悴，文章內(nèi)容來自“極客時間”專欄《Redis核心技術(shù)與實戰(zhàn)》，如有侵權(quán)幔妨，請告知抄瓦，必即時刪除。

1陶冷、內(nèi)存碎片的優(yōu)化

在使用 Redis 時，我們經(jīng)常會遇到這樣一個問題：明明做了數(shù)據(jù)刪除毯辅，數(shù)據(jù)量已經(jīng)不大了埂伦，為什么使用 top 命令查看時，還會發(fā)現(xiàn) Redis 占用了很多內(nèi)存呢思恐？實際上沾谜，這是因為，當數(shù)據(jù)刪除后胀莹，Redis 釋放的內(nèi)存空間會由內(nèi)存分配器管理基跑，并不會立即返回給操作系統(tǒng)。所以描焰，操作系統(tǒng)仍然會記錄著給 Redis 分配了大量內(nèi)存媳否。

但是，這往往會伴隨一個潛在的風險點：Redis 釋放的內(nèi)存空間可能并不是連續(xù)的荆秦，那么篱竭，這些不連續(xù)的內(nèi)存空間很有可能處于一種閑置的狀態(tài)。這就會導致一個問題：雖然有空閑空間步绸，Redis 卻無法用來保存數(shù)據(jù)掺逼，不僅會減少 Redis 能夠?qū)嶋H保存的數(shù)據(jù)量，還會降低 Redis 運行機器的成本回報率瓤介。

雖然操作系統(tǒng)的剩余內(nèi)存空間總量足夠吕喘，但是赘那，應(yīng)用申請的是一塊連續(xù)地址空間的 N 字節(jié)，但在剩余的內(nèi)存空間中氯质，沒有大小為 N 字節(jié)的連續(xù)空間了募舟，那么，這些剩余空間就是內(nèi)存碎片病梢。

1.1胃珍、內(nèi)存碎片的形成原因

1.1.1、內(nèi)因：內(nèi)存分配器的分配策略

內(nèi)存分配器一般是按固定大小來分配內(nèi)存蜓陌，而不是完全按照應(yīng)用程序申請的內(nèi)存空間大小給程序分配觅彰。Redis 可以使用 libc、jemalloc钮热、tcmalloc 多種內(nèi)存分配器來分配內(nèi)存填抬，默認使用 jemalloc。接下來隧期，我就以 jemalloc 為例飒责，來具體解釋一下。其他分配器也存在類似的問題仆潮。

jemalloc 的分配策略之一宏蛉，是按照一系列固定的大小劃分內(nèi)存空間，例如 8 字節(jié)性置、16 字節(jié)拾并、32 字節(jié)、48 字節(jié)鹏浅，…, 2KB嗅义、4KB、8KB 等隐砸。當程序申請的內(nèi)存最接近某個固定值時之碗，jemalloc 會給它分配相應(yīng)大小的空間。例如季希，Redis 申請一個 20 字節(jié)的空間保存數(shù)據(jù)褪那，jemalloc 就會分配 32 字節(jié)。

1.1.2式塌、外因：鍵值對大小不一樣和刪改操作

Redis 通常作為共用的緩存系統(tǒng)或鍵值數(shù)據(jù)庫對外提供服務(wù)武通，所以，不同業(yè)務(wù)應(yīng)用的數(shù)據(jù)都可能保存在 Redis 中珊搀，這就會帶來不同大小的鍵值對冶忱。這樣一來，Redis 申請內(nèi)存空間分配時境析，本身就會有大小不一的空間需求囚枪。這是第一個外因派诬。

第二個外因是，這些鍵值對會被修改和刪除链沼，這會導致空間的擴容和釋放默赂。具體來說，一方面括勺，如果修改后的鍵值對變大或變小了缆八，就需要占用額外的空間或者釋放不用的空間。另一方面疾捍，刪除的鍵值對就不再需要內(nèi)存空間了奈辰，此時，就會把空間釋放出來乱豆，形成空閑空間奖恰。

1.2、如何判斷是否由內(nèi)存碎片

Redis 自身提供了 INFO 命令宛裕，可以用來查詢內(nèi)存使用的詳細信息瑟啃，命令如下：

INFO memory
# Memory
used_memory:1073741736
used_memory_human:1024.00M
used_memory_rss:1997159792
used_memory_rss_human:1.86G
…
mem_fragmentation_ratio:1.86

這里有一個 mem_fragmentation_ratio 的指標，它表示的就是 Redis 當前的內(nèi)存碎片率揩尸。那么蛹屿，這個碎片率是怎么計算的呢？其實岩榆，就是上面的命令中的兩個指標 used_memory_rss 和 used_memory 相除的結(jié)果蜡峰。used_memory_rss是操作系統(tǒng)實際分配給 Redis 的物理內(nèi)存空間，里面就包含了碎片朗恳；而used_memory是 Redis 為了保存數(shù)據(jù)實際申請使用的空間。
那么载绿，知道了這個指標粥诫，我們該如何使用呢？在這兒崭庸，我提供一些經(jīng)驗閾值：

1. mem_fragmentation_ratio 大于 1 但小于 1.5怀浆。這種情況是合理的。這是因為怕享，剛才我介紹的那些因素是難以避免的执赡。畢竟，內(nèi)因的內(nèi)存分配器是一定要使用的函筋，分配策略都是通用的沙合，不會輕易修改；而外因由 Redis 負載決定跌帐，也無法限制首懈。所以勋功，存在內(nèi)存碎片也是正常的顷帖。
2. mem_fragmentation_ratio 大于 1.5。這表明內(nèi)存碎片率已經(jīng)超過了 50%。一般情況下嘲叔，這個時候，我們就需要采取一些措施來降低內(nèi)存碎片率了梦重。

1.3赏壹、清理內(nèi)存碎片

當 Redis 發(fā)生內(nèi)存碎片后，一個“簡單粗暴”的方法就是重啟 Redis 實例泥彤。當然欲芹，這并不是一個“優(yōu)雅”的方法。從 4.0-RC3 版本以后全景，Redis 自身提供了一種內(nèi)存碎片自動清理的方法耀石，我們先來看這個方法的基本機制。內(nèi)存碎片清理爸黄，簡單來說滞伟，就是“搬家讓位，合并空間”炕贵。

當有數(shù)據(jù)把一塊連續(xù)的內(nèi)存空間分割成好幾塊不連續(xù)的空間時梆奈，操作系統(tǒng)就會把數(shù)據(jù)拷貝到別處。此時称开，數(shù)據(jù)拷貝需要能把這些數(shù)據(jù)原來占用的空間都空出來亩钟，把原本不連續(xù)的內(nèi)存空間變成連續(xù)的空間。否則鳖轰，如果數(shù)據(jù)拷貝后清酥，并沒有形成連續(xù)的內(nèi)存空間，這就不能算是清理了蕴侣。

不過焰轻，需要注意的是：碎片清理是在Redis主線程中進行的，所以在碎片清理時昆雀，會阻塞主線程辱志，導致 Redis 無法及時處理請求，性能降低狞膘。

Redis 專門為自動內(nèi)存碎片清理功機制設(shè)置了參數(shù)揩懒，我們可以通過設(shè)置參數(shù)，來控制碎片清理的開始和結(jié)束時機挽封，以及占用的 CPU 比例已球，從而減少碎片清理對 Redis 本身請求處理的性能影響。
首先，Redis 需要啟用自動內(nèi)存碎片清理和悦，可以把 activedefrag 配置項設(shè)置為 yes退疫，命令如下：

config set activedefrag yes

具體什么時候清理，會受到下面這兩個參數(shù)的控制鸽素。這兩個參數(shù)分別設(shè)置了觸發(fā)內(nèi)存清理的一個條件褒繁，如果同時滿足這兩個條件，就開始清理馍忽。在清理的過程中棒坏，只要有一個條件不滿足了，就停止自動清理遭笋。

1. active-defrag-ignore-bytes 100mb：表示內(nèi)存碎片的字節(jié)數(shù)達到 100MB 時坝冕，開始清理；
2. active-defrag-threshold-lower 10：表示內(nèi)存碎片空間占操作系統(tǒng)分配給 Redis 的總空間比例達到 10% 時瓦呼，開始清理喂窟。

自動內(nèi)存碎片清理功能在執(zhí)行時，還會監(jiān)控清理操作占用的 CPU 時間央串，而且還設(shè)置了兩個參數(shù)磨澡，分別用于控制清理操作占用的 CPU 時間比例的上、下限质和，既保證清理工作能正常進行稳摄，又避免了降低 Redis 性能。這兩個參數(shù)具體如下：

1. active-defrag-cycle-min 25： 表示自動清理過程所用 CPU 時間的比例不低于 25%饲宿，保證清理能正常開展厦酬；
2. active-defrag-cycle-max 75：表示自動清理過程所用 CPU 時間的比例不高于 75%，一旦超過瘫想，就停止清理仗阅，從而避免在清理時，大量的內(nèi)存拷貝阻塞 Redis国夜，導致響應(yīng)延遲升高减噪。

2、緩沖區(qū)溢出優(yōu)化

緩沖區(qū)的功能其實很簡單支竹，主要就是用一塊內(nèi)存空間來暫時存放命令數(shù)據(jù)，以免出現(xiàn)因為數(shù)據(jù)和命令的處理速度慢于發(fā)送速度而導致的數(shù)據(jù)丟失和性能問題鸠按。但因為緩沖區(qū)的內(nèi)存空間有限礼搁，如果往里面寫入數(shù)據(jù)的速度持續(xù)地大于從里面讀取數(shù)據(jù)的速度，就會導致緩沖區(qū)需要越來越多的內(nèi)存來暫存數(shù)據(jù)目尖。當緩沖區(qū)占用的內(nèi)存超出了設(shè)定的上限閾值時馒吴，就會出現(xiàn)緩沖區(qū)溢出。

如果發(fā)生了溢出，就會丟數(shù)據(jù)了饮戳。那是不是不給緩沖區(qū)的大小設(shè)置上限豪治，就可以了呢？顯然不是扯罐，隨著累積的數(shù)據(jù)越來越多负拟，緩沖區(qū)占用內(nèi)存空間越來越大，一旦耗盡了 Redis 實例所在機器的可用內(nèi)存歹河，就會導致 Redis 實例崩潰掩浙。

2.1、客戶端輸入秸歧、輸出緩沖區(qū)

為了避免客戶端和服務(wù)器端的請求發(fā)送和處理速度不匹配厨姚，服務(wù)器端給每個連接的客戶端都設(shè)置了一個輸入緩沖區(qū)和輸出緩沖區(qū)，我們稱之為客戶端輸入緩沖區(qū)和輸出緩沖區(qū)键菱。輸入緩沖區(qū)會先把客戶端發(fā)送過來的命令暫存起來谬墙，Redis 主線程再從輸入緩沖區(qū)中讀取命令，進行處理经备。當 Redis 主線程處理完數(shù)據(jù)后拭抬，會把結(jié)果寫入到輸出緩沖區(qū)，再通過輸出緩沖區(qū)返回給客戶端弄喘，如下圖所示：

22.jpg

2.1.1玖喘、如何應(yīng)對輸入緩沖區(qū)溢出

輸入緩沖區(qū)就是用來暫存客戶端發(fā)送的請求命令的，所以可能導致溢出的情況主要是下面兩種：

1. 寫入了 bigkey蘑志，比如一下子寫入了多個百萬級別的集合類型數(shù)據(jù)累奈；
2. 服務(wù)器端處理請求的速度過慢，例如急但，Redis 主線程出現(xiàn)了間歇性阻塞澎媒，無法及時處理正常發(fā)送的請求，導致客戶端發(fā)送的請求在緩沖區(qū)越積越多波桩。

要查看和服務(wù)器端相連的每個客戶端對輸入緩沖區(qū)的使用情況戒努，我們可以使用 CLIENT LIST 命令：

CLIENT LIST
id=5 addr=127.0.0.1:50487 fd=9 name= age=4 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client

輸出結(jié)果中:

1. addr 會顯示不同客戶端的 IP 和端口號。
2. cmd镐躲，表示客戶端最新執(zhí)行的命令储玫。這個例子中執(zhí)行的是 CLIENT 命令。
3. qbuf萤皂，表示輸入緩沖區(qū)已經(jīng)使用的大小撒穷。這個例子中的 CLIENT 命令已使用了 26 字節(jié)大小的緩沖區(qū)。
4. qbuf-free裆熙，表示輸入緩沖區(qū)尚未使用的大小端礼。這個例子中的 CLIENT 命令還可以使用 32742 字節(jié)的緩沖區(qū)禽笑。qbuf 和 qbuf-free 的總和就是，Redis 服務(wù)器端當前為已連接的這個客戶端分配的緩沖區(qū)總大小蛤奥。這個例子中總共分配了 26 + 32742 = 32768 字節(jié)佳镜，也就是 32KB 的緩沖區(qū)。

有了 CLIENT LIST 命令凡桥，我們就可以通過輸出結(jié)果來判斷客戶端輸入緩沖區(qū)的內(nèi)存占用情況了蟀伸。如果 qbuf 很大，而同時 qbuf-free 很小唬血，就要引起注意了望蜡，因為這時候輸入緩沖區(qū)已經(jīng)占用了很多內(nèi)存，而且沒有什么空閑空間了拷恨。此時脖律，客戶端再寫入大量命令的話，就會引起客戶端輸入緩沖區(qū)溢出腕侄，Redis 的處理辦法就是把客戶端連接關(guān)閉小泉，結(jié)果就是業(yè)務(wù)程序無法進行數(shù)據(jù)存取了。

Redis 并沒有提供參數(shù)讓我們調(diào)節(jié)客戶端輸入緩沖區(qū)的大小冕杠。如果要避免輸入緩沖區(qū)溢出微姊，那我們就只能從數(shù)據(jù)命令的發(fā)送和處理速度入手，也就是前面提到的避免客戶端寫入 bigkey分预，以及避免 Redis 主線程阻塞兢交。

2.1.2、如何應(yīng)對輸出緩沖區(qū)溢出

Redis 的輸出緩沖區(qū)暫存的是 Redis 主線程要返回給客戶端的數(shù)據(jù)笼痹。一般來說配喳，主線程返回給客戶端的數(shù)據(jù)，既有簡單且大小固定的 OK 響應(yīng)（例如凳干，執(zhí)行 SET 命令）或報錯信息晴裹，也有大小不固定的、包含具體數(shù)據(jù)的執(zhí)行結(jié)果（例如救赐，執(zhí)行 HGET 命令）涧团。

因此，Redis 為每個客戶端設(shè)置的輸出緩沖區(qū)也包括兩部分：一部分经磅，是一個大小為 16KB 的固定緩沖空間泌绣，用來暫存 OK 響應(yīng)和出錯信息；另一部分预厌，是一個可以動態(tài)增加的緩沖空間阿迈，用來暫存大小可變的響應(yīng)結(jié)果。那什么情況下會發(fā)生輸出緩沖區(qū)溢出呢配乓？ 我為你總結(jié)了三種：

1. 服務(wù)器端返回 bigkey 的大量結(jié)果仿滔；
2. 執(zhí)行了 MONITOR 命令；
3. 緩沖區(qū)大小設(shè)置得不合理犹芹。

其中崎页，bigkey 原本就會占用大量的內(nèi)存空間，所以服務(wù)器端返回的結(jié)果包含 bigkey腰埂，必然會影響輸出緩沖區(qū)飒焦。MONITOR 命令是用來監(jiān)測 Redis 執(zhí)行的。執(zhí)行這個命令之后屿笼，就會持續(xù)輸出監(jiān)測到的各個命令操作牺荠，如下所示：

MONITOR
OK
1600617456.437129 [0 127.0.0.1:50487] "COMMAND"
1600617477.289667 [0 127.0.0.1:50487] "info" "memory"

MONITOR 的輸出結(jié)果會持續(xù)占用輸出緩沖區(qū)，并越占越多驴一，最后的結(jié)果就是發(fā)生溢出休雌。MONITOR 命令主要用在調(diào)試環(huán)境中，不要在線上生產(chǎn)環(huán)境中持續(xù)使用 MONITOR肝断。接下來杈曲，我們看下輸出緩沖區(qū)大小設(shè)置的問題。和輸入緩沖區(qū)不同胸懈，我們可以通過 client-output-buffer-limit 配置項担扑，來設(shè)置緩沖區(qū)的大小。具體設(shè)置的內(nèi)容包括兩方面：

1. 設(shè)置緩沖區(qū)大小的上限閾值趣钱；
2. 設(shè)置輸出緩沖區(qū)持續(xù)寫入數(shù)據(jù)的數(shù)量上限閾值涌献，和持續(xù)寫入數(shù)據(jù)的時間的上限閾值。

當我們給普通客戶端設(shè)置緩沖區(qū)大小時首有，通逞嗬可以在 Redis 配置文件中進行這樣的設(shè)置：

client-output-buffer-limit normal 0 0 0

其中，normal 表示當前設(shè)置的是普通客戶端绞灼，第 1 個 0 設(shè)置的是緩沖區(qū)大小限制利术，第 2 個 0 和第 3 個 0 分別表示緩沖區(qū)持續(xù)寫入量限制和持續(xù)寫入時間限制。

對于普通客戶端來說低矮，它每發(fā)送完一個請求印叁，會等到請求結(jié)果返回后，再發(fā)送下一個請求军掂，這種發(fā)送方式稱為阻塞式發(fā)送轮蜕。在這種情況下，如果不是讀取體量特別大的 bigkey蝗锥，服務(wù)器端的輸出緩沖區(qū)一般不會被阻塞的跃洛。所以，我們通常把普通客戶端的緩沖區(qū)大小限制终议，以及持續(xù)寫入量限制汇竭、持續(xù)寫入時間限制都設(shè)置為 0葱蝗，也就是不做限制。

對于訂閱客戶端來說细燎，一旦訂閱的 Redis 頻道有消息了两曼，服務(wù)器端都會通過輸出緩沖區(qū)把消息發(fā)給客戶端。所以玻驻，訂閱客戶端和服務(wù)器間的消息發(fā)送方式悼凑，不屬于阻塞式發(fā)送。不過璧瞬，如果頻道消息較多的話户辫，也會占用較多的輸出緩沖區(qū)空間。

client-output-buffer-limit pubsub 8mb 2mb 60

pubsub 參數(shù)表示當前是對訂閱客戶端進行設(shè)置嗤锉；8mb 表示輸出緩沖區(qū)的大小上限為 8MB渔欢，一旦實際占用的緩沖區(qū)大小要超過 8MB，服務(wù)器端就會直接關(guān)閉客戶端的連接瘟忱；2mb 和 60 表示膘茎，如果連續(xù) 60 秒內(nèi)對輸出緩沖區(qū)的寫入量超過 2MB 的話，服務(wù)器端也會關(guān)閉客戶端連接酷誓。

好了披坏，我們來總結(jié)下如何應(yīng)對輸出緩沖區(qū)溢出：

1. 避免 bigkey 操作返回大量數(shù)據(jù)結(jié)果；
2. 避免在線上環(huán)境中持續(xù)使用 MONITOR 命令盐数；
3. 使用 client-output-buffer-limit 設(shè)置合理的緩沖區(qū)大小上限棒拂，或是緩沖區(qū)連續(xù)寫入時間和寫入量上限。

2.2玫氢、主從集群中的緩沖區(qū)

2.2.1帚屉、復制緩沖區(qū)的溢出問題

在全量復制過程中，主節(jié)點在向從節(jié)點傳輸 RDB 文件的同時漾峡，會繼續(xù)接收客戶端發(fā)送的寫命令請求攻旦。這些寫命令就會先保存在復制緩沖區(qū)中，等 RDB 文件傳輸完成后生逸，再發(fā)送給從節(jié)點去執(zhí)行牢屋。主節(jié)點上會為每個從節(jié)點都維護一個復制緩沖區(qū)，來保證主從節(jié)點間的數(shù)據(jù)同步槽袄。

23.jpg

一方面，我們可以控制主節(jié)點保存的數(shù)據(jù)量大小催跪。按通常的使用經(jīng)驗锁蠕，我們會把主節(jié)點的數(shù)據(jù)量控制在 2~4GB，這樣可以讓全量同步執(zhí)行得更快些懊蒸，避免復制緩沖區(qū)累積過多命令荣倾。另一方面，我們可以使用 client-output-buffer-limit 配置項骑丸，來設(shè)置合理的復制緩沖區(qū)大小舌仍。設(shè)置的依據(jù)，就是主節(jié)點的數(shù)據(jù)量大小通危、主節(jié)點的寫負載壓力和主節(jié)點本身的內(nèi)存大小铸豁。

在主節(jié)點執(zhí)行如下命令：

config set client-output-buffer-limit slave 512mb 128mb 60

其中，slave 參數(shù)表明該配置項是針對復制緩沖區(qū)的菊碟。512mb 代表將緩沖區(qū)大小的上限設(shè)置為 512MB节芥；128mb 和 60 代表的設(shè)置是，如果連續(xù) 60 秒內(nèi)的寫入量超過 128MB 的話逆害，也會觸發(fā)緩沖區(qū)溢出头镊。在實際應(yīng)用中設(shè)置復制緩沖區(qū)的大小時，可以根據(jù)寫命令數(shù)據(jù)的大小和應(yīng)用的實際負載情況（也就是寫命令速率）魄幕，來粗略估計緩沖區(qū)中會累積的寫命令數(shù)據(jù)量相艇；然后，再和所設(shè)置的復制緩沖區(qū)大小進行比較纯陨，判斷設(shè)置的緩沖區(qū)大小是否足夠支撐累積的寫命令數(shù)據(jù)量坛芽。

為了避免復制緩沖區(qū)累積過多命令造成溢出，引發(fā)全量復制失敗翼抠，我們可以控制主節(jié)點保存的數(shù)據(jù)量大小靡馁，并設(shè)置合理的復制緩沖區(qū)大小。同時机久，我們需要控制從節(jié)點的數(shù)量臭墨，來避免主節(jié)點中復制緩沖區(qū)占用過多內(nèi)存的問題。

2.2.2膘盖、復制積壓緩沖區(qū)的溢出問題

主節(jié)點在把接收到的寫命令同步給從節(jié)點時胧弛，同時會把這些寫命令寫入復制積壓緩沖區(qū)尤误。一旦從節(jié)點發(fā)生網(wǎng)絡(luò)閃斷，再次和主節(jié)點恢復連接后结缚，從節(jié)點就會從復制積壓緩沖區(qū)中损晤，讀取斷連期間主節(jié)點接收到的寫命令，進而進行增量同步红竭，如下圖所示：

24.jpg

緩沖空間的計算公式是：緩沖空間大小 = 主庫寫入命令速度 * 操作大小 - 主從庫間網(wǎng)絡(luò)傳輸命令速度 * 操作大小。在實際應(yīng)用中赡若，考慮到可能存在一些突發(fā)的請求壓力达布，我們通常需要把這個緩沖空間擴大一倍，即 repl_backlog_size = 緩沖空間大小 * 2逾冬，這也就是 repl_backlog_size 的最終值往枣。

舉個例子，如果主庫每秒寫入 2000 個操作粉渠，每個操作的大小為 2KB分冈，網(wǎng)絡(luò)每秒能傳輸 1000 個操作，那么霸株，有 1000 個操作需要緩沖起來雕沉，這就至少需要 2MB 的緩沖空間。否則去件，新寫的命令就會覆蓋掉舊操作了坡椒。為了應(yīng)對可能的突發(fā)壓力，我們最終把 repl_backlog_size 設(shè)為 4MB尤溜。

不過倔叼，如果并發(fā)請求量非常大，連兩倍的緩沖空間都存不下新操作請求的話宫莱，此時丈攒，主從庫數(shù)據(jù)仍然可能不一致。可以考慮使用切片集群來分擔單個主庫的請求壓力巡验。