Redis Cluster服務平臺化之路

1、 Redis Cluster 服務平臺化之路 1. Redis架構(gòu)的方案經(jīng)歷階段1.1. 客戶端分片客戶端分片：優(yōu)點不依賴于第三方中間件，實現(xiàn)方法和代碼自己掌控，可隨時調(diào)整這種分片機制的性能比代理式更好（少了一個中間分發(fā)環(huán)節(jié)）可控的分發(fā)請求，分發(fā)壓力落在客戶端，無服務器壓力增加缺點不能平滑的水平擴展節(jié)點，擴容/縮容時，必須手動調(diào)整分片程序出現(xiàn)故障，不能自動轉(zhuǎn)移，運維性很差客戶端得自己維護一套路由算法升級復雜1.2. TwemproxyTwemproxy：優(yōu)點運維成本低。業(yè)務方不用關心后端Redis實例，跟操作Redis一樣Proxy 的邏輯和存儲的邏輯是隔離的缺點代理層多了一次轉(zhuǎn)發(fā)，性能有所損

2、耗進行擴容/縮容時候，部分數(shù)據(jù)可能會失效，需要手動進行遷移，對運維要求較高，而且難以做到平滑的擴縮容出現(xiàn)故障，不能自動轉(zhuǎn)移，運維性很差升級復雜1.3. Redis ClusterRedis Cluster：優(yōu)點無中心節(jié)點數(shù)據(jù)按照Slot存儲分布在多個Redis實例上平滑的進行擴容/縮容節(jié)點自動故障轉(zhuǎn)移(節(jié)點之間通過Gossip協(xié)議交換狀態(tài)信息,進行投票機制完成Slave到Master角色的提升)降低運維成本，提高了系統(tǒng)的可擴展性和高可用性缺點嚴重依賴外部Redis-Trib缺乏監(jiān)控管理需要依賴Smart Client(連接維護, 緩存路由表, MultiOp和Pipeline支持)Failov

3、er節(jié)點的檢測過慢，不如“中心節(jié)點ZooKeeper”及時Gossip消息的開銷無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)Slave“冷備”，不能緩解讀壓力1.4. Proxy+Redis ClusterSmart Client vs Proxy：優(yōu)點Smart Client：a. 相比于使用代理，減少了一層網(wǎng)絡傳輸?shù)南模瘦^高。b. 不依賴于第三方中間件，實現(xiàn)方法和代碼自己掌控，可隨時調(diào)整。Proxy：a. 提供一套HTTP Restful接口，隔離底層存儲。對客戶端完全透明，跨語言調(diào)用。b. 升級維護較為容易，維護Redis Cluster，只需要平滑升級Proxy。c. 層次化存儲，底層存儲做冷熱異構(gòu)

4、存儲。d. 權(quán)限控制，Proxy可以通過秘鑰控制白名單，把一些不合法的請求都過濾掉。并且也可以控制用戶請求的超大Value進行控制，和過濾。e. 安全性，可以屏蔽掉一些危險命令，比如Keys、Save、Flush All等。f. 容量控制，根據(jù)不同用戶容量申請進行容量限制。g. 資源邏輯隔離，根據(jù)不同用戶的Key加上前綴，來進行資源隔離。h. 監(jiān)控埋點，對于不同的接口進行埋點監(jiān)控等信息。缺點Smart Client：a. 客戶端的不成熟，影響應用的穩(wěn)定性，提高開發(fā)難度。b. MultiOp和Pipeline支持有限。c. 連接維護，Smart客戶端對連接到集群中每個結(jié)點Socket的維護。Pr

5、oxy：a. 代理層多了一次轉(zhuǎn)發(fā)，性能有所損耗。b進行擴容/縮容時候?qū)\維要求較高，而且難以做到平滑的擴縮容。2. 為什么選擇Nginx開發(fā)Proxy單Master多Work模式，每個Work跟Redis一樣都是單進程單線程模式，并且都是基于Epoll事件驅(qū)動的模式。Nginx采用了異步非阻塞的方式來處理請求，高效的異步框架。內(nèi)存占用少，有自己的一套內(nèi)存池管理方式,。將大量小內(nèi)存的申請聚集到一塊，能夠比Malloc 更快。減少內(nèi)存碎片，防止內(nèi)存泄漏。減少內(nèi)存管理復雜度。為了提高Nginx的訪問速度，Nginx使用了自己的一套連接池。最重要的是支持自定義模塊開發(fā)。業(yè)界內(nèi)，對于Nginx，Redi

