AliRedis單機180w QPS, 8臺服務器構建1000w QPS Cache集羣

轉自：http://www.open-open.com/lib/view/open1389880948758.html

引言:
        現在redis憑藉其高性能的優點, 以及豐富的數據結構做爲cache已愈來愈流行, 逐步取代了memcached等cache產品,在Twitter,新浪微博中普遍使用,阿里巴巴一樣如此. redis已經佔據了其不可動搖的地位, 然而在實際的生產環境中, redis也暴露出一些其餘問題.如性能瓶頸, 內存冗餘, 運維部署複雜等. 本文目的就是分析redis現有的問題, 以及介紹阿里巴巴技術保障團隊對redis的改造工做, 使其在生產環境中發揮更大的價值.
 
原生redis的瓶頸: 
1. 單進程單線程, 沒法充分發揮服務器多核cpu的性能.
2. 大流量下形成IO阻塞. 一樣是因爲單進程單線程, cpu在處理業務邏輯的時候,網絡IO被阻塞住, 形成沒法處理更多的請求.
3. 維護成本高, 若是想要充分發揮服務器的全部資源包括cpu, 網絡io等, 就必須創建多個instance, 但此時不可避免會增長維護成本.  拿24核服務器舉例來說, 若是部署24個單機版的instance,理論上能夠實現10w*24core= 240wQPS的整體性能.可是每一個 instance 有各自獨立的數據,佔用資源如內存也會同比上升,反過來制約一臺服務器又未必能支持這麼多的 instance.  若是部署24個Instance來構成單機集羣, 雖然能夠共享數據，可是由於節點增長, redis的狀態通信更加頻繁和費時,性能也下會降不少.  而且兩種方式都意味着要維護24個Instance，運維成本都會成倍增長. 

4. 持久化. redis提供了兩種save方式 1)save觸發. 2)bgsave. 固然也可使用3)aof來實現持久化, 可是這3點都有弊端.
         1)save:  因爲是單進程單線程, redis會阻塞住全部請求, 來遍歷全部redisDB, 把key-val寫入dump.rdb. 若是內存數據量過大, 會形成短期幾秒到幾十秒甚至更長的時間中止服務, 這種方案對於twitter, taobao等大流量的網站, 顯然是不可取的.  
         2)bgsave: 在觸發bgsave時, redis會fork自身, child進程會進入1)的處理方式,這意味着服務器內存要有一半的冗餘才能夠, 現在內存已變得愈來愈廉價, 可是對於存儲海量數據的狀況,內存以及服務器的成本仍是不容忽視的. 
         3)aof:  說到持久化, redis提供的aof算是最完美的方案了, 可是有得必有失, 嚴重影響性能! 由於redis每接收到一條請求,就要把命令內容完整的寫到磁盤文件, 且不說頻繁讀寫會影響磁盤壽命,寫磁盤的時間足以拖垮redis總體性能 . 固然熟悉redis的開發者會想到用appendfsync等參數來調整, 但都不是完美.即便使用 SSD，性能也只是略有提高，而且性價比不高。
 
針對以上幾種狀況, 阿里技術保障團隊作了以下優化手段, 其實這不只僅只是優化, 而更是一種對redis的改造.
1. 多線程master + N*work 工做模式.master線程負責監聽網絡事件, 在接收到一個新的鏈接後, master會把新的fd註冊到worker的epoll事件中, 交由worker處理這個fd的全部讀寫事件, 這樣master線程就能夠徹底被釋放出來接收更多的鏈接, 同時又不妨礙worker處理業務邏輯和IO讀寫.

採用這種master + N*worker的網絡層事件模型,能夠實現redis性能的平行擴展. 真正的讓redis在面臨高併發請求時能夠叢容面對.
2. 拋棄save, bgsave, aof等三種模式.採用redisDB lock模式. AliRedis在數據存儲層把多DB存儲模式轉換成HashDb存儲,將key hash到全部RedisDB上, 這樣作有一個弊端就是拋棄了select命令, 但與此同時會帶來一個更大的好處, 能夠逐個DB持久化而不會影響整個系統, 在作持久化的時候AliRedis只需lock住1/N個redisDb, 佔用1/m個線程. 在不須要內存冗餘的狀況下進行持久化, 相比以前提到的弊端, 這種方式能夠帶來更大的收益, 更豐厚的回報.
3. 重構hiredis客戶端, 支持redis-cluster工做模式, 目前hiredis並不支持redis-cluster模式, 阿里技術保障團隊對hiredis進行重構,使之支持redis-cluster.
4. 優化jemalloc, 採用大內存頁.  Redis在使用內存方面可謂苛刻至極, 壓縮, string轉number等, 能省就省, 可是在實際生產環境中, 爲了追求性能, 對於內存的使用能夠適度（不至於如bgsave般浪費）通融處理, 所以AliRedis對jemalloc作了微調, 經過調整pagesize來讓一次je_malloc分配更多run空間來儲備更多的用戶態可用內存, 同時能夠減輕換頁表的負載, 下降user sys的切換頻率, 來提升申請內存的性能, 對jemalloc有興趣的開發者能夠參考jemalloc源碼中的bin, run, chunk數據結構進行分析.

經過如上改造 , redis 能夠充分發揮服務器多核的優點 , 以及網絡 IO 複用 , 特別是節省運維成本 , 每臺服務器只需維護一個AliRedis 實例 .



測試環境
CPU: Intel Xeon E5-2630 2.3GHz, *2
KERNEL: 3.2.0
GCC: 4.4.6
Jemalloc: 3.2.0
NIC: Intel 82599EB

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

AliRedis集羣
8個節點, 20臺客戶端, 配置相同, cpu所有打滿.
set/get=1:1   qps: 10,344,877
 
結論
單機版AliRedis能夠實現24核跑滿180wQPS性能.
集羣版能夠實現8臺服務器支撐1000wQPS的數據請求.
 
阿里巴巴技術保障團隊肩負着支撐阿里技術, 保障系統穩定運行的艱鉅使命.不論是雙11, 仍是雙12, 或者其餘大促活動, 每一個阿里人都在努力且拼命的工做, 拿本身的勞動來捍衛着阿里集團的榮譽.
 
阿里技術-保障奇蹟.
                                                                                    阿里技術保障部-系統運營-網絡部-子逍

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