Redis錯(cuò)誤配置詳解

【編者按】筆者在運(yùn)行了上千個(gè)Redis數(shù)據(jù)庫(kù)實(shí)例后，不僅發(fā)現(xiàn)了使用Redis時(shí)遇到的一些令人頭疼的問(wèn)題，更是探索到了解決這些問(wèn)題的簡(jiǎn)單解決方案，其中包括復(fù)制緩沖區(qū)限制、復(fù)制超時(shí)和客戶(hù)端緩沖區(qū)等一系列容易遇到的難題。

免費(fèi)訂閱“CSDN大數(shù)據(jù)”微信公眾號(hào)，實(shí)時(shí)了解最新的大數(shù)據(jù)進(jìn)展！

CSDN大數(shù)據(jù)，專(zhuān)注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗(yàn)的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機(jī)器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點(diǎn)，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺(tái)，大數(shù)據(jù)實(shí)踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。

以下為譯文：

Redis提供了許多提高和維護(hù)高效內(nèi)存數(shù)據(jù)庫(kù)使用的工具。在無(wú)需額外配置應(yīng)用層的前提下，Redis獨(dú)特的數(shù)據(jù)類(lèi)型、指令和命令調(diào)優(yōu)就可以滿(mǎn)足應(yīng)用的需求，但是錯(cuò)誤的配置，更確切的說(shuō)那些機(jī)外設(shè)備可能導(dǎo)致操作麻煩和性能問(wèn)題。雖然導(dǎo)致了一些令人頭疼的問(wèn)題，但是解決方案是存在的，而且解決方案可能比我們預(yù)期的簡(jiǎn)單。

本系列文章介紹了使用Redis時(shí)遇到的一些令人頭疼的問(wèn)題，以及該解決這些問(wèn)題。這些內(nèi)容基于我們?cè)谶\(yùn)行上千個(gè)Redis數(shù)據(jù)庫(kù)實(shí)例時(shí)的真實(shí)經(jīng)歷。

復(fù)制緩沖區(qū)限制

復(fù)制緩沖區(qū)主從服務(wù)器同步數(shù)據(jù)時(shí)保存數(shù)據(jù)的內(nèi)存區(qū)域。在一個(gè)完整的主從同步中，初始化階段同步時(shí)，主服務(wù)器在復(fù)制緩沖區(qū)中保存數(shù)據(jù)的變化。初始化階段完成后，緩沖的內(nèi)容發(fā)送到從服務(wù)器。這個(gè)過(guò)程可能會(huì)遇到緩沖區(qū)的容量限制，達(dá)到最大容量時(shí)復(fù)制會(huì)重新開(kāi)始。為了避免這種情況，緩沖區(qū)需要依據(jù)復(fù)制過(guò)程中變化的類(lèi)型和數(shù)量進(jìn)行初始化配置。例如，一個(gè)小緩沖區(qū)可以存儲(chǔ)少量的變化數(shù)據(jù)，但當(dāng)變化比較多、比較大時(shí)，我們需要大緩沖區(qū)。一個(gè)更復(fù)雜的解決方案會(huì)更詳細(xì)的設(shè)置緩沖區(qū)，避免冗長(zhǎng)、大的復(fù)雜過(guò)程耗盡緩沖區(qū)（如果緩沖區(qū)太小）。最終，這個(gè)解決方案需要微調(diào)特定的數(shù)據(jù)庫(kù)。

當(dāng)256MB的硬限制到達(dá)時(shí)，或者軟限制到達(dá)且持續(xù)60秒時(shí)，默認(rèn)的復(fù)制鏈路會(huì)斷裂（導(dǎo)致同步從頭開(kāi)始）。許多情況下，特別是寫(xiě)負(fù)載高和從服務(wù)器帶寬不足的情況下，負(fù)載過(guò)程都無(wú)法結(jié)束。這可能導(dǎo)致無(wú)限循環(huán)，主Redis持續(xù)的將整個(gè)數(shù)據(jù)集復(fù)制到硬盤(pán)，這可以導(dǎo)致高速率的I/O操作，消耗高達(dá)三倍的額外內(nèi)存。此外，無(wú)限循環(huán)將導(dǎo)致從服務(wù)器無(wú)法趕上主服務(wù)器，無(wú)法與主服務(wù)器完全同步。

