Redis服務支持5000萬的QPS？

雖然知道你問這個問題的時候，其實自己并沒有想的太清楚，但是為了漲粉，我還是愿意來評論一下。

我想對redis來說，單機qps 5000w暫時肯定是不能的事情了，所以需要分布式集群來解決這個問題。

但是現實中的分布式方案，其實都是在各種現有條件下的權衡結果，我想現實中5000wqps的應用可能主要會有以下場景。

1.純讀場景(存儲量單機可存儲)

對于純讀場景，其實是離線寫 + 在線讀的模式，單純的加機器就可以完成你的需求。

單機我記得10w沒問題，那你可能需要500臺機器，如果你是多idc，那么N + 1冗余考慮到的話，可能實際會多點。

技術方案： 采用 1主 N從即可

優劣點： 線性擴展，沒有啥優劣點，平行分割流量

常見場景： 你的業務只存儲天氣信息，流量大，但是存儲量小！

2.純讀場景(存儲量單機無法存儲) or 讀寫流量都很大

這種場景相對于上面的場景就復雜起來了，因為單機已經無法存儲全部數據，你同時需要考慮存儲擴展和流量分割。所以流量達到實例之前是需要hash的，因為你每個實例已經裝不下全部數據，需要多個示例共同承擔這個任務。

這種情況下常見的是兩種方案：

2.1 客戶端hash

客戶端hash，就是由客戶端選擇最終請求落到哪個實例上，這樣流量和存儲的擴展就解決了。

但是這種問題在于，當增刪機器的時候，客戶端涉及到hash策略更新，如何保證這兩動作之間不會產生臟請求？這是個問題。

2.2 增加代理層

代理層的位于client和server之間，當然重要作用仍然是扮演實例選擇的作用，這點上與客戶端一致。

請求路徑由原來的直接請求變成了 client => proxy => redis。

我也存在這個問題，他如何解決動態擴縮容的問題的？

我也沒找到答案，如果你知道可以告訴我，但是就我的理解、

對于擴容而言，只需要實例服務起來之后，開放入口即可。

對于縮容而言，首先是proxy控制寫分發到其他實例，然后把縮容機器數據按照新的寫策略重新分布，

然后寫路由也改成最新的，下掉機器即可。

多idc方案，目前我們采用的是一idc主，多idc從，保持最終一致。

優勢： 容量&流量線性擴展，動態擴縮容

劣勢： 1.proxy 性能損耗

2.語法不再如原生的靈活

3.多idc set不保證完全的回話一致。寫操作，對于從idc來說，永遠是跨機房的。

歡迎批評指正！