Redis服務支持5000萬的QPS，有什麼好的思路？

01-11

其中寫請求有2000萬左右；需要持久化，高可用；
按照實際的生產經驗，大概需要1600左右的實例（包含副本）
官方的 redis cluster 搞不定，單個集群超過1000個分片後，gossip通信成本太高，
更改 node-timeout 到30s也不具有可用性；
實例之間只能互相獨立，由proxy存儲路由的方式能達到這樣的規模，貌似codis的架構可以滿足；（最多支持1024個group這個調整下就好）

阿里的 ApsaraCache 有單個服務支持這麼大的量么？
大廠們是怎麼玩的？有什麼好的思路？

謝邀。5000W QPS 量確實比較大，在當前的架構下，就以開源的redis cluster為例，假設每個節點跑8W QPS，那麼也需要 5000/8 = 600+的節點，而Gossip在超過百級別節點的時候成本就越來越高，表現也越來越差了，所以用redis cluster來解這個問題不大靠譜，不靠譜的主要原因是Gossip的通信機制。

對於幾個大廠來說，阿里雲ApsaraDB for Redis/ApsaraCache用的是自研的集群方案（架構類似Codis），RedisLabs也是這個架構，AWS用的是開源的Redis Cluster，其他大廠就不清楚了。proxy+redis-server的架構可以做到線性的擴容，不用擔心節點間的通訊壓力，因為proxy做了分片，雖然也需要全局的Config Server/Zookeeper來維護數據分片信息，但是總體而言通信成本幾乎為0，所以這種架構撐5000W QPS理論上是沒有問題的。

這種架構還有一個優點就是可以把proxy當成一個中間件，在這個中間件上你可以做任何事情，比如可以把集群和主從的兼容性做到幾乎一致、可以做無縫擴縮容、安全策略等等，redis cluster因為缺少了這麼一個中間層就很難做這類事情（現在也有項目給redis cluster做一層proxy），當然因為帶了proxy，帶寬和CPU基本也是double的，對資源的消耗會大很多。

回到5000W這個問題上，理論上沒問題不代表實際沒問題，在幾百個節點的集群中，由於節點數變多，fail的幾率也大大變高；數據傾斜的問題也依然存在（訪問熱點導致的單個分片節點跑滿，比如秒殺）；而且由於redis跑滿時70-80%的cpu會消耗在內核網路棧上，所以當一個機器的CPU跑滿時，cpu system和softirq會居高不下，對主機的穩定性是個巨大的挑戰；另外對機房各個層次的交換機也會有巨大的挑戰；總而言之，服務的SLA是很難得到滿足的，為了保證SLA，可能需要上百台機器來部署幾百個分片以分擔5000W的壓力，這個成本也不是一般小廠能承擔的。而且節點數多的時候，對一些跨機指令是不友好的，比如mget，當節點數變多的時候會存在mget hole的問題，延遲與單節點相比會是原來的1/2次方倍，比如9個節點，mget的延遲就是原來的3倍，100個節點，延遲就是原來的10倍，懂概率的同學可以自己算一下。

那到底如何徹底解決5000W這個問題呢，這裡還是需要引入新技術的，比如智能網卡、用戶態tcp/ip協議棧、多線程redis（減少分片數量，兼容性依然100%），純用戶態協議棧可以做到單機600W QPS（64 core）左右，用intel iWARP這個值可能能達到1500W QPS左右（把7層網路棧都offload到網卡），這樣3-4台baremetal機器就能達到你說的要求；上層交換機也要用最新的機房建設標準，而且redis源碼本身也要做很多的適配和重構；產品形態也要做相應改進，比如我們為了支持熱key就做了讀寫分離這種產品形態。

以上就是我們正在做的事情，是不是很酷？如果你想參與可以私信我，我們期待你的加入，一起做最酷的事情。

褚霸 is watching me!! 只能說這麼多了。。。

一般會考慮先幹掉這個需求……

就算你有一千萬同時在線的用戶，還需要它們進行每秒鐘兩次寫入的高頻操作。那麼問題就來了，為什麼這個架構還在使用redis，有什麼數據是需要一千萬用戶共享的嗎……

理論上來說換成Cassandra，只要有個足夠大的集群就立即能解決問題了

瀉藥

不是打擊，5000w/s 是什麼水平大家心裡都有數，只能用震(hua)驚(ji)來形容。

5kw/s的量是怎麼估算出來的。

以100byte/request 計算每秒通信量高達5GB/s 。//這得什麼樣子得網路環境啊
如果沒有使用pipeline而是使用同步客戶端，跑到這個量得需要多少機器啊，如果你使用了pipeline，單個節點50w/s 應該是穩穩得。需要master應該沒有這麼多。
節點如何分布？上物理機的話，不可能。上虛擬機？怎麼保證服務質量。上公有雲？這個成本不科學。
2000w/s 如果開啟持久化可以說非常恐怖了，這個開銷存在與很多方面，最直觀得就是磁碟壓力和fork之後內存開銷。

如果真的寫入量這麼大，場景感覺也就幾個方向，很像是實時數據處理計算類的吧。

所以你得解釋一下為什麼會有這麼大的量了

數據總量是多少，是不是有非常集中的熱點數據，查詢能不能增加本地緩存層，從你的描述看很像是做存儲了，但是寫入量很大，猜測是統計數據。
第二個問題，業務架構是不是不合理，數據是不是應該本地處理更新定時同步等等方式，數據盡量本地處理，而不是來回同步。
你們公司都這麼大的量了，是不是可以考慮招個好點的架構師了，或者提升一下基礎組件的研究了~

首先你要考慮這麼大的qps要怎麼應對有限的網卡中斷，主流配置的伺服器每秒中斷數量大概在10W左右。