6、s的口碑可稱得上兩大神器。性能也就不用說了。3. Proxy+Redis Cluster介紹3.1 Proxy+Redis Cluster架構(gòu)方案介紹用戶在ACL平臺申請集群資源，如果申請成功返回秘鑰信息。用戶請求接口必須包含申請的秘鑰信息，請求至LVS服務器。LVS根據(jù)負載均衡策略將請求轉(zhuǎn)發(fā)至Nginx Proxy。Nginx Proxy首先會獲取秘鑰信息，然后根據(jù)秘鑰信息去ACL服務上獲取集群的種子信息。(種子信息是集群內(nèi)任意幾臺IP:PORT節(jié)點)然后把秘鑰信息和對應的集群種子信息緩存起來。并且第一次訪問會根據(jù)種子IP:PORT獲取集群Slot對應節(jié)點的Mapping路由信息，進行緩存起

7、來。最后根據(jù)Key計算SlotId，從緩存路由找到節(jié)點信息。把相應的K/V信息發(fā)送到對應的Redis節(jié)點上。Nginx Proxy定時(60s)上報請求接口埋點的QPS,RT,Err等信息到Open-Falcon平臺。Redis Cluster定時(60s)上報集群相關指標的信息到Open-Falcon平臺。3.2 Nginx Proxy功能介紹目前支持的功能：HTTP Restful接口：解析用戶Post過來的數(shù)據(jù)， 并且構(gòu)建Redis協(xié)議?？蛻舳瞬恍枰_發(fā)Smart Client, 對客戶端完全透明、跨語言調(diào)用權(quán)限控制：根據(jù)用戶Post數(shù)據(jù)獲取AppKey,Uri, 然后去ACL Serv

8、ice服務里面進行認證。如果認證通過，會給用戶返回相應的集群種子IP，以及相應的過期時間限制等信息限制數(shù)據(jù)大小：獲取用戶Post過來的數(shù)據(jù)，對Key，Value長度進行限制，避免產(chǎn)生超大的Key,Value，打滿網(wǎng)卡、阻塞Proxy數(shù)據(jù)壓縮/解壓：如果是寫請求，對Value進行壓縮(Snappy)，然后在把壓縮后的數(shù)據(jù)存儲到Redis Cluster。如果是讀請求，把Value從Redis Cluster讀出來，然后對Value進行解壓，最后響應給用戶。緩存路由信息：維護路由信息，Slot對應的節(jié)點的Mapping信息結(jié)果聚合：MultiOp支持批量指令支持(Pipeline/Redis+Lu

9、a+EVALSHA進行批量指令執(zhí)行)資源邏輯隔離：根據(jù)用戶Post數(shù)據(jù)獲取該用戶申請的NameSpace，然后以NameSpace作為該用戶請求Key的前綴，從而達到不同用戶的不同NameSpace，進行邏輯資源隔離重試策略：針對后端Redis節(jié)點出現(xiàn)Moved,Ask,Err,TimeOut等進行重試，重試次數(shù)可配置連接池：維護用戶請求的長連接，維護后端服務器的長連接配額管理：根據(jù)用戶的前綴(NameSpace), 定時的去抓取RANDOMKEY，根據(jù)一定的比率，估算出不同用戶的容量大小值，然后在對用戶的配額進行限制管理過載保護：通過在Nginx Proxy Limit模塊進行限速，超過集群

10、的承載能力，進行過載保護。從而保證部分用戶可用，不至于壓垮服務器監(jiān)控管理：Nginx Proxy接入了Open-Falcon對系統(tǒng)級別，應用級別，業(yè)務級別進行監(jiān)控和告警例如： 接口的QPS,RT,ERR等進行采集監(jiān)控，并且展示到DashBoard上告警閾值的設置非常靈活，配置化待開發(fā)的功能列表：層次化存儲：利用Nginx Proxy共享內(nèi)存定制化開發(fā)一套LRU本地緩存實現(xiàn)，從而減少網(wǎng)絡請求冷數(shù)據(jù)Swap到慢存儲，從而實現(xiàn)冷熱異構(gòu)存儲主動Failover節(jié)點：由于Redis Cluster是通過Gossip通信, 超過半數(shù)以上Master節(jié)點通信(cluster-node-timeout)認為當

