Redis Cluster服務(wù)平臺(tái)化之路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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