2011 年，當(dāng)初選擇 Redis 作為主要的內(nèi)存數(shù)據(jù)存儲，主要吸引我的是它提供多樣的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)可以很方便的實現(xiàn)業(yè)務(wù)需求佩脊。另一方面又比較擔(dān)心它的性能是否足以支撐，畢竟當(dāng)時 Redis 還屬于比較新的開源產(chǎn)品垫卤。但 Redis 官網(wǎng)宣稱其是提供多數(shù)據(jù)結(jié)構(gòu)的高性能存儲威彰，我們對其還是抱有幻想的。

幻想

要了解 Redis 的性能穴肘，我們先看看官方的基準(zhǔn)性能測試數(shù)據(jù)抱冷，心里有個底。

測試前提
Redis version 2.4.2
Using the TCP loopback
Payload size = 256 bytes  
測試結(jié)果
SET: 198412.69/s
GET: 198019.80/s

這個數(shù)據(jù)剛一看覺得有點超出預(yù)期了梢褐，不過看了測試前提是規(guī)避了網(wǎng)絡(luò)開銷的，Client 和 Server 全在本機(jī)赵讯。而真實的使用場景肯定是需要走網(wǎng)絡(luò)的盈咳，而且使用的客戶端庫也是不同的。不過這個官方參考數(shù)據(jù)當(dāng)時讓我們對 Redis 的性能還是抱有很大的期待的边翼。

另外官方文檔中也提到鱼响，在局域網(wǎng)環(huán)境下只要傳輸?shù)陌怀^一個 MTU （以太網(wǎng)下大約 1500 bytes），那么對于 10组底、100丈积、1000 bytes 不同包大小的處理吞吐能力實際結(jié)果差不多。關(guān)于吞吐量與數(shù)據(jù)大小的關(guān)系可見下面官方網(wǎng)站提供的示意圖债鸡。

驗證

基于我們真實的使用場景江滨，我們搭建了性能驗證環(huán)境，作了一個驗證測試厌均，如下（數(shù)據(jù)來自同事 @kusix 當(dāng)年的測試報告唬滑，感謝）。

測試前提
Redis version 2.4.1
Jmeter version 2.4
Network 1000Mb
Payload size = 100 bytes  
測試結(jié)果
SET: 32643.4/s
GET: 32478.8/s

在實驗環(huán)境下得到的測試數(shù)據(jù)給人的感覺和官方差了蠻多，這里面因為有網(wǎng)絡(luò)和客戶端庫綜合的影響所以沒有實際的橫向比較意義晶密。這個實驗環(huán)境實測數(shù)據(jù)只對我們真實的生產(chǎn)環(huán)境具有指導(dǎo)參考作用擒悬。在實驗環(huán)境的測試，單 Redis 實例運(yùn)行穩(wěn)定稻艰，單核 CPU 利用率在 70% ~ 80% 之間波動懂牧。除了測試 100 bytes 的包，還測了 1k尊勿、10k 和 100k 不同大小的包僧凤，如下圖所示：

誠然，1k 基本是 Redis 性能的一個拐點运怖，這一點從上圖看趨勢是和官方圖的一致拼弃。

現(xiàn)實

基于實驗室測試數(shù)據(jù)和實際業(yè)務(wù)量，現(xiàn)實中采用了 Redis 分片來承擔(dān)更大的吞吐量摇展。一個單一 Redis 分片一天的 ops 波動在 20k~30k 之間吻氧，單核 CPU 利用率在 40% ~ 80% 之間波動，如下圖咏连。

這與當(dāng)初實驗室環(huán)境的測試結(jié)果接近盯孙，而目前生產(chǎn)環(huán)境使用的 Redis 版本已升級到 2.8 了。如果業(yè)務(wù)量峰值繼續(xù)增高祟滴，看起來單個 Redis 分片還有大約 20% 的余量就到單實例極限了振惰。那么可行的辦法就是繼續(xù)增加分片的數(shù)量來分?jǐn)倖蝹€分片的壓力，前提是能夠很容易的增加分片而不影響業(yè)務(wù)系統(tǒng)垄懂。這才是使用 Redis 面臨的真正殘酷現(xiàn)實考驗骑晶。

殘酷

Redis 是個好東西，提供了很多好用的功能草慧，而且大部分實現(xiàn)的都還既可靠又高效（主從復(fù)制除外）桶蛔。所以一開始我們犯了一個天真的用法錯誤：把所有不同類型的數(shù)據(jù)都放在了一組 Redis 集群中。

• 長生命周期的用戶狀態(tài)數(shù)據(jù)
• 臨時緩存數(shù)據(jù)
• 后臺統(tǒng)計用的流水?dāng)?shù)據(jù)

導(dǎo)致的問題就是當(dāng)你想擴(kuò)分片的時候漫谷，客戶端 Hash 映射就變了仔雷，這是要遷移數(shù)據(jù)的。而所有數(shù)據(jù)放在一組 Redis 里舔示，要把它們分開就麻煩了碟婆，每個 Redis 實例里面都是千萬級的 key。

而另外一個問題是單個 Redis 的性能上限帶來的瓶頸問題惕稻。由于 CPU 的單核頻率都發(fā)展到了瓶頸竖共，都在往多核發(fā)展，一個 PC Server 一般 24或32 核俺祠。但 Redis 的單線程設(shè)計機(jī)制只能利用一個核肘迎，導(dǎo)致單核 CPU 的最大處理能力就是 Redis 單實例處理能力的天花板了甥温。