一個(gè)簡(jiǎn)單地解決方案是提高輸出從緩沖區(qū)，將軟硬限制都設(shè)置為512MB，這個(gè)解決方案可以很快的提高結(jié)果。

因?yàn)橛泻芏嘀匦屡渲?，所以?wù)必理解：

1.  在增加復(fù)制緩沖區(qū)尺寸前，我們必須確保機(jī)器上有足夠的內(nèi)存。

2.  Redis內(nèi)存使用計(jì)算不考慮復(fù)制緩沖區(qū)容量。

以上是本文介紹的第一個(gè)問(wèn)題。如我們上面談到的，盡管有復(fù)制緩沖區(qū)限制，合適的配置是可以良好運(yùn)行的。下面我們談?wù)勚鲝膹?fù)制的另一問(wèn)題。我們將深入討論完成該過(guò)程所需的時(shí)間和可能導(dǎo)致麻煩的一些配置問(wèn)題。

復(fù)制超時(shí)

如我們先前討論的，Redis的復(fù)制過(guò)程包括兩個(gè)同步階段：初始化階段和進(jìn)行階段。盡管進(jìn)行階段很穩(wěn)定（只要保持主從服務(wù)器間的鏈路即可），初始化階段不那么容易完成。成功的完成初始化同步不止依賴(lài)于復(fù)制緩沖區(qū)分配的內(nèi)存，還基于該步驟花費(fèi)的時(shí)間。

你可能想起來(lái)了，初始化同步步驟包括后臺(tái)保存以及整個(gè)數(shù)據(jù)主導(dǎo)從的傳播?；跀?shù)據(jù)庫(kù)容量和網(wǎng)絡(luò)連接質(zhì)量，這可能是一個(gè)很長(zhǎng)的過(guò)程。如果階段耗時(shí)太久，Redis可能會(huì)達(dá)到復(fù)制超時(shí)設(shè)置，這可能會(huì)導(dǎo)致初始階段重復(fù)進(jìn)行。這種情況下，你會(huì)發(fā)現(xiàn)從Redis日志文檔充斥著這些信息：

[28618] 21 Jul 00:33:36.031 * Connecting to MASTER 10.60.228.106:25994 
[28618] 21 Jul 00:33:36.032 * MASTER <-> SLAVE sync started 
[28618] 21 Jul 00:33:36.032 * Non blocking connect for SYNC fired the event. 
[28618] 21 Jul 00:33:36.032 * Master replied to PING, replication can continue... 
[28618] 21 Jul 00:33:36.032 * Partial resynchronization not possible (no cached master) 
[28618] 21 Jul 00:33:36.032 * Full resync from master: 549907b03661629665eb90846ea921f23de6c961:2537453 

Redis復(fù)制超時(shí)的默認(rèn)值是60秒（見(jiàn)redis.conf文件的repl-timeout指令，或使用redis-cli運(yùn)行“config get repl-timeout”）。這個(gè)時(shí)間可能很短，特別是當(dāng)你有：

• 低速存儲(chǔ)器：如果主服務(wù)器或從服務(wù)器是基于低速存儲(chǔ)器的，如果是主服務(wù)器將導(dǎo)致后臺(tái)進(jìn)程花費(fèi)很多時(shí)間；如果是服務(wù)器磁盤(pán)讀寫(xiě)數(shù)據(jù)時(shí)間將延長(zhǎng)。
• 大數(shù)據(jù)集：更大的數(shù)據(jù)集將需要更長(zhǎng)的存儲(chǔ)時(shí)間和傳輸時(shí)間。
• 網(wǎng)絡(luò)性能：當(dāng)主服務(wù)器和從服務(wù)器的網(wǎng)絡(luò)鏈路有限制帶寬和高延遲時(shí)，這會(huì)直接影響數(shù)據(jù)傳輸傳輸速率。

我們可以通過(guò)將復(fù)制超時(shí)設(shè)置為更合適的值來(lái)修正這個(gè)問(wèn)題。首先是一個(gè)可接受復(fù)制數(shù)據(jù)庫(kù)的的估計(jì)時(shí)間。第一步，檢查Redis通過(guò)BGSAVE指令和檢查相關(guān)行（如“Background saving started by pid nnn ”表示進(jìn)程開(kāi)始，“ Background saving terminated with success”表示進(jìn)程結(jié)束）的日志文檔執(zhí)行后臺(tái)進(jìn)程所花的時(shí)間。然后，測(cè)量CN將主服務(wù)器上的結(jié)果RDB文件拷貝到從服務(wù)器硬盤(pán)所需的時(shí)間。最后，測(cè)量從硬盤(pán)加載數(shù)據(jù)實(shí)際消耗的時(shí)間（如重啟Redis，在日志文件中尋找“DB loaded from disk”行）。這些方法可以大致估計(jì)復(fù)制超時(shí)值，保險(xiǎn)起見(jiàn)，我們可能需要在上面加上10~20%。

