5000萬QPS太大了。

1.你應先分析一下自己的業務場景，一般來說，這麼大的場景有可能是你對redis的用法有問題，導致qps太低了，當然一些網際網路頭部公司已經過了5000萬了，但他們也不需要來問了，他們已經有應對的方案了。

2.redis裡面的資料結構是比較多的，5000W qps只是個請求量，與你使用的業務是相關的，有的業務還不支援叢集分佈，這就需要從設計層面去解決，從redis層面是解決不了的。

3.還有一個是網路流量的問題，5000萬的QPS，基實網路流量也是一個天量，需要同步考慮主機效能，叢集交換機承載能力，對外提供服務的出口流量。

4.如果不管其它問題，就當成是簡單的kv讀寫，且讀取量遠大於寫入量（常見的業務形態），那麼可以使用redis的自身叢集功能，由於redis是單執行緒，所以一般可以一臺物理機同時開3-5個redis應用例項。比承載富餘來看，單機跑到5萬-10萬QPS已經到頂了，至少需要500臺機器，這個叢集已經很大了，國內除去網際網路頭部公司，估計誰也沒有這麼大的叢集了。

5.再向外一看，還有網路延時決定了處理能力，單機記憶體決定了資料儲存量。

單例項帶業務實戰經驗一般10萬ops左右，一臺48核心伺服器安裝48個Redis例項，整體吞吐最高超過30萬ops，網絡卡超過600Mbps，這是帶業務例項跑。如果是壓力測試，單機32例項，最高220萬ops，業務會帶有不同複雜操作，很難上去百萬。但是，最近一年我們研究發現，多用mget替代get，多用管道，帶業務場景，實質上業務次數超過了100萬tps每機器。

最後，你需要5000萬qps，估計需要200臺48C256G的Redis伺服器。如果90%操作能夠批次進行且使用萬兆網路再，再把程式最佳化好一點，8+8主備架構足夠了！

如果 有面試問你這個問題，薪資待遇先要個200萬一年 其他期權分紅再說。這種有思路要麼堆機器，要麼還是堆機器。