1.1. 客戶端分片

優(yōu)點

不依賴于第三方中間件，實現(xiàn)方法和代碼自己掌控,，可隨時調(diào)整

這種分片機制的性能比代理式更好（少了一個中間分發(fā)環(huán)節(jié)）

可控的分發(fā)請求,，分發(fā)壓力落在客戶端，無服務(wù)器壓力增加

缺點

不能平滑的水平擴展節(jié)點,，擴容/縮容時,，必須手動調(diào)整分片程序

出現(xiàn)故障，不能自動轉(zhuǎn)移,，運維性很差

客戶端得自己維護一套路由算法

升級復雜

優(yōu)點

運維成本低。業(yè)務(wù)方不用關(guān)心后端Redis實例,，跟操作Redis一樣

Proxy 的邏輯和存儲的邏輯是隔離的

缺點

代理層多了一次轉(zhuǎn)發(fā),，性能有所損耗

進行擴容/縮容時候，部分數(shù)據(jù)可能會失效,，需要手動進行遷移,，對運維要求較高，而且難以做到平滑的擴縮容

出現(xiàn)故障,，不能自動轉(zhuǎn)移,，運維性很差

升級復雜

1.3. Redis 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支持)

Failover節(jié)點的檢測過慢,，不如“中心節(jié)點ZooKeeper”及時

Gossip消息的開銷

無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)

Slave“冷備”,，不能緩解讀壓力

Smart Client vs Proxy：

優(yōu)點

Smart Client：

a. 相比于使用代理，減少了一層網(wǎng)絡(luò)傳輸?shù)南?，效率較高,。

b. 不依賴于第三方中間件，實現(xiàn)方法和代碼自己掌控,，可隨時調(diào)整,。

Proxy：

a. 提供一套HTTP Restful接口，隔離底層存儲,。對客戶端完全透明,，跨語言調(diào)用。

b. 升級維護較為容易,，維護Redis Cluster,，只需要平滑升級Proxy。

c. 層次化存儲,，底層存儲做冷熱異構(gòu)存儲,。

d. 權(quán)限控制,，Proxy可以通過秘鑰控制白名單，把一些不合法的請求都過濾掉,。并且也可以控制用戶請求的超大Value進行控制,，和過濾。

e. 安全性,，可以屏蔽掉一些危險命令,，比如Keys、Save,、Flush All等,。

f. 容量控制，根據(jù)不同用戶容量申請進行容量限制,。

g. 資源邏輯隔離,，根據(jù)不同用戶的Key加上前綴，來進行資源隔離,。

h. 監(jiān)控埋點,，對于不同的接口進行埋點監(jiān)控等信息。

缺點

Smart Client：

a. 客戶端的不成熟,，影響應(yīng)用的穩(wěn)定性,，提高開發(fā)難度。

b. MultiOp和Pipeline支持有限,。

c. 連接維護,，Smart客戶端對連接到集群中每個結(jié)點Socket的維護。

Proxy：

a.  代理層多了一次轉(zhuǎn)發(fā),，性能有所損耗,。

b．進行擴容/縮容時候?qū)\維要求較高，而且難以做到平滑的擴縮容,。

1. 單Master多Work模式，每個Work跟Redis一樣都是單進程單線程模式,，并且都是基于Epoll事件驅(qū)動的模式,。

2. Nginx采用了異步非阻塞的方式來處理請求，高效的異步框架,。

3. 內(nèi)存占用少,，有自己的一套內(nèi)存池管理方式,。將大量小內(nèi)存的申請聚集到一塊,，能夠比Malloc 更快,。減少內(nèi)存碎片，防止內(nèi)存泄漏,。減少內(nèi)存管理復雜度,。

4. 為了提高Nginx的訪問速度,，Nginx使用了自己的一套連接池。

5. 最重要的是支持自定義模塊開發(fā),。

6. 業(yè)界內(nèi),，對于Nginx，Redis的口碑可稱得上兩大神器,。性能也就不用說了,。

3.1  Proxy Redis Cluster架構(gòu)方案介紹

1. 用戶在ACL平臺申請集群資源,，如果申請成功返回秘鑰信息,。