依據(jù)測(cè)量值設(shè)定了超時(shí)后，我們可以通過(guò)讓從服務(wù)器執(zhí)行幾次完整的同步和檢查日志文件來(lái)測(cè)量復(fù)制的實(shí)際耗時(shí)。如果可能的話，在日常不同的時(shí)刻重復(fù)這個(gè)操作，確保在不同的負(fù)載下系統(tǒng)的表現(xiàn)良好。最后，切記隨著數(shù)據(jù)庫(kù)的增長(zhǎng)，我們需要定時(shí)檢查超時(shí)設(shè)置值。

以上描述的是Redis復(fù)制問(wèn)題。復(fù)制是保持?jǐn)?shù)據(jù)庫(kù)可用、擴(kuò)展數(shù)據(jù)庫(kù)可讀性的有力工具，不過(guò)注意復(fù)制的默認(rèn)設(shè)置，確保依照實(shí)際使用情況配置數(shù)據(jù)庫(kù)。下面我們談?wù)効蛻?hù)端緩沖區(qū)。在有些情況下，客戶(hù)端緩沖區(qū)會(huì)帶來(lái)很多問(wèn)題。

客戶(hù)端緩沖區(qū)

你大概已經(jīng)知道Redis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，這意味著所有的數(shù)據(jù)都由RAM直接管理和提供的。因此Redis有著卓越的交付性能，Redis可以以亞毫秒級(jí)的延遲處理幾萬(wàn)、幾十萬(wàn)的請(qǐng)求。RAM是當(dāng)下最快的存儲(chǔ)技術(shù)――為了更好的理解延遲數(shù)字，請(qǐng)看以下數(shù)據(jù)：

Latency Comparison Numbers
--------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns
Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms
Read 4K randomly from SSD* 150,000 ns 0.15 ms
Read 1 MB sequentially from memory 250,000 ns 0.25 ms
Round trip within same datacenter 500,000 ns 0.5 ms
Read 1 MB sequentially from SSD* 1,000,000 ns 1 ms 4X memory
Disk seek 10,000,000 ns 10 ms 20x datacenter roundtrip
Read 1 MB sequentially from disk 20,000,000 ns 20 ms 80x memory, 20X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150 ms
 
Notes
-----
1 ns = 10-9 seconds
1 ms = 10-3 seconds
* Assuming ~1GB/sec SSD
 
Credit
------
By Jeff Dean: http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers
 
Contributions
-------------
Some updates from: https://gist.github.com/2843375
Great 'humanized' comparison version:https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Nice animated presentation of the data: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/
- See more at:http://redislabs.com/blog/top-redis-headaches-for-devops-client-buffers#sthash.9rHluMPF.dpuf

Redis，如同它的名字和設(shè)計(jì)，是一個(gè)移動(dòng)服務(wù)器，客戶(hù)端（通常）通過(guò)網(wǎng)絡(luò)連接Redis。這種情況下，客戶(hù)端請(qǐng)求返回客戶(hù)端的時(shí)間將顯著長(zhǎng)于Redis CPU從RAM讀取數(shù)據(jù)的時(shí)間。這意味著如果沒(méi)有客戶(hù)端緩沖區(qū)的話，Redis的主要差異與在該段時(shí)間對(duì)服務(wù)的響應(yīng)有關(guān)。

客戶(hù)端緩沖區(qū)組成了服務(wù)客戶(hù)請(qǐng)求所需的內(nèi)存空間，Redis的每個(gè)連接都配有自己的緩沖區(qū)空間。處理請(qǐng)求后，Redis把響應(yīng)數(shù)據(jù)復(fù)制到客戶(hù)端緩沖區(qū)，然后繼續(xù)處理下一個(gè)請(qǐng)求，與此同時(shí)，請(qǐng)求客戶(hù)端通過(guò)網(wǎng)絡(luò)連接讀取數(shù)據(jù)。Redis客戶(hù)端緩沖區(qū)配置在redis.conf文件，通過(guò)client-output-buffer-limit normal指令配置（你可以在運(yùn)行時(shí)通過(guò)config get client-output-buffer-limit指令獲取設(shè)置）。默認(rèn)的redis.conf文件定義如下：