假設集群架構中有一層對等路由（proxy），那有效的中斷就是5W。

再假設每個query對路由的每一層只產生一次中斷，那麼大概需要1000台物理機才能解決中斷數量的問題。

單物理機處理5Wkps還是可以的，再加上一些打包查詢的優化，只要肯花錢還是能啃下來，接下來再去處理單機的bad case。

其實這裡還沒考慮網段打散的問題，如果考慮了，機器數量可能會double或者triple……

有答主提到proxy-server模式可以通過線性擴容來把機器堆上去，但是實踐當中，如果zookeeper用來做服務發現，會在遠小於這個規模的時候就發現各種問題。實踐上可以做，但通信成本並不為0……

吐槽：這麼大規模的問題，你應該招個專業的架構師來解決（逃

謝謝邀請。

如果是單純從技術角度來討論如何做到單集群5000W qps，那前面子嘉的回答就很好了。

但如果從實際生產的需求和業務角度出發，那這個問題可能會涉及很多隱含的要素，比如對應的數據量有多少？key的數量？用戶規模多大？業務單元有多少個？

在有了這些已知條件的情況下，考慮按業務和流程對數據進行分類，按用戶或ID屬性來定義key，基本上你的一個大的服務都可以拆分成N個小的服務，然後每個小服務對應一個redis cluster集群，其實也能達到同樣的效果。

比如我們的redis cluster集群數量大概600個左右，數據總量100T以上，redis總實例數上萬，單集群節點數最多的有200個左右，日訪問次數百億級，目前為止，在國內來說，應該是redis cluster應用規模最大的了。但是這麼多redis cluster集群的部署、在線擴容、管理、監控等又成了問題，需要有一個非常好用的自動化運維管理平台才可以勝任，不然得累死運維了。所以，要用好redis cluster，也還是有很多事情要做的。

假設每個請求100B, 5000萬QPS 就是 4.65GB/s 摺合約 37.25Gb/s, 如果每台機器都只用1個1000BaseT 這樣的方案, 單單符合帶寬就要約38台機器(這還沒考慮網卡中斷). 如果每個請求達到1K, 將會是372.5Gb/s 這樣恐怖的流量.

自底向上思考的話:

物理層

首先至少要有交換容量400Gb以上的交換機. 其次如果單實例優化的好或者採用虛擬化方案, 物理機應配備10G, 40G乙太網Infiniband方案. 網卡支持SR-IOV, 多隊列.

操作系統, 驅動

網卡應該搭配DPDK類似的方案使用, 儘可能繞過kernel. 可以考慮 dpdk-redis 這樣的通信方案.

持久化

看數據多少, 如果只是抗QPS, 本身數據規模不大而且更新不要求實時性, 就沒必要用Redis. 直接數據硬編碼到程序里. 如果是通用Redis. 到這個程度就只能自己魔改了... 說實話我倒是覺得這樣不如直接上帶電池的內存, 不失為一種方案.

高可用

高可用看你喜歡CAP哪個. 這麼大QPS了本身是一定要Availability的. 那麼最終得到的就是一個要麼極限腦裂, 要麼瘋狂丟數據的東西. 其實可以只要A的, CP全不要. 這樣性能還能爆炸.

我總覺得這是釣魚貼. （逃

問題主可以試下「map and reduce」這個原則來處理。

任何存儲方案對於你的問題都是瓶頸了，那麼就應該要換一種思路了而不是頭痛醫頭腳痛醫腳。

先確定是不是邏輯不合理，把簡單的事寫複雜了，寫1次或者幾次其實就能搞定的業務邏輯因為代碼屎被搞成了寫幾十上百次這種事見過不少了，不要不想著優化代碼/演算法，只知道砸機器。

另外考慮到現在是年底，有可能是SB老闆在拍KPI，這種你看看就行了，完全無腦拍我們明年QPS多少多少千萬的SB我也見過，你信你就輸了。

Codis可以嘗試一下！

貴司的體量令人嘆服！

5000W的QPS，想Redis這種單線程的弱雞資料庫，是無法滿足題主的需求的

@郭忠明老師的組件烏魯木齊雲山雲海信息技術有限責任公司或許可以幫到你

請問那個大廠有5000w的qps？

兄弟你不能這麼張嘴就來啊

5000w？當你們雙11的淘寶呢？手動滑稽。

你是單key 5000萬qps嗎

這個問題意義不大，沒這麼大量，大廠都是重寫redis，自己定製，皮這一下開心了沒。

樓上說的很多了，補充一點，5000萬qps，震精了，我覺得，業務一定存在優化的空間，而且，還不少，非常好奇到底是什麼業務，5000萬是怎麼評估出來的

這需求超越BAT了，確定不是拍腦袋好玩？

難以想像有這種需求的公司跑到知乎上要答案……

redis單實例一般輕鬆支持到20萬qps，讀寫並沒有區別。而且redis單線程的，按照一般伺服器8核或者16核，那單伺服器qps就應該上百萬了吧。另外業務怎樣？不能用pipeline嗎？那qps至少可以再乘5。性能調優的時候注意每次請求數據大小，超過網路包大小性能會急劇下降。

其實整個系統最關鍵的是你每次請求的數據大小，如果太大很容易塞滿網路，你確定機房網路環境滿足了你的帶寬？

還有預計使用的內存大小，如果太大的話，又要持久化，一次重啟就得花幾十分鐘甚至一小時。

你這種沒法使用cluster，建議按key分片，master slave + sentinel

最最關鍵的，不說什麼業務動不動就5kw qps，你這不是耍流氓么？

前端入口做負載均衡，後端多搭幾個集群，總脫不了這個圈。另外這種不帶具體業務場景的提問純屬瞎扯

一個實例一個月6千，1600實例一年要1.15億。我覺得你們廠也很大的。