舉個具體的案例，新功能上線又有點不放心妓布，于是做了個開關(guān)放在 Redis姻蚓，所有應(yīng)用可以很方便的共享。通過讀取 Redis 中的開關(guān) key 來判斷是否啟用某個功能匣沼，對每個請求做判斷狰挡。這里的問題是什么？這個 key 只能放在一個實例上释涛，而所有的流量進(jìn)入都要去這個 Redis GET 一下加叁，導(dǎo)致該分片實例壓力山大。而它的極限在我們的環(huán)境上不過 4 萬 OPS唇撬，這個天花板其實并不高它匕。

總結(jié)

認(rèn)識清楚了現(xiàn)實的殘酷性，了解了你所在環(huán)境 Redis 的真實性能指標(biāo)窖认，區(qū)分清幻想和現(xiàn)實豫柬。我們才能真正考慮好如何合理的利用 Redis 的多功能特性，并有效規(guī)避的它的弱項扑浸，再給出一些 Redis 的使用建議：

-根據(jù)數(shù)據(jù)性質(zhì)把 Redis 集群分類烧给；我的經(jīng)驗是分三類：cache、buffer 和 db
- cache：臨時緩存數(shù)據(jù)喝噪，加分片擴(kuò)容容易础嫡，一般無持久化需要。
- buffer：用作緩沖區(qū)酝惧，平滑后端數(shù)據(jù)庫的寫操作榴鼎，根據(jù)數(shù)據(jù)重要性可能有持久化需求。
- db：替代數(shù)據(jù)庫的用法晚唇，有持久化需求檬贰。

• 規(guī)避在單實例上放熱點 key。
• 同一系統(tǒng)下的不同子應(yīng)用或服務(wù)使用的 Redis 也要隔離開

另外缺亮，有一種觀點認(rèn)為用作緩存 Memcache 更合適，這里可以獨立分析下其中的優(yōu)劣取舍吧桥言。Memcache 是設(shè)計為多線程的萌踱，所以在多核機(jī)器上單實例對 CPU 的利用更有效，所以它的性能天花板也更高号阿。（見下圖）要達(dá)到同樣的效果并鸵，對于一個 32 核機(jī)器，你可能需要部署 32 個 Redis 實例扔涧，對運(yùn)維也是一種負(fù)擔(dān)园担。

除此届谈，Redis 還有個 10k 問題，當(dāng)緩存數(shù)據(jù)大于 10k（用作靜態(tài)頁面的緩存弯汰，就可能超過這個大屑枭健）延遲會明顯增加，這也是單線程機(jī)制帶來的問題咏闪。如果你的應(yīng)用業(yè)務(wù)量離 Redis 的性能天花板還比較遠(yuǎn)而且也沒有 10k 需求曙搬，那么用 Redis 作緩存也是合理的，可以讓應(yīng)用減少多依賴一種外部技術(shù)棧鸽嫂。最后纵装，搞清楚現(xiàn)階段你的應(yīng)用到底需要什么，是多樣的數(shù)據(jù)結(jié)構(gòu)和功能据某、更好的擴(kuò)展能力還是更敏感的性能需求橡娄，然后再來選擇合適的工具吧。別只看到個基準(zhǔn)測試的性能數(shù)據(jù)癣籽，就歡呼雀躍起來了挽唉。

額外扯點其他的，Redis 的作者 @antirez 對自己的產(chǎn)品和技術(shù)那是相當(dāng)自信才避。一有人批評 Redis 的問題橱夭，他都是要跳出來在自己的 blog 里加以回應(yīng)和說明的。比如有人說 Redis 功能多容易使用但也容易誤用桑逝，作者就跑出來解釋我設(shè)計是針對每種不同場景的棘劣，你用的不對怪我咯，怪我咯楞遏。有人說緩存場景 Memcache 比 Redis 更合適茬暇，作者也專門寫了篇文章來說明，大概就是 Memcache 有的 Redis 都有寡喝，它沒有的我還有糙俗。當(dāng)然最后也承認(rèn)多線程是沒有的，但正在思考為 Redis I/O 增加線程预鬓，每個 Client 一個線程獨立處理巧骚，就像 Memcache 一樣，已經(jīng)等不及要去開發(fā)和測試了格二，封住所以批評者的嘴劈彪。

Redis 這些年不斷的增加新功能和優(yōu)化改進(jìn)，讓它變得更靈活場景適應(yīng)性更多的同時顶猜，也讓我們在使用時需要更細(xì)致的思考沧奴，不是它有什么我就用什么，而是你需要什么你就選擇什么长窄。

這篇先到這滔吠，后面還會再寫寫關(guān)于 Redis 擴(kuò)展方面的主題纲菌。

參考

[1] antirez. Redis Documentation.
[2] antirez. Clarifications about Redis and Memcached.
[3] antirez. Lazy Redis is better Redis.
[4] antirez. On Redis, Memcached, Speed, Benchmarks and The Toilet.
[5] antirez. An update on the Memcached/Redis benchmark.
[6] dormando. Redis VS Memcached (slightly better bench).
[7] Mike Perham. Storing Data with Redis.
[8] 溫柔一刀. Redis 常見的性能問題和解決方法.