Redis叢集方案的對比
Redis叢集方案
長期以來，Redis本身僅支援單例項，記憶體一般最多10~20GB。這無法支撐大型線上業務系統的需求。而且也造成資源的利用率過低，畢竟現在伺服器記憶體動輒100~200GB。
為解決單機承載能力不足的問題，出現了不少叢集方案，物理上把資料“分片”儲存在多個Redis例項。（一般情況下，每一片對應一個Redis例項）
其中最主要有下面兩種方式：
l Redis官方近期推出的Redis Cluster，通過節點之間兩兩通訊來實現成員管理，去中心化。
l 代理分片：通過第三方代理程式來管理後端多個Redis分片，根據路由規則，將這些請求分發給正確的Redis例項並返回給業務程式。其中Twemproxy就是這種第三方代理的代表之一。
---------------------Twemproxy + Redis VS RedisCluster---------------------
Twemproxy + Redis分片
Redis單例項“簡單、可依賴”但是承載能力不足，Twemproxy代理Redis分片恰恰彌補了這個缺陷。而且這些年來，應用範圍廣、穩定性高、技術也比較成熟。
不過其缺點也不可忽視：
Twemproxy最大的痛點在於，無法平滑地擴容/縮容。Twemproxy更加像伺服器端靜態sharding，有時為了規避業務量突增導致的擴容需求，甚至被迫新開一個基於Twemproxy的Redis叢集。
另外，Twemproxy本身也是單點，需要用Keepalived做高可用方案，再加上lvs負載均衡等元件，導致架構複雜，維護管理成本高。而且層次負載增加了問題定位排查的成本。
Redis Cluster
官方推出的Redis叢集解決方案，通過Redis節點之間兩兩通訊，定期交換並更新，來實現成員管理（節點名稱、IP、埠、狀態、角色）。在這種機制下，沒有中心節點（和代理模式的重要不同之處）。客戶端可以向任一例項發出請求，如果所需資料不在該例項中，則該例項引導客戶端自動去對應例項讀寫資料。
而且解決了Twemproxy不能線上擴容的問題，支援HA，架構簡單，更便於擴充套件和維護。
當然也會帶來不足的地方：
l 加重Redis例項，已經不是“簡單、可依賴”了。
l 對資料的批量讀寫效能不是很好。根本原因在於資料存在不同的分片，其次客戶端驅動的支援目前不是很完善。（如pipeline 和 multi key等操作）
l 線上擴容和資料resharding需要自動化工具支援，rediscluster目前不能智慧的實現auto resharding。
l 不能構建跨機房的只讀叢集。（twemproxy可以通過複製實現）
-----------相關閱讀----------------------------------------------------------------------------------------
Twemproxy
twemproxy(也叫nutcraker)，是twitter開源的一個redis和memcache代理伺服器，來統一管理多個redis。 （簡介見http://cloudaice.com/twemproxy-explore/）
LVS
LVS是LinuxVirtual Server的簡寫，即Linux虛擬伺服器，是一個虛擬的伺服器集群系統。
LVS叢集採用IP負載均衡技術和基於內容請求分發技術。排程器具有很好的吞吐率，將請求均衡地轉移到不同的伺服器上執行，且排程器自動遮蔽掉伺服器的故障，從而將一組伺服器構成一個高效能的、高可用的虛擬伺服器。
一般來說，LVS叢集採用三層結構，其主要組成部分為：
A. 負載排程器（loadbalancer），它是整個叢集對外面的前端機-排程器，負責將客戶的請求傳送到一組伺服器上執行，看起來是來自一個IP地址（可稱之為虛擬IP地址）。
B. 伺服器池（server pool），是一組真正執行客戶請求的伺服器，執行的服務有WEB、MAIL、FTP和DNS等。
C. 共享儲存（sharedstorage），它為伺服器池提供一個共享的儲存區，這樣很容易使得伺服器池擁有相同的內容，提供相同的服務。【共享儲存通常是資料庫、網路檔案系統或者分散式檔案系統。】
對大多數網路服務來說，請求間不存在很強的相關性，請求可以在不同的結點上並行執行，所以整個系統的效能基本上可以隨著伺服器池的結點數目增加而線性增長。