本篇文章給大家?guī)砹岁P于Redis的相關知識，其中主要介紹了集群的相關問題，Redis集群是一種分布式數(shù)據(jù)庫方案，集群通過分片來進行數(shù)據(jù)共享，并提供復制和故障轉(zhuǎn)移功能，希望對大家有幫助。

推薦學習：Redis學習教程

幾種 Redis 高可用性的解決方案。包括：「主從模式」、「哨兵機制」以及「哨兵集群」。

• 「主從模式」具有讀寫分離，分擔讀壓力、數(shù)據(jù)備份，提供多個副本等優(yōu)點。
• 「哨兵機制」在主節(jié)點故障后能自動將從節(jié)點提升成主節(jié)點，不需要人工干預操作就能恢復服務可用。
• 「哨兵集群」解決單點故障以及單機哨兵產(chǎn)生「誤判」問題。

Redis 從最簡單的單機版，經(jīng)過數(shù)據(jù)持久化、主從多副本、哨兵集群，通過這么一番的優(yōu)化，不管是性能還是穩(wěn)定性，都越來越高。

但是隨著時間的發(fā)展，公司業(yè)務體量迎來了爆炸性增長，此時的架構(gòu)模型，還能夠承擔這么大的流量嗎？

比如有這么一個需求：要用 Redis 保存 5000 萬個鍵值對，每個鍵值對大約是 512B，為了能快速部署并對外提供服務，我們采用云主機來運行 Redis 實例，那么，該如何選擇云主機的內(nèi)存容量呢？

通過計算，這些鍵值對所占的內(nèi)存空間大約是 25GB（5000 萬 *512B）。

想到的第一個方案就是：選擇一臺 32GB 內(nèi)存的云主機來部署 Redis。因為 32GB 的內(nèi)存能保存所有數(shù)據(jù)，而且還留有 7GB，可以保證系統(tǒng)的正常運行。

同時，還采用 RDB 對數(shù)據(jù)做持久化，以確保 Redis 實例故障后，還能從 RDB 恢復數(shù)據(jù)。

但是，在使用的過程中會發(fā)現(xiàn)，Redis 的響應有時會非常慢。通過 INFO命令 查看 Redis 的latest_fork_usec指標值（表示最近一次 fork 的耗時），結(jié)果發(fā)現(xiàn)這個指標值特別高。

這跟 Redis 的持久化機制有關系。

在使用 RDB 進行持久化時，Redis 會 fork 子進程來完成，fork 操作的用時和 Redis 的數(shù)據(jù)量是正相關的，而 fork 在執(zhí)行時會阻塞主線程。數(shù)據(jù)量越大，fork 操作造成的主線程阻塞的時間越長。

所以，在使用 RDB 對 25GB 的數(shù)據(jù)進行持久化時，數(shù)據(jù)量較大，后臺運行的子進程在 fork 創(chuàng)建時阻塞了主線程，于是就導致 Redis 響應變慢了。

顯然這個方案是不可行的，我們必須要尋找其他的方案。

如何保存