2. 用戶請求接口必須包含申請的秘鑰信息，請求至LVS服務(wù)器,。

3. LVS根據(jù)負載均衡策略將請求轉(zhuǎn)發(fā)至Nginx Proxy,。

4. Nginx Proxy首先會獲取秘鑰信息，然后根據(jù)秘鑰信息去ACL服務(wù)上獲取集群的種子信息,。(種子信息是集群內(nèi)任意幾臺IP:PORT節(jié)點)

5. 然后把秘鑰信息和對應(yīng)的集群種子信息緩存起來,。并且第一次訪問會根據(jù)種子IP:PORT獲取集群Slot對應(yīng)節(jié)點的Mapping路由信息，進行緩存起來,。最后根據(jù)Key計算SlotId，從緩存路由找到節(jié)點信息,。

6. 把相應(yīng)的K/V信息發(fā)送到對應(yīng)的Redis節(jié)點上,。

7. Nginx Proxy定時(60s)上報請求接口埋點的QPS,RT,Err等信息到Open-Falcon平臺。

8. Redis Cluster定時(60s)上報集群相關(guān)指標的信息到Open-Falcon平臺,。

目前支持的功能：

HTTP Restful接口：

解析用戶Post過來的數(shù)據(jù),， 并且構(gòu)建Redis協(xié)議?？蛻舳瞬恍枰_發(fā)Smart Client, 對客戶端完全透明,、跨語言調(diào)用

權(quán)限控制：

根據(jù)用戶Post數(shù)據(jù)獲取AppKey,Uri, 然后去ACL Service服務(wù)里面進行認證。如果認證通過,，會給用戶返回相應(yīng)的集群種子IP,，以及相應(yīng)的過期時間限制等信息

限制數(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進行解壓,，最后響應(yīng)給用戶,。

緩存路由信息：

維護路由信息，Slot對應(yīng)的節(jié)點的Mapping信息

結(jié)果聚合：

MultiOp支持

批量指令支持(Pipeline/Redis Lua EVALSHA進行批量指令執(zhí)行)

資源邏輯隔離：

根據(jù)用戶Post數(shù)據(jù)獲取該用戶申請的NameSpace,，然后以NameSpace作為該用戶請求Key的前綴,，從而達到不同用戶的不同NameSpace，進行邏輯資源隔離

重試策略：

針對后端Redis節(jié)點出現(xiàn)Moved,Ask,Err,TimeOut等進行重試,，重試次數(shù)可配置

連接池：

維護用戶請求的長連接,，維護后端服務(wù)器的長連接

配額管理：

根據(jù)用戶的前綴(NameSpace), 定時的去抓取RANDOMKEY，根據(jù)一定的比率,，估算出不同用戶的容量大小值,，然后在對用戶的配額進行限制管理

過載保護：

通過在Nginx Proxy Limit模塊進行限速，超過集群的承載能力,，進行過載保護,。從而保證部分用戶可用，不至于壓垮服務(wù)器

監(jiān)控管理：

Nginx Proxy接入了Open-Falcon對系統(tǒng)級別,，應(yīng)用級別,，業(yè)務(wù)級別進行監(jiān)控和告警

例如： 接口的QPS,RT,ERR等進行采集監(jiān)控，并且展示到DashBoard上

告警閾值的設(shè)置非常靈活,，配置化

待開發(fā)的功能列表：

層次化存儲：

利用Nginx Proxy共享內(nèi)存定制化開發(fā)一套LRU本地緩存實現(xiàn),，從而減少網(wǎng)絡(luò)請求冷數(shù)據(jù)Swap到慢存儲，從而實現(xiàn)冷熱異構(gòu)存儲

主動Failover節(jié)點：

由于Redis Cluster是通過Gossip通信, 超過半數(shù)以上Master節(jié)點通信(cluster-node-timeout)認為當前Master節(jié)點宕機,，才真的確認該節(jié)點宕機,。判斷節(jié)點宕機時間過長，在Proxy層加入Raft算法,，加快失效節(jié)點判定,，主動Failover

3.3  Nginx Proxy性能優(yōu)化

3.3.1  批量接口優(yōu)化方案

1. 子請求變?yōu)閰f(xié)程

案例：

