引入redis代理是否一定會降低redis服務(wù)性能？ - 全文

從我們的直觀感受來講，對于任何服務(wù)，只要在中間增加了一層，肯定會對服務(wù)性能造成影響。那么到底會影響什么呢？在考察一個(gè)服務(wù)性能的時(shí)候，有兩個(gè)最重要的指標(biāo)，那就是吞吐和延遲。吞吐定義為服務(wù)端單位時(shí)間內(nèi)能處理的請求數(shù)，延遲定義為客戶端從發(fā)出請求到收到請求的耗時(shí)。中間環(huán)節(jié)的引入我們首先想到的就是那會增加處理時(shí)間，這就會增加服務(wù)的延遲，于是順便我們也會認(rèn)為吞吐也會下降。從單個(gè)用戶的角度來講，事實(shí)確實(shí)如此，我完成一個(gè)請求的時(shí)間增加了，那么我單位時(shí)間內(nèi)所能完成的請求量必定就減少了。然而站在服務(wù)端的角度來看，雖然單個(gè)請求的處理時(shí)間增加了，但是總的吞吐就一定會減少嗎？

接下來我們就來對redis來進(jìn)行一系列的測試，利用redis自帶的redis-benchmark，分別對set和get命令；單個(gè)發(fā)送和批量發(fā)送；直連redis和連接redis代理predixy。這樣組合起來總共就是八種情況。redis-benchmark、redis是單線程的，predixy支持多線程，但是我們也只運(yùn)行一個(gè)線程，這三個(gè)程序都運(yùn)行在一臺機(jī)器上。

項(xiàng)目 內(nèi)容
CPU?AMD Ryzen 7 1700X Eight-Core Processor 3.775GHz?
內(nèi)存?16GB DDR4 3000?
OS?x86_64 GNU/Linux 4.10.0-42-generic #46~16.04.1-Ubuntu?
redis?版本3.2.9，端口7200?
predixy?版本1.0.2，端口7600?

八個(gè)測試命令

測試命令 命令行
redis set?redis-benchmark -h xxx -p 7200 -t set -r 3000 -n 40000000?
predixy set?redis-benchmark -h xxx -p 7600 -t set -r 3000 -n 40000000?
redis get?redis-benchmark -h xxx -p 7200 -t get -r 3000 -n 40000000?
predixy get?redis-benchmark -h xxx -p 7600 -t get -r 3000 -n 40000000?
redis 批量set?redis-benchmark -h xxx -p 7200 -t set -r 3000 -n 180000000 -P 20?
predixy 批量set?redis-benchmark -h xxx -p 7600 -t set -r 3000 -n 180000000 -P 20?
redis 批量get?redis-benchmark -h xxx -p 7200 -t get -r 3000 -n 420000000 -P 20?
predixy 批量get?redis-benchmark -h xxx -p 7600 -t get -r 3000 -n 220000000 -P 20?

以上8條命令采取redis-benchmark默認(rèn)的50個(gè)并發(fā)連接，數(shù)據(jù)大小為2字節(jié)，指定3000個(gè)key，批量測試時(shí)一次發(fā)送20個(gè)請求。依次間隔2分鐘執(zhí)行以上命令，每一個(gè)測試完成時(shí)間大約4分鐘。最后得到下圖的總體結(jié)果：

眼花繚亂是不是？左邊的縱軸表示CPU使用率，右邊的縱軸表示吞吐。其中redis used表示redis總的CPU使用率，redis user表示redis CPU用戶態(tài)使用率，redis sys表示redis CPU內(nèi)核態(tài)使用率，其它類推。先別擔(dān)心分不清里面的內(nèi)容，下面我們會一一標(biāo)出數(shù)值來。在這圖中總共可以看出有八個(gè)凸起，依次對應(yīng)我們上面提到的八個(gè)測試命令。

1 redis set測試

2 predixy set測試

3 redis get測試

4 predixy get測試

5 redis 批量set測試

6 predixy 批量set測試

7 redis 批量get測試

8 predixy 批量get測試

圖片還是不方便看，我們總結(jié)為表格：

