1. 程式人生 > >沉浸於此,成體系,求自由

沉浸於此,成體系,求自由

         分片是分散式儲存的突出特點。

必要性

         如果Redis叢集的每個資料庫都儲存叢集中的所有資料,那麼叢集的總資料儲存量受限於可用儲存記憶體最小的資料庫節點,形成木桶效應。由於Redis中的所有資料都基於記憶體儲存,這一問題就尤為突出了,尤其是當使用Redis做持久化儲存服務時。從容量上,單個Redis伺服器的記憶體非常容易成為儲存瓶頸,所以需要進行資料分片。

舊版本Redis的解決辦法

         舊版本Redis(2.4)沒有提供叢集的功能。

         通常使用客戶端分片來解決這個問題,即啟動多個Redis資料庫節點,由客戶端決定每個鍵交由哪個資料庫節點儲存,下次客戶端讀取該鍵時直接到該節點讀取。這樣可以實現將整個資料分佈儲存在N個數據庫節點中,每個節點只存放總資料量的1/N。但對於需要擴容的場景來說,在客戶端分片後,如果想增加更多的節點,就需要對資料進行手工遷移,同時在遷移的過程中為了保證資料的一致性,還需要將叢集暫時下線。這個過程相對比較複雜。

         考慮到Redis例項非常輕量特點,可以採用預分片技術(presharding)來在一定程度上避免此問題。具體來說就是在節點部署初期,就提前考慮日後的儲存規模,建立足夠多的例項(如128個節點),初期資料很少,所以每個節點儲存的資料也非常少,但由於節點輕量的特性,資料之外的記憶體開銷並不大,這使得只需要很少的伺服器即可執行這些例項。日後儲存規模擴大後,所要做的不過是將某些例項遷移到其他伺服器上,而不需要對所有資料進行重新分片並進行叢集下線和資料遷移了。

         總之,客戶端分片終歸是有非常多的缺點,比如維護成本高,增加、移除節點較繁煩等。

新版本Redis的解決辦法

         Redis3.0版的一大特性就是支援叢集(Cluster)功能。

         Redis叢集是自動分片和高可用的首選方式。當前還不能完全用於生產環境,但是已經進入了beta階段。  一旦Redis叢集可用,以及支援Redis叢集的客戶端可用,Redis叢集將會成為Redis分片的事實標準。

         叢集的特點在於擁有和單機例項同樣的功能,同時在網路分割槽後能夠提供一定的可訪問性以及對主資料庫故障恢復的支援。

          Redis叢集是查詢路由和客戶端分片的混合模式。