11、前Master節(jié)點宕機，才真的確認該節(jié)點宕機。判斷節(jié)點宕機時間過長，在Proxy層加入Raft算法，加快失效節(jié)點判定，主動Failover3.3 Nginx Proxy性能優(yōu)化3.3.1 批量接口優(yōu)化方案1. 子請求變?yōu)閰f(xié)程案例：用戶需求調(diào)用批量接口mget(50Key)要求性能高，吞吐高，響應快。問題：由于最早用的Nginx Subrequest來做批量接口請求的處理，性能一直不高，CPU利用率也不高，QPS提不起來。通過火焰圖觀察分析子請求開銷比較大。解決方案：子請求效率較低，因為它需要重新從Server Rewrite開始走一遍Request處理的PHASE。并且子請求共享父請求的內(nèi)存池

12、，子請求同時并發(fā)度過大，導致內(nèi)存較高。協(xié)程輕量級的線程，占用內(nèi)存少。經(jīng)過調(diào)研和測試，單機一兩百萬個協(xié)程是沒有問題的，并且性能也很高。優(yōu)化前：a) 用戶請求mget(k1,k2)到Proxyb) Proxy根據(jù)k1,k2分別發(fā)起子請求subrequest1,subrequest2c) 子請求根據(jù)key計算slotid，然后去緩存路由表查找節(jié)點d) 子請求請求Redis Cluster的相關節(jié)點，然后響應返回給ProxyProxy會合并所有的子請求返回的結(jié)果，然后進行解析包裝返回給用戶優(yōu)化后：a) 用戶請求mget(k1,k2)到Proxyb) Proxy根據(jù)k1,k2分別計算slotid, 然后

13、去緩存路由表查找節(jié)點c) Proxy發(fā)起多個協(xié)程coroutine1, coroutine2并發(fā)的請求Redis Cluster的相關節(jié)點Proxy會合并多個協(xié)程返回的結(jié)果，然后進行解析包裝返回給用戶2. 合并相同槽，批量執(zhí)行指令，減少網(wǎng)絡開銷案例：用戶需求調(diào)用批量接口mget(50key)要求性能高，吞吐高，響應快。問題：經(jīng)過上面協(xié)程的方式進行優(yōu)化后，發(fā)現(xiàn)批量接口性能還是提升不夠高。通過火焰圖觀察分析網(wǎng)絡開銷比較大。解決方案：因為在Redis Cluster中，批量執(zhí)行的key必須在同一個slotid。所以，我們可以合并相同slotid的key做為一次請求。然后利用Pipeline/Lua+

14、EVALSHA批量執(zhí)行命令來減少網(wǎng)絡開銷，提高性能。優(yōu)化前：a) 用戶請求mget(k1,k2,k3,k4) 到Proxy。b) Proxy會解析請求串，然后計算k1,k2,k3,k4所對應的slotid。c) Proxy會根據(jù)slotid去路由緩存中找到后端服務器的節(jié)點，并發(fā)的發(fā)起多個請求到后端服務器。d) 后端服務器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應的value。Proxy把key,value對應數(shù)據(jù)包裝返回給用戶。優(yōu)化后：a) 用戶請求mget(k1,k2,k3,k4) 到Proxy。b) Proxy會解析請求串，然后計算k1,k2,k3,k4所對應的slotid

15、，然后把相同的slotid進行合并為一次Pipeline請求。c) Proxy會根據(jù)slotid去路由緩存中找到后端服務器的節(jié)點，并發(fā)的發(fā)起多個請求到后端服務器。d) 后端服務器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應的value。e) Proxy把key,value對應數(shù)據(jù)包裝返回給用戶。3. 對后端并發(fā)度的控制案例：當用戶調(diào)用批量接口請求mset，如果k數(shù)量幾百個甚至幾千個時，會導致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務器Redis Cluster。問題：Redis Cluster同時并發(fā)請求的協(xié)程過多，會導致連接數(shù)瞬間會很大，甚至超過上限，CPU,連

16、接數(shù)忽高忽低，對集群造成不穩(wěn)定。解決方案：單個批量請求對后端適當控制并發(fā)度進行分組并發(fā)請求，反向有利于性能提升，避免超過Redis Cluster連接數(shù)，同時Redis Cluster 波動也會小很多，更加的平滑。優(yōu)化前：a) 用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的邏輯)b) Proxy會解析這200個key，會同時發(fā)起200個協(xié)程請求并發(fā)的去請求Redis Cluster。Proxy等待所有協(xié)程請求完成，然后合并所有協(xié)程請求的響應結(jié)果，進行解析，包裝返回給用戶優(yōu)化后：a) 用戶請求批量接口mset(200個key)。 (這里先忽略合并相同槽的邏輯)b) Prox