測試指標(biāo) redis used redis user redis sys predixy used predixy user predixy sys redis qps predixy qps
redis set?0.990?0.247?0.744?0?0?0?167000?3?
predixy set?0.475?0.313?0.162?0.986?0.252?0.734?174000?174000?
redis get?0.922?0.180?0.742?0?0?0?163000?3?
predixy get?0.298?0.195?0.104?0.988?0.247?0.741?172000?172000?
redis批量set?1.006?0.796?0.21?0?0?0?782000?3?
predixy批量set?0.998?0.940?0.058?0.796?0.539?0.256?724000?724000?
redis批量get?1?0.688?0.312?0?0?0?1708000?3?
predixy批量get?0.596?0.582?0.014?0.999?0.637?0.362?935000?935000?

看到前四個(gè)的結(jié)果如果感到驚訝不用懷疑是自己看錯(cuò)了或者是測試結(jié)果有問題，這個(gè)結(jié)果是無誤的。根據(jù)這個(gè)結(jié)果，那么可以回答我們最初提出的疑問，增加了代理之后并不一定會降低服務(wù)整體的吞吐！雖然benchmark并不是我們的實(shí)際應(yīng)用，但是redis的大部分應(yīng)用場景都是這樣的，并發(fā)的接受眾多客戶端的請求，處理然后返回。

為什么會是這樣的結(jié)果，看到這個(gè)結(jié)果后我們肯定想知道原因，這好像跟我們的想象不太一樣。要分析這個(gè)問題，我們還是從測試的數(shù)據(jù)來入手，首先看測試1的數(shù)據(jù)，redis的CPU使用率幾乎已經(jīng)達(dá)到了1，對于單線程程序來說，這意味著CPU已經(jīng)跑滿了，性能已經(jīng)達(dá)到了極限，不可能再提高了，然而這時(shí)redis的吞吐卻只有167000。測試2的redis吞吐都比它高，并且我們明顯能看出測試2里redis的CPU使用率還不如測試1的高，測試2里redis CPU使用率只有0.475。為什么CPU使用率降低了吞吐反而卻還高了呢？仔細(xì)對比一下兩個(gè)測試的數(shù)據(jù)，可以發(fā)現(xiàn)在測試1里，redis的CPU大部分都花在了內(nèi)核態(tài)，高達(dá)0.744，而用戶態(tài)只有0.247，CPU運(yùn)行在內(nèi)核態(tài)時(shí)雖然我們不能稱之為瞎忙活，但是卻無助于提升程序的性能，只有CPU運(yùn)行在用戶態(tài)才可能提升我們的程序性能，相比測試1，測試2的redis用戶態(tài)CPU使用率提高到了0.313，而內(nèi)核態(tài)CPU則大幅下降至0.162。這也就解釋了為什么測試2的吞吐比測試1還要高。當(dāng)然了，我們還是要繼續(xù)刨根問底，為什么測試2里經(jīng)過一層代理predixy后，redis的CPU使用情況發(fā)生變化了呢？這是因?yàn)閞edis接受一個(gè)連接批量的發(fā)送命令過來處理，也就是redis里所謂的pipeline。而predixy正是利用這一特性，predixy與redis之間只有一個(gè)連接（大多數(shù)情況下），predixy在收到客戶端的請求后，會將它們批量的通過這個(gè)連接發(fā)送給redis處理，這樣一來就大大降低了redis用于網(wǎng)絡(luò)IO操作的開銷，而這一部分開銷基本都是花費(fèi)在內(nèi)核態(tài)。

對比測試1和測試2，引入predixy不僅直接提高了吞吐，還帶來一個(gè)好處，就是redis的CPU使用率只有一半不到了，這也就意味著如果我再把剩下的這一半CPU用起來還可以得到更高的吞吐，而如果沒有predixy這樣一層的話，測試1結(jié)果告訴我們r(jià)edis的CPU利用率已經(jīng)到頭了，吞吐已經(jīng)不可能再提高。

測試3和測試4說明的問題與測試1和測試2一樣，如果我只做了這四個(gè)測試，那么看起來好像代理的引入完全有助于提升我們的吞吐嘛。正如上面所分析的那樣，predixy提升吞吐的原因是因?yàn)椴捎昧伺堪l(fā)送手段。那么如果客戶端的使用場景就是批量發(fā)送命令，那結(jié)果會如何呢？

