引言:
        如今redis憑借其高性能的優(yōu)勢(shì), 以及豐富的數(shù)據(jù)結(jié)構(gòu)作為cache已越來越流行, 逐步取代了memcached等cache產(chǎn)品, 在Twitter,新浪微博中廣泛使用,阿里巴巴同樣如此. redis已經(jīng)占據(jù)了其不可動(dòng)搖的地位, 然而在實(shí)際的生產(chǎn)環(huán)境中, redis也暴露出一些其他問題.如性能瓶頸, 內(nèi)存冗余, 運(yùn)維部署復(fù)雜等. 本文目的就是分析redis現(xiàn)有的問題, 以及介紹阿里巴巴技術(shù)保障團(tuán)隊(duì)對(duì)redis的改造工作, 使其在生產(chǎn)環(huán)境中發(fā)揮更大的價(jià)值.
 
原生redis的瓶頸:
1. 單進(jìn)程單線程, 無法充分發(fā)揮服務(wù)器多核cpu的性能.
2. 大流量下造成IO阻塞. 同樣是由于單進(jìn)程單線程, cpu在處理業(yè)務(wù)邏輯的時(shí)候,網(wǎng)絡(luò)IO被阻塞住, 造成無法處理更多的請(qǐng)求.
3. 維護(hù)成本高, 如果想要充分發(fā)揮服務(wù)器的所有資源包括cpu, 網(wǎng)絡(luò)io等, 就必須建立多個(gè)instance, 但此時(shí)不可避免會(huì)增加維護(hù)成本.  拿24核服務(wù)器舉例來講, 如果部署24個(gè)單機(jī)版的instance,理論上可以實(shí)現(xiàn)10w*24core= 240wQPS的總體性能.但是每個(gè) instance 有各自獨(dú)立的數(shù)據(jù),占用資源如內(nèi)存也會(huì)同比上升,反過來制約一臺(tái)服務(wù)器又未必能支持這么多的 instance.  如果部署24個(gè)Instance來構(gòu)成單機(jī)集群, 雖然可以共享數(shù)據(jù)，但是因?yàn)楣?jié)點(diǎn)增加, redis的狀態(tài)通訊更加頻繁和費(fèi)時(shí),性能也下會(huì)降很多.  并且兩種方式都意味著要維護(hù)24個(gè)Instance，運(yùn)維成本都會(huì)成倍增加. 

4. 持久化. redis提供了兩種save方式 1)save觸發(fā). 2)bgsave. 當(dāng)然也可以使用3)aof來實(shí)現(xiàn)持久化, 但是這3點(diǎn)都有弊端.
         1)save:  由于是單進(jìn)程單線程, redis會(huì)阻塞住所有請(qǐng)求, 來遍歷所有redisDB, 把key-val寫入dump.rdb. 如果內(nèi)存數(shù)據(jù)量過大, 會(huì)造成短時(shí)間幾秒到幾十秒甚至更長(zhǎng)的時(shí)間停止服務(wù), 這種方案對(duì)于twitter, taobao等大流量的網(wǎng)站, 顯然是不可取的.  
         2)bgsave: 在觸發(fā)bgsave時(shí), redis會(huì)fork自身, child進(jìn)程會(huì)進(jìn)入1)的處理方式,這意味著服務(wù)器內(nèi)存要有一半的冗余才可以, 如今內(nèi)存已變得越來越廉價(jià), 但是對(duì)于存儲(chǔ)海量數(shù)據(jù)的情況,內(nèi)存以及服務(wù)器的成本還是不容忽視的. 
         3)aof:  說到持久化, redis提供的aof算是最完美的方案了, 但是有得必有失, 嚴(yán)重影響性能! 因?yàn)?/span>redis每接收到一條請(qǐng)求, 就要把命令內(nèi)容完整的寫到磁盤文件, 且不說頻繁讀寫會(huì)影響磁盤壽命,寫磁盤的時(shí)間足以拖垮redis整體性能 . 當(dāng)然熟悉redis的開發(fā)者會(huì)想到用appendfsync等參數(shù)來調(diào)整, 但都不是完美.即使使用 SSD，性能也只是略有提升，并且性價(jià)比不高。
 
