站長資訊網本篇文章給大家帶來了關于Redis的相關知識，其中主要介紹了集群的相關問題，Redis集群是一種分布式數據庫方案，集群通過分片來進行數據共享，并提供復制和故障轉移功能，希望對大家有幫助。
推薦學習：Redis學習教程
幾種 Redis 高可用性的解決方案。包括：「主從模式」、「哨兵機制」以及「哨兵集群」。
- 「主從模式」具有讀寫分離，分擔讀壓力、數據備份，提供多個副本等優點。
- 「哨兵機制」在主節點故障后能自動將從節點提升成主節點，不需要人工干預操作就能恢復服務可用。
- 「哨兵集群」解決單點故障以及單機哨兵產生「誤判」問題。
Redis 從最簡單的單機版，經過數據持久化、主從多副本、哨兵集群，通過這么一番的優化，不管是性能還是穩定性，都越來越高。
但是隨著時間的發展，公司業務體量迎來了爆炸性增長，此時的架構模型，還能夠承擔這么大的流量嗎？
比如有這么一個需求：要用 Redis 保存 5000 萬個鍵值對，每個鍵值對大約是 512B，為了能快速部署并對外提供服務，我們采用云主機來運行 Redis 實例，那么，該如何選擇云主機的內存容量呢？
通過計算，這些鍵值對所占的內存空間大約是 25GB（5000 萬 *512B）。
想到的第一個方案就是：選擇一臺 32GB 內存的云主機來部署 Redis。因為 32GB 的內存能保存所有數據，而且還留有 7GB，可以保證系統的正常運行。
同時，還采用 RDB 對數據做持久化，以確保 Redis 實例故障后，還能從 RDB 恢復數據。
但是，在使用的過程中會發現，Redis 的響應有時會非常慢。通過 INFO命令 查看 Redis 的latest_fork_usec指標值（表示最近一次 fork 的耗時），結果發現這個指標值特別高。
這跟 Redis 的持久化機制有關系。
在使用 RDB 進行持久化時，Redis 會 fork 子進程來完成，fork 操作的用時和 Redis 的數據量是正相關的，而 fork 在執行時會阻塞主線程。數據量越大，fork 操作造成的主線程阻塞的時間越長。
所以，在使用 RDB 對 25GB 的數據進行持久化時，數據量較大，后臺運行的子進程在 fork 創建時阻塞了主線程，于是就導致 Redis 響應變慢了。
顯然這個方案是不可行的，我們必須要尋找其他的方案。