于是有了后面四個(gè)測試，后面四個(gè)測試給我們的直接感受就是太震撼了，吞吐直接提升幾倍甚至10倍！其實(shí)也正是因?yàn)閞edis批量模式下性能非常強(qiáng)悍，才使得predixy在單命令情況下改進(jìn)吞吐成為可能。當(dāng)然到了批量模式，從測試結(jié)果看，predixy使得服務(wù)的吞吐下降了。

具體到批量set時(shí)，直連redis和通過predixy，redis的CPU使用率都滿了，雖然采用predixy使得redis的用戶態(tài)CPU從0.796提高到了0.940，但是吞吐卻不升反降，從782000到724000，大約下降了7.4%。至于為什么用戶態(tài)CPU利用率提高了吞吐卻下降了，要想知道原因就需要分析redis本身的實(shí)現(xiàn)，這里我們就不做詳細(xì)探討?？梢宰鲆粋€(gè)粗糙的解釋，在redis CPU跑滿的情況下，不同的負(fù)載情況會使得用戶態(tài)和內(nèi)核態(tài)的使用率不同，而這其中有一種分配情況會是吞吐最大，而用戶態(tài)使用率高于或者低于這種情況時(shí)都會出現(xiàn)吞吐下降的情況。

再來看批量get，直連redis時(shí)吞吐高達(dá)1708000，而通過predixy的話就只有935000了，下降了45%！就跟納了個(gè)人所得稅上限一般。看到這，剛剛對predixy建立的美好形象是不是又突然覺得要坍塌了？先別急，再看看其它指標(biāo)，直連redis時(shí)，redis CPU跑滿；而通過predixy時(shí)redis CPU只用了0.596，也就是說redis還有四成的CPU等待我們?nèi)赫ァ?/p>

寫到這，既然上面提到批量get時(shí)，通過predixy的話redis并未發(fā)揮出全部功力，于是就想著如果全部發(fā)揮出來會是什么情況呢？我們繼續(xù)增加兩個(gè)測試，既然單個(gè)predixy在批量的情況下造成了吞吐下降，但是給我們帶來了一個(gè)好處是redis還可以提升的余地，那么我們就增加predixy的處理能力。因此我們把predixy改為三線程，再來跑一遍測試6和測試8。
兩個(gè)測試的整體結(jié)果如下。

三線程predixy批量set

三線程predixy批量get

測試指標(biāo) redis used redis user redis sys predixy used predixy user predixy sys redis qps predixy qps
predixy pipeline set?1.01?0.93?0.07?1.37?0.97?0.41?762000?762000?
predixy pipeline get?0.93?0.85?0.08?2.57?1.85?0.72?1718000?1718000?

原本在單線程predixy的批量set測試中，predixy和redis的CPU都已經(jīng)跑滿了，我們覺得吞吐已經(jīng)達(dá)到了極限，但是實(shí)際結(jié)果顯示在三線程predixy的批量set測試中，吞吐還是提高了，從原來的724000到現(xiàn)在的76200，與直連的782000只有2.5%的差距。多線程和單線程的主要差別在于單線程時(shí)predixy與redis只有一個(gè)連接，而三線程時(shí)有三個(gè)連接。

而對于三線程predixy的批量get測試，不出我們所料的吞吐得到了極大的提升，從之前的935000直接飆到1718000，已經(jīng)超過了直連的1708000。

最后，我們來總結(jié)一下，我們整個(gè)測試的場景比較簡單，只是單純的set、get測試，并且數(shù)據(jù)大小為默認(rèn)的2字節(jié)，實(shí)際的redis應(yīng)用場景遠(yuǎn)比這復(fù)雜的多。但是測試結(jié)果的數(shù)據(jù)依舊可以給我們一些結(jié)論。代理的引入并不一定會降低服務(wù)的吞吐，實(shí)際上根據(jù)服務(wù)的負(fù)載情況，有時(shí)候引入代理反而可以提升整個(gè)服務(wù)的吞吐，如果我們不計(jì)較代理本身所消耗的資源，那么引入代理幾乎總是一個(gè)好的選擇。根據(jù)我們上面的分析，一個(gè)最簡單實(shí)用的判斷原則，看看你的redis CPU使用情況，如果花費(fèi)了太多時(shí)間在內(nèi)核態(tài)，那么考慮引入代理吧。