17、y會解析這200個key，進行分組。100個key為一組，分批次進行并發(fā)請求。c) Proxy先同時發(fā)起第一組100個協(xié)程(coroutine1, coroutine100)請求并發(fā)的去請求Redis Cluster。d) Proxy等待所有協(xié)程請求完成，然后合并所有協(xié)程請求的響應結(jié)果。e) Proxy然后同時發(fā)起第二組100個協(xié)程(coroutine101, coroutine200)請求并發(fā)的去請求Redis Cluster。f) Proxy等待所有協(xié)程請求完成，然后合并所有協(xié)程請求的響應結(jié)果。g) Proxy把所有協(xié)程響應的結(jié)果進行解析，包裝，返回給用戶。4. 單Work分散到多Work

18、案例：當用戶調(diào)用批量接口請求mset，如果k數(shù)量幾百個甚至幾千個時，會導致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務器Redis Cluster。問題：由于Nginx的框架模型是單進程單線程, 所以Proxy發(fā)起的協(xié)程都會在一個Work上,這樣如果發(fā)起的協(xié)程請求過多就會導致單Work CPU打滿，導致Nginx 的每個Work CPU使用率非常不均，內(nèi)存持續(xù)暴漲的情況。(nginx 的內(nèi)存池只能提前釋放大塊，不會提前釋放小塊)解決方案：增加一層緩沖層代理，把請求的數(shù)據(jù)進行拆分為多份，然后每份發(fā)起請求，控制并發(fā)度，在轉(zhuǎn)發(fā)給Proxy層，避免單個較大的批量請求打滿單Work，從而達

19、到分散多Work，達到Nginx 多個Wrok CPU使用率均衡。優(yōu)化前：a) 用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的邏輯)b) Proxy會解析這200個key，會同時發(fā)起200個協(xié)程請求并發(fā)的去請求Redis Cluster。Proxy等待所有協(xié)程請求完成，然后合并所有協(xié)程請求的響應結(jié)果，進行解析，包裝返回給用戶。優(yōu)化后：a) 用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的key的邏輯)b) Proxy會解析這200個key，然后進行拆分分組以此來控制并發(fā)度。c) Proxy會根據(jù)劃分好的組進行一組一組的發(fā)起請求。Proxy等待所有請求完

20、成，然后合并所有協(xié)程請求的響應結(jié)果，進行解析，包裝返回給用戶?？偨Y(jié)，經(jīng)過上面一系列優(yōu)化，我們可以來看看針對批量接口mset(50個k/v)性能對比圖，Nginx Proxy的響應時間比Java版本的響應時間快了5倍多。Java版本：Nginx版本：3.3.2 網(wǎng)卡軟中斷優(yōu)化irqbalance根據(jù)系統(tǒng)中斷負載的情況，自動遷移中斷保持中斷的平衡。但是在實時系統(tǒng)中會導致中斷自動漂移，對性能造成不穩(wěn)定因素，在高性能的場合建議關閉。1.首先關閉網(wǎng)卡軟中斷2.查看網(wǎng)卡是隊列3.綁定網(wǎng)卡軟中斷到CPU0-2號上(注意這里的echo 是十六進制)3.3.3 綁定進程到指定的CPU綁定nginx或者redis

21、的pid到cpu3-cpu10上：3.3.4 性能優(yōu)化神器火焰圖3.4 Redis Cluster運維3.4.1 運維功能創(chuàng)建集群集群擴容/縮容節(jié)點宕機集群升級遷移數(shù)據(jù)副本遷移手動failover手動rebalance以上相關運維功能，目前是通過腳本配置化一鍵式操作，依賴于官方的redis-rebalance.rb進行擴展開發(fā)。運維非常方便快捷。3.5 性能測試報告3.5.1 測試環(huán)境軟件：JmeterNginx Proxy(24核)Redis集群(4 Master,4 Slave)測試Key(100000)硬件：OS： Centos6.6CPU：24核帶寬：千兆內(nèi)存：62G測試結(jié)果：場景：普