用戶需求調(diào)用批量接口mget(50Key)要求性能高，吞吐高,，響應(yīng)快,。

問題：

由于最早用的Nginx Subrequest來做批量接口請求的處理，性能一直不高,，CPU利用率也不高,，QPS提不起來。通過火焰圖觀察分析子請求開銷比較大,。

解決方案：

子請求效率較低,，因為它需要重新從Server Rewrite開始走一遍Request處理的PHASE。并且子請求共享父請求的內(nèi)存池,，子請求同時并發(fā)度過大,，導致內(nèi)存較高,。

協(xié)程輕量級的線程，占用內(nèi)存少,。經(jīng)過調(diào)研和測試,，單機一兩百萬個協(xié)程是沒有問題的，并且性能也很高,。

優(yōu)化前：

a) 用戶請求mget(k1,k2)到Proxy

b) Proxy根據(jù)k1,k2分別發(fā)起子請求subrequest1,subrequest2

c) 子請求根據(jù)key計算slotid,，然后去緩存路由表查找節(jié)點

d) 子請求請求Redis Cluster的相關(guān)節(jié)點，然后響應(yīng)返回給Proxy

e) Proxy會合并所有的子請求返回的結(jié)果,，然后進行解析包裝返回給用戶

優(yōu)化后：

a) 用戶請求mget(k1,k2)到Proxy

b) Proxy根據(jù)k1,k2分別計算slotid, 然后去緩存路由表查找節(jié)點

c) Proxy發(fā)起多個協(xié)程coroutine1, coroutine2并發(fā)的請求Redis Cluster的相關(guān)節(jié)點

d) Proxy會合并多個協(xié)程返回的結(jié)果,，然后進行解析包裝返回給用戶

2. 合并相同槽，批量執(zhí)行指令,，減少網(wǎng)絡(luò)開銷

案例：

用戶需求調(diào)用批量接口mget(50key)要求性能高,，吞吐高，響應(yīng)快,。

問題：

經(jīng)過上面協(xié)程的方式進行優(yōu)化后,，發(fā)現(xiàn)批量接口性能還是提升不夠高。通過火焰圖觀察分析網(wǎng)絡(luò)開銷比較大,。

解決方案：

因為在Redis Cluster中,，批量執(zhí)行的key必須在同一個slotid。所以,，我們可以合并相同slotid的key做為一次請求,。然后利用Pipeline/Lua EVALSHA批量執(zhí)行命令來減少網(wǎng)絡(luò)開銷，提高性能,。

優(yōu)化前：

a) 用戶請求mget(k1,k2,k3,k4) 到Proxy,。

b) Proxy會解析請求串,，然后計算k1,k2,k3,k4所對應(yīng)的slotid,。

c) Proxy會根據(jù)slotid去路由緩存中找到后端服務(wù)器的節(jié)點，并發(fā)的發(fā)起多個請求到后端服務(wù)器,。

d) 后端服務(wù)器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應(yīng)的value,。

e) Proxy把key,value對應(yīng)數(shù)據(jù)包裝返回給用戶。

優(yōu)化后：

a) 用戶請求mget(k1,k2,k3,k4) 到Proxy,。

b) Proxy會解析請求串,，然后計算k1,k2,k3,k4所對應(yīng)的slotid，然后把相同的slotid進行合并為一次Pipeline請求,。

c) Proxy會根據(jù)slotid去路由緩存中找到后端服務(wù)器的節(jié)點,，并發(fā)的發(fā)起多個請求到后端服務(wù)器。

d) 后端服務(wù)器返回結(jié)果給Proxy,然后Proxy進行解析獲取key對應(yīng)的value,。

e) Proxy把key,value對應(yīng)數(shù)據(jù)包裝返回給用戶,。

 3. 對后端并發(fā)度的控制

案例：

當用戶調(diào)用批量接口請求mset,，如果k數(shù)量幾百個甚至幾千個時，會導致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務(wù)器Redis Cluster,。

問題：

Redis Cluster同時并發(fā)請求的協(xié)程過多,，會導致連接數(shù)瞬間會很大，甚至超過上限,，CPU,連接數(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,。

c) Proxy等待所有協(xié)程請求完成，然后合并所有協(xié)程請求的響應(yīng)結(jié)果,，進行解析,，包裝返回給用戶。

