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

接下來我們就來對redis來進行一系列的測試，利用redis自帶的redis-benchmark，分別對set和get命令；單個傳送和批量傳送；直連redis和連線redis代理

八個測試命令

以上8條命令採取redis-benchmark預設的50個併發連線，資料大小為2位元組，指定3000個key，批量測試時一次傳送20個請求。依次間隔2分鐘執行以上命令，每一個測試完成時間大約4分鐘。最後得到下圖的總體結果：

眼花繚亂是不是？左邊的縱軸表示CPU使用率，右邊的縱軸表示吞吐。其中redis used表示redis總的CPU使用率，redis user表示redis CPU使用者態使用率，redis sys表示redis CPU核心態使用率，其它類推。先別擔心分不清裡面的內容，下面我們會一一標出數值來。在這圖中總共可以看出有八個凸起，依次對應我們上面提到的八個測試命令。

1 redis set測試

2 predixy set測試

3 redis get測試

4 predixy get測試

5 redis 批量set測試

6 predixy 批量set測試

7 redis 批量get測試

8 predixy 批量get測試

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

看到前四個的結果如果感到驚訝不用懷疑是自己看錯了或者是測試結果有問題，這個結果是無誤的。根據這個結果，那麼可以回答我們最初提出的疑問，增加了代理之後並不一定會降低服務整體的吞吐！雖然benchmark並不是我們的實際應用，但是redis的大部分應用場景都是這樣的，併發的接受眾多客戶端的請求，處理然後返回。

為什麼會是這樣的結果，看到這個結果後我們肯定想知道原因，這好像跟我們的想象不太一樣。要分析這個問題，我們還是從測試的資料來入手，首先看測試1的資料，redis的CPU使用率幾乎已經達到了1，對於單執行緒程式來說，這意味著CPU已經跑滿了，效能已經達到了極限，不可能再提高了，然而這時redis的吞吐卻只有167000。測試2的redis吞吐都比它高，並且我們明顯能看出測試2裡redis的CPU使用率還不如測試1的高，測試2裡redis CPU使用率只有0.475。為什麼CPU使用率降低了吞吐反而卻還高了呢？仔細對比一下兩個測試的資料，可以發現在測試1裡，redis的CPU大部分都花在了核心態，高達0.744，而使用者態只有0.247，CPU執行在核心態時雖然我們不能稱之為瞎忙活，但是卻無助於提升程式的效能，只有CPU執行在使用者態才可能提升我們的程式效能，相比測試1，測試2的redis使用者態CPU使用率提高到了0.313，而核心態CPU則大幅下降至0.162。這也就解釋了為什麼測試2的吞吐比測試1還要高。當然了，我們還是要繼續刨根問底，為什麼測試2裡經過一層代理predixy後，redis的CPU使用情況發生變化了呢？這是因為redis接受一個連線批量的傳送命令過來處理，也就是redis裡所謂的pipeline。而predixy正是利用這一特性，predixy與redis之間只有一個連線（大多數情況下），predixy在收到客戶端的請求後，會將它們批量的通過這個連線傳送給redis處理，這樣一來就大大降低了redis用於網路IO操作的開銷，而這一部分開銷基本都是花費在核心態。

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

測試3和測試4說明的問題與測試1和測試2一樣，如果我只做了這四個測試，那麼看起來好像代理的引入完全有助於提升我們的吞吐嘛。正如上面所分析的那樣，predixy提升吞吐的原因是因為採用了批量傳送手段。那麼如果客戶端的使用場景就是批量傳送命令，那結果會如何呢？

於是有了後面四個測試，後面四個測試給我們的直接感受就是太震撼了，吞吐直接提升幾倍甚至10倍！其實也正是因為redis批量模式下效能非常強悍，才使得predixy在單命令情況下改進吞吐成為可能。當然到了批量模式，從測試結果看，predixy使得服務的吞吐下降了。

具體到批量set時，直連redis和通過predixy，redis的CPU使用率都滿了，雖然採用predixy使得redis的使用者態CPU從0.796提高到了0.940，但是吞吐卻不升反降，從782000到724000，大約下降了7.4%。至於為什麼使用者態CPU利用率提高了吞吐卻下降了，要想知道原因就需要分析redis本身的實現，這裡我們就不做詳細探討。可以做一個粗糙的解釋，在redis CPU跑滿的情況下，不同的負載情況會使得使用者態和核心態的使用率不同，而這其中有一種分配情況會是吞吐最大，而使用者態使用率高於或者低於這種情況時都會出現吞吐下降的情況。

再來看批量get，直連redis時吞吐高達1708000，而通過predixy的話就只有935000了，下降了45%！就跟納了個人所得稅上限一般。看到這，剛剛對predixy建立的美好形象是不是又突然覺得要坍塌了？先別急，再看看其它指標，直連redis時，redis CPU跑滿；而通過predixy時redis CPU只用了0.596，也就是說redis還有四成的CPU等待我們去壓榨。

寫到這，既然上面提到批量get時，通過predixy的話redis並未發揮出全部功力，於是就想著如果全部發揮出來會是什麼情況呢？我們繼續增加兩個測試，既然單個predixy在批量的情況下造成了吞吐下降，但是給我們帶來了一個好處是redis還可以提升的餘地，那麼我們就增加predixy的處理能力。因此我們把predixy改為三執行緒，再來跑一遍測試6和測試8。
兩個測試的整體結果如下。

三執行緒predixy批量set

三執行緒predixy批量get

原本在單執行緒predixy的批量set測試中，predixy和redis的CPU都已經跑滿了，我們覺得吞吐已經達到了極限，但是實際結果顯示在三執行緒predixy的批量set測試中，吞吐還是提高了，從原來的724000到現在的76200，與直連的782000只有2.5%的差距。多執行緒和單執行緒的主要差別在於單執行緒時predixy與redis只有一個連線，而三執行緒時有三個連線。

而對於三執行緒predixy的批量get測試，不出我們所料的吞吐得到了極大的提升，從之前的935000直接飆到1718000，已經超過了直連的1708000。

最後，我們來總結一下，我們整個測試的場景比較簡單，只是單純的set、get測試，並且資料大小為預設的2位元組，實際的redis應用場景遠比這複雜的多。但是測試結果的資料依舊可以給我們一些結論。代理的引入並不一定會降低服務的吞吐，實際上根據服務的負載情況，有時候引入代理反而可以提升整個服務的吞吐，如果我們不計較代理本身所消耗的資源，那麼引入代理幾乎總是一個好的選擇。根據我們上面的分析，一個最簡單實用的判斷原則，看看你的redis CPU使用情況，如果花費了太多時間在核心態，那麼考慮引入代理吧。