client-output-buffer-limit normal 0 0 0

這些數(shù)值分別代表緩沖區(qū)軟限制，硬限制和以秒為單位的超時(shí)（類(lèi)似于復(fù)制緩沖區(qū)）。當(dāng)Redis終止連接時(shí)，這些值提供保護(hù)――不需要客戶(hù)讀取回復(fù)――當(dāng)緩沖區(qū)尺寸達(dá)到a）軟限制并且保持狀態(tài)直到超時(shí)b）硬限制。將這些數(shù)值都設(shè)為0意味著關(guān)閉保護(hù)。

不過(guò)，和復(fù)制緩沖區(qū)不同的是客戶(hù)端緩沖區(qū)來(lái)自Redis數(shù)據(jù)內(nèi)存空間?？梢酝ㄟ^(guò)maxmemory指令設(shè)置Redis的總內(nèi)存值，達(dá)到極限后，Redis將應(yīng)用其配置的驅(qū)逐策略（由maxmemory-policy 指令定義）。因此，低性能的客戶(hù)或大量的同時(shí)連接可能會(huì)因?yàn)閿?shù)據(jù)集尺寸和客戶(hù)端緩沖區(qū)達(dá)到內(nèi)存限制導(dǎo)致Redis實(shí)例過(guò)早的驅(qū)逐鍵或禁止更新。

由于生命周期的相對(duì)性，一個(gè)客戶(hù)端不需要降低性能就可能導(dǎo)致這種現(xiàn)象。因?yàn)镽AM讀取和網(wǎng)絡(luò)讀取存在著很大的速度差異，過(guò)多的客戶(hù)端緩沖區(qū)很可能耗盡Redis內(nèi)存，即使是在高性能的客戶(hù)端和網(wǎng)絡(luò)連接中。例如，考慮下（萬(wàn)惡的）KEYS指令，這個(gè)指令觸發(fā)后，Redis將會(huì)把整個(gè)鍵的名空間拷貝給客戶(hù)端緩沖區(qū)。如果我們的數(shù)據(jù)庫(kù)有很多鍵，這很可能導(dǎo)致驅(qū)逐。

警告：使用KEYS時(shí)務(wù)必要謹(jǐn)慎，不要在生產(chǎn)環(huán)境下使用KEYS。使用KEYS除了可能導(dǎo)致上文提到的驅(qū)逐外，還可能會(huì)在很長(zhǎng)時(shí)間內(nèi)封鎖Redis。

KEYS不是唯一一個(gè)可能導(dǎo)致這種情況的指令。類(lèi)似的指令還有SMEMBERS，HGETALL，LRANGE和ZRANGE（以及與這些指令相關(guān)的指令），當(dāng)值（或范圍）足夠大，或者當(dāng)有很多公開(kāi)連接（每個(gè)連接都需要單獨(dú)的緩沖區(qū)）時(shí)，這些指令可能導(dǎo)致類(lèi)似的現(xiàn)象。

我們強(qiáng)烈推薦謹(jǐn)慎負(fù)責(zé)的使用這些指令。我們推薦大家使用SCAN家族指令替代這些指令，v2.8版本加入了SCAN指令。SCAN指令不僅允許Redis在后續(xù)的SCAN調(diào)用間繼續(xù)處理請(qǐng)求，還降低了耗盡客戶(hù)端緩沖區(qū)的概率。

客戶(hù)端緩沖區(qū)是Redis內(nèi)存需求和管理常常會(huì)忽略的方面。客戶(hù)端緩沖區(qū)的默認(rèn)設(shè)置有風(fēng)險(xiǎn)，很可能導(dǎo)致內(nèi)存耗盡。我們要有依據(jù)的設(shè)置緩沖區(qū)閾值―考慮“maxmemory”設(shè)置，當(dāng)下和預(yù)測(cè)內(nèi)存使用，應(yīng)用流量模式。謹(jǐn)慎的使用先前提到的指令可以避免那些令人頭疼的問(wèn)題。歡迎關(guān)注我們后續(xù)的文章。

原文鏈接：

Top Redis Headaches for Devops

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)