優(yōu)化后：

a) 用戶請求批量接口mset(200個key),。 (這里先忽略合并相同槽的邏輯)

b) Proxy會解析這200個key,，進行分組。100個key為一組,，分批次進行并發(fā)請求,。

c) Proxy先同時發(fā)起第一組100個協(xié)程(coroutine1, coroutine100)請求并發(fā)的去請求Redis Cluster。

d) Proxy等待所有協(xié)程請求完成,，然后合并所有協(xié)程請求的響應(yīng)結(jié)果,。

e) Proxy然后同時發(fā)起第二組100個協(xié)程(coroutine101, coroutine200)請求并發(fā)的去請求Redis Cluster。

f) Proxy等待所有協(xié)程請求完成,，然后合并所有協(xié)程請求的響應(yīng)結(jié)果,。

g) Proxy把所有協(xié)程響應(yīng)的結(jié)果進行解析，包裝,，返回給用戶,。

4.單Work分散到多Work

案例：

當用戶調(diào)用批量接口請求mset，如果k數(shù)量幾百個甚至幾千個時,，會導致Proxy瞬間同時發(fā)起幾百甚至幾千個協(xié)程同時去訪問后端服務(wù)器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,，從而達到分散多Work，達到Nginx 多個Wrok CPU使用率均衡,。

優(yōu)化前：

a) 用戶請求批量接口mset(200個key),。(這里先忽略合并相同槽的邏輯)

b) Proxy會解析這200個key，會同時發(fā)起200個協(xié)程請求并發(fā)的去請求Redis Cluster,。

c) Proxy等待所有協(xié)程請求完成,，然后合并所有協(xié)程請求的響應(yīng)結(jié)果，進行解析,，包裝返回給用戶,。

優(yōu)化后：

a) 用戶請求批量接口mset(200個key)。(這里先忽略合并相同槽的key的邏輯)

b) Proxy會解析這200個key,，然后進行拆分分組以此來控制并發(fā)度,。

c) Proxy會根據(jù)劃分好的組進行一組一組的發(fā)起請求。

d) Proxy等待所有請求完成,，然后合并所有協(xié)程請求的響應(yīng)結(jié)果,，進行解析，包裝返回給用戶,。

總結(jié),，經(jīng)過上面一系列優(yōu)化，我們可以來看看針對批量接口mset(50個k/v)性能對比圖,，Nginx Proxy的響應(yīng)時間比Java版本的響應(yīng)時間快了5倍多,。

Java版本：

Nginx版本：

 3.3.2  網(wǎng)卡軟中斷優(yōu)化

irqbalance根據(jù)系統(tǒng)中斷負載的情況，自動遷移中斷保持中斷的平衡,。但是在實時系統(tǒng)中會導致中斷自動漂移,，對性能造成不穩(wěn)定因素,，在高性能的場合建議關(guān)閉,。

1. 首先關(guān)閉網(wǎng)卡軟中斷

service irqbalance stop

service cpuspeed stop

2. 查看網(wǎng)卡是隊列

grep eth /proc/interrupts | awk '{print $1, $NF}'

77: eth0

78: eth0-TxRx-0

79: eth0-TxRx-1

80: eth0-TxRx-2

81: eth0-TxRx-3

82: eth0-TxRx-4

83: eth0-TxRx-5

84: eth0-TxRx-6

85: eth0-TxRx-7

3. 綁定網(wǎng)卡軟中斷到CPU0-2號上

(注意這里的echo 是十六進制)

echo '1' > /proc/irq/78/smp_affinity  

echo '1' > /proc/irq/79/smp_affinity  

echo '2' > /proc/irq/80/smp_affinity  

echo '2' > /proc/irq/81/smp_affinity  

echo '2' > /proc/irq/82/smp_affinity  

echo '4' > /proc/irq/83/smp_affinity  

echo '4' > /proc/irq/84/smp_affinity  

echo '4' > /proc/irq/85/smp_affinity

 3.3.3  綁定進程到指定的CPU

綁定nginx或者redis的pid到cpu3-cpu10上：  

taskset -cp 3 1900

taskset -cp 4 1901