22、通K/VQPS：18W左右RT： 99都在10ms以內(nèi)CPU：Nginx Proxy CPU在50%左右4. 監(jiān)控告警4.1 系統(tǒng)級別通過Open-Falcon Agent采集服務器的CPU、內(nèi)存、網(wǎng)卡流量、網(wǎng)絡連接、磁盤等信息。4.2 應用級別通過Open-Falcon Plugin采集Nginx/Redis進程級別的CPU，內(nèi)存，Pid等信息。4.3 業(yè)務級別通過在Proxy里面埋點監(jiān)控業(yè)務接口QPS，RT(50%,99%,999%)，請求流量，錯誤次數(shù)等信息，定時的上報給Open-Falcon。通過Open-Falcon Plugin采集Redis Cluster集群信息，QPS，連接數(shù)

23、等相關指標指標信息。5. QAQ: 問個問題哈，Redis適合大數(shù)據(jù)的查詢和結(jié)果集的Union？A：由于Redis是單進程單線程的，不適合大數(shù)據(jù)的查詢和分析。Q: 是所有應用的數(shù)據(jù)都打散放在各個實例中了嗎，數(shù)據(jù)不均衡怎么辦？A: 數(shù)據(jù)是根據(jù)Redis Cluster內(nèi)部的crc32(key)%16384 每個實例都有部分槽，并且槽可以進行遷移。Q：我看剛才說99的請求在10ms內(nèi)，那平均的響應時常在多少呢？A: 平均響應時間都在1ms以內(nèi)。Q：Proxy是否有出現(xiàn)瓶頸，有案例嗎？如何解決類似情況？A: Proxy是單Master多Work的，可以充分內(nèi)用多核,cpu配置高更好了。 并且Prox

24、y是無狀態(tài)的，可以水平擴展。Q: 這些都是采用開源組件的嗎？其他人也可以搭建嗎，如何搭建的？A：這個是因為Nginx支持之定義模塊開發(fā)，所以需要在c/c+模塊里面進行開發(fā)，并且進行埋點，壓縮等工作。 并不是搭建就可以的。Q：我對那個平滑擴容的一直沒太理解，貌似剛?cè)肴旱臅r候我就問過了?A: 這個你可以學習Redis Cluster，它內(nèi)部自身提供該功能。Q: OpenResty Lua 處理部分在當前使用比例?A: 批量接口用到了lua的協(xié)程，所以目前批量接口都是用lua+c/c+結(jié)合開發(fā), 普通接口目前都是用c/c+模塊開發(fā)的。Q: 是否有開源的計劃，這樣大家也好 研究？A: 后續(xù)我們對Pro

25、xy還有部分工作要進一步完善，例如在Proxy層加入Raft算法，加快失效節(jié)點判定，主動Failover。 等完善的更健壯，會有開源的計劃。Q：在Proxy 完成Failover 對Redis Cluster 的改動就大了？A：Proxy只是去檢查master節(jié)點是不是真的掛掉，然后多個Proxy進行判決，由一個Proxy給Redis Cluster發(fā)起主動Failover命令，不涉及改動Redis Cluster。Q: 不同業(yè)務部門的數(shù)據(jù)物理是存儲在一起的嗎？A：不同的業(yè)務需要申請我們的合一平臺集群資源，獲得appkey,uri, 每個業(yè)務都有自己的namespace，你可以放到同一個集群，

26、他們是通過namespace+key來進行邏輯隔離的，跟其它業(yè)務不會產(chǎn)生沖突。如果對于非常重要的業(yè)務建議還是分開單獨部署一套集群比較好。Q: Nginx c/c+模塊開發(fā)，特別c+開發(fā)，有學習資料共享嗎？A: 對于Nginx提供幾種模塊開發(fā)Handler模塊，SubRequest模塊，F(xiàn)ilter模塊，Upstream模塊，我目前是有一本書深入理解Nginx模塊開發(fā)與架構(gòu)解析陶輝寫的。或者你可以看看tengine整理的教程 /book/關于語言基礎書推薦C+ Primer PlusQ: mset即然是分成多個請求發(fā)到不同的Cluster 節(jié)點，那么如果部分成功部分失敗，Proxy 如何給客戶端返回結(jié)果？A: 對于mset我們采取的是要么全部成功，要么就是失敗。所以，針對你這種部分失敗，我們內(nèi)部也會有重試機制的，如果達到最大重試次數(shù)，這個時候就認為真的是失敗的，不過客戶端可以根據(jù)失敗進行再次重試。Q：讀寫操作都是在master上執(zhí)行的嗎？A: 目前我們的讀寫都在master， 如果slave提供讀，你得容忍數(shù)據(jù)不一致，延遲的問題。Q: Nginx上的LuaJIT的性能對Redis/Memcached影響大嗎？比如LuaJIT的Int