針對(duì)以上幾種情況, 阿里技術(shù)保障團(tuán)隊(duì)做了如下優(yōu)化手段, 其實(shí)這不僅僅只是優(yōu)化, 而更是一種對(duì)redis的改造.
1. 多線程master + N*work 工作模式.master線程負(fù)責(zé)監(jiān)聽網(wǎng)絡(luò)事件, 在接收到一個(gè)新的連接后, master會(huì)把新的fd注冊(cè)到worker的epoll事件中, 交由worker處理這個(gè)fd的所有讀寫事件, 這樣master線程就可以完全被釋放出來接收更多的連接, 同時(shí)又不妨礙worker處理業(yè)務(wù)邏輯和IO讀寫.

采用這種master + N*worker的網(wǎng)絡(luò)層事件模型,可以實(shí)現(xiàn)redis性能的平行擴(kuò)展. 真正的讓redis在面臨高并發(fā)請(qǐng)求時(shí)可以叢容面對(duì).
2. 拋棄save, bgsave, aof等三種模式.采用redisDB lock模式. AliRedis在數(shù)據(jù)存儲(chǔ)層把多DB存儲(chǔ)模式轉(zhuǎn)換成HashDb存儲(chǔ), 將key hash到所有RedisDB上, 這樣做有一個(gè)弊端就是拋棄了select命令, 但與此同時(shí)會(huì)帶來一個(gè)更大的好處, 可以逐個(gè)DB持久化而不會(huì)影響整個(gè)系統(tǒng), 在做持久化的時(shí)候AliRedis只需lock住1/N個(gè)redisDb, 占用1/m個(gè)線程. 在不需要內(nèi)存冗余的情況下進(jìn)行持久化, 相比之前提到的弊端, 這種方式可以帶來更大的收益, 更豐厚的回報(bào).
3. 重構(gòu)hiredis客戶端, 支持redis-cluster工作模式, 目前hiredis并不支持redis-cluster模式, 阿里技術(shù)保障團(tuán)隊(duì)對(duì)hiredis進(jìn)行重構(gòu),使之支持redis-cluster.
4. 優(yōu)化jemalloc, 采用大內(nèi)存頁.  Redis在使用內(nèi)存方面可謂苛刻至極, 壓縮, string轉(zhuǎn)number等, 能省就省, 但是在實(shí)際生產(chǎn)環(huán)境中, 為了追求性能, 對(duì)于內(nèi)存的使用可以適度（不至于如bgsave般浪費(fèi)）通融處理, 因此AliRedis對(duì)jemalloc做了微調(diào), 通過調(diào)整pagesize來讓一次je_malloc分配更多run空間來儲(chǔ)備更多的用戶態(tài)可用內(nèi)存, 同時(shí)可以減輕換頁表的負(fù)載, 降低user sys的切換頻率, 來提高申請(qǐng)內(nèi)存的性能, 對(duì)jemalloc有興趣的開發(fā)者可以參考jemalloc源碼中的bin, run, chunk數(shù)據(jù)結(jié)構(gòu)進(jìn)行分析.

.



測(cè)試環(huán)境
CPU: Intel Xeon E5-2630 2.3GHz, *2
KERNEL: 3.2.0
GCC: 4.4.6
Jemalloc: 3.2.0
NIC: Intel 82599EB

測(cè)試數(shù)據(jù)
AliRedis單機(jī)版性能數(shù)據(jù)
thread:            1            2              4            8             12          16             20             24
set/get=1:1    83182  162214  301552 605817 876656 1173748 1551113 1800878

AliRedis集群
8個(gè)節(jié)點(diǎn), 20臺(tái)客戶端, 配置相同, cpu全部打滿.
set/get=1:1   qps: 10,344,877
 
結(jié)論
單機(jī)版AliRedis可以實(shí)現(xiàn)24核跑滿180wQPS性能.
集群版可以實(shí)現(xiàn)8臺(tái)服務(wù)器支撐1000wQPS的數(shù)據(jù)請(qǐng)求.
 
阿里巴巴技術(shù)保障團(tuán)隊(duì)肩負(fù)著支撐阿里技術(shù), 保障系統(tǒng)穩(wěn)定運(yùn)行的艱巨使命.不管是雙11, 還是雙12, 或者其他大促活動(dòng), 每個(gè)阿里人都在努力且拼命的工作, 拿自己的勞動(dòng)來捍衛(wèi)著阿里集團(tuán)的榮譽(yù).
 
阿里技術(shù)-保障奇跡.
                                                                                    阿里技術(shù)保障部-系統(tǒng)運(yùn)營-網(wǎng)絡(luò)部-子逍

來自：http://blog.sina.com.cn/s/blog_e59371cc0101br74.html