taskset -cp 5 1902

taskset -cp 6 1903

taskset -cp 7 1904

taskset -cp 8 1905

taskset -cp 9 1902

taskset -cp 10 1902

或者通過Nginx Proxy配置：

worker_cpu_affinity 綁定CPU親緣性

 3.3.4  性能優(yōu)化神器火焰圖

3.4  Redis Cluster運維

3.4.1 運維功能

1. 創(chuàng)建集群

2. 集群擴容/縮容

3. 節(jié)點宕機

4. 集群升級

5. 遷移數(shù)據(jù)

6. 副本遷移

7. 手動failover

8. 手動rebalance

以上相關(guān)運維功能，目前是通過腳本配置化一鍵式操作,，依賴于官方的redis-rebalance.rb進行擴展開發(fā),。運維非常方便快捷。

3.5  性能測試報告

3.5.1  測試環(huán)境

軟件：

Jmeter

Nginx Proxy(24核)

Redis集群(4 Master,4 Slave)

測試Key(100000)

硬件：

OS： Centos6.6

CPU：24核

帶寬：千兆

內(nèi)存：62G

測試結(jié)果：

場景：普通K/V

QPS：18W左右

RT： 99都在10ms以內(nèi)

CPU：Nginx Proxy CPU在50%左右

通過Open-Falcon Agent采集服務(wù)器的CPU,、內(nèi)存,、網(wǎng)卡流量、網(wǎng)絡(luò)連接,、磁盤等信息,。

4.2 應(yīng)用級別

通過Open-Falcon Plugin采集Nginx/Redis進程級別的CPU，內(nèi)存,，Pid等信息,。

4.3 業(yè)務(wù)級別

通過在Proxy里面埋點監(jiān)控業(yè)務(wù)接口QPS，RT(50%,99%,999%),，請求流量,，錯誤次數(shù)等信息，定時的上報給Open-Falcon,。

通過Open-Falcon Plugin采集Redis Cluster集群信息,，QPS，連接數(shù)等相關(guān)指標指標信息,。

五,、QA

Q: 問個問題哈，Redis適合大數(shù)據(jù)的查詢和結(jié)果集的Union,？

A：由于Redis是單進程單線程的,，不適合大數(shù)據(jù)的查詢和分析。

Q: 是所有應(yīng)用的數(shù)據(jù)都打散放在各個實例中了嗎,，數(shù)據(jù)不均衡怎么辦,？

A: 數(shù)據(jù)是根據(jù)Redis Cluster內(nèi)部的crc32(key)%16384每個實例都有部分槽，并且槽可以進行遷移

Q：我看剛才說99的請求在10ms內(nèi),，那平均的響應(yīng)時常在多少呢,？

A: 平均響應(yīng)時間都在1ms以內(nèi)

Q：Proxy是否有出現(xiàn)瓶頸，有案例嗎,？如何解決類似情況,？

A: Proxy是單Master多Work的，可以充分內(nèi)用多核,cpu配置高更好了,。 并且Proxy是無狀態(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ù)我們對Proxy還有部分工作要進一步完善,，例如在Proxy層加入Raft算法，加快失效節(jié)點判定,，主動Failover,。等完善的更健壯，會有開源的計劃,。

Q：在Proxy 完成Failover 對Redis Cluster 的改動就大了,？

A：Proxy只是去檢查master節(jié)點是不是真的掛掉，然后多個Proxy進行判決,，由一個Proxy給Redis Cluster發(fā)起主動Failover命令,，不涉及改動Redis Cluster。

Q: 不同業(yè)務(wù)部門的數(shù)據(jù)物理是存儲在一起的嗎,？

A：不同的業(yè)務(wù)需要申請我們的合一平臺集群資源,，獲得appkey,uri, 每個業(yè)務(wù)都有自己的namespace，你可以放到同一個集群,，他們是通過namespace key來進行邏輯隔離的,，跟其它業(yè)務(wù)不會產(chǎn)生沖突。

如果對于非常重要的業(yè)務(wù)建議還是分開單獨部署一套集群比較好,。

Q: Nginxc/c 模塊開發(fā),，特別c 開發(fā)，有學習資料共享嗎,？

A: 對于Nginx提供幾種模塊開發(fā)Handler模塊,，SubRequest模塊，Filter模塊,，Upstream模塊,，我目前是有一本書《深入理解Nginx模塊開發(fā)與架構(gòu)解析》陶輝寫的。

或者你可以看看tengine整理的教程 http://tengine./book/

關(guān)于語言基礎(chǔ)書推薦《C Primer Plus》

Q: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的Intepreter模式跟LuaJIT的JIT方式，性能會在nginx cache的這種架構(gòu)下帶來多少性能開銷,？

A: 這個我有對比過純c/c 模塊跟lua模塊的性能,，確實有些損耗，經(jīng)過優(yōu)化效果還是不錯,，但是批量接口Nginx的subrequest效率本身就比較低,。這塊有Lua的協(xié)程來處理的。

Nginx是多進程的,，這樣用戶請求可以充分利用多核。您說的LuaJIT這兩種方式我沒有具體對比過，不好意思,。不過線下我們可以私聊,，進步交流互相學習下。

Q: Redis在合一的應(yīng)用場景

A: 目前優(yōu)土全站的視頻播放數(shù)服務(wù)是我們最大的一個服務(wù),，每天支撐300多億次的請求,，峰值QPS在80w時，整體系統(tǒng)的CPU在20%以下,；另外還有用戶視頻推薦的相關(guān)信息等,。

Q:Nginx Redis Clustet這樣的結(jié)果支持跨機房部署嗎？能擴展讀操作嗎,？

A: 本著數(shù)據(jù)接近計算的原則,，我們的服務(wù)是在多IDC部署的，每個應(yīng)用方在申請資源時,，我們會給他分配一個最近的IDC提供資源,，以最大限度保障服務(wù)可用性。

可以在Proxy層封裝和擴展任何Redis底層的接口,，另外也可以利用Redis本身嵌入Lua來擴展,。

Q: 對于用戶來講,，是怎么說服他們使用你們包裝的HTTP協(xié)議而不是原生Redis協(xié)議的？

A：提供統(tǒng)一的HTTP Restful接口,客戶端不需要開發(fā)SmartClient, 對客戶端完全透明,、跨語言調(diào)用,。這樣不用依賴官方的驅(qū)動，并且官方的驅(qū)動包有些bug,，客戶端也不好維護,，并且得跟著官方驅(qū)動包升級，這個成本還是很大的,。

相反如果是簡單的HTTP Restful  Proxy平滑升級即可,，客戶端不需要操作什么。

Q:24核心測試環(huán)境下只有18w qps其實不算太高的性能,，單核心的Redis在沒有Pipeline的情況下也有五六萬的,，Proxy會不會成為性能瓶頸？

A: 18w是控制cpu在50%以內(nèi),，并且響應(yīng)時間999 都在10ms以內(nèi),，并不是極限壓測。并且Proxy是無狀態(tài)的,，可以水平擴展,。

Q: 你們規(guī)定的HTTP協(xié)議如何處理二進制存儲需求的？

A: 由于目前沒有這種場景,，所以目前并不支持二進制存儲,。

運維幫近期沙龍活動

• 最火爆的沙龍,，運維幫技術(shù)沙龍「運維與架構(gòu)」 (深圳站·6月25號·免費)

• 烏云白帽大會·不插電,，體驗不一樣的黑客文化
  

文章精選

• 專訪阿里云資深總監(jiān)李津：論開源戰(zhàn)略,、安全服務(wù)和運維行業(yè)的變化
  

• 【運維者說】O2O大戰(zhàn)之后，看到家美食會如何做運維
  

• Linux TCP隊列相關(guān)參數(shù)的總結(jié)
  

• 每個做SOA服務(wù)化的團隊,，都需要一個trace系統(tǒng)
  

• 烏云白帽大會·不插電,，體驗不一樣的黑客文化

• 區(qū)塊鏈技術(shù)涉足DNS領(lǐng)域了，研究一下就好,，普及這事......
  

• 這可能是最全的 Redis 集群方案介紹了
  

• tomcat的配置和優(yōu)化

• LVS負載均衡的三種模式和八種算法總結(jié)

QQ技術(shù)討論群：542812110