分佈式緩存集羣方案特性使用場景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）優缺點對比及選型

分佈式緩存集羣方案特性使用場景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）優缺點對比及選型

 

分佈式緩存特性：

1) 高性能:當傳統數據庫面臨大規模數據訪問時,磁盤I/O 每每成爲性能瓶頸,從而致使太高的響應延遲.分佈式緩存將高速內存做爲數據對象的存儲介質,數據以key/value 形式存儲,理想狀況下能夠得到DRAM 級的讀寫性能;
2) 動態擴展性:支持彈性擴展,經過動態增長或減小節點應對變化的數據訪問負載,提供可預測的性能與擴展性;同時,最大限度地提升資源利用率;
3) 高可用性:可用性包含數據可用性與服務可用性兩方面.基於冗餘機制實現高可用性,無單點失效(single point of failure),支持故障的自動發現,透明地實施故障切換,不會因服務器故障而致使緩存服務中斷或數據丟失.動態擴展時自動均衡數據分區,同時保障緩存服務持續可用;
4) 易用性:提供單一的數據與管理視圖;API 接口簡單,且與拓撲結構無關;動態擴展或失效恢復時無需人工配置;自動選取備份節點;多數緩存系統提供了圖形化的管理控制檯,便於統一維護;
5) 分佈式代碼執行(distributed code execution):將任務代碼轉移到各數據節點並行執行,客戶端聚合返回結果,從而有效避免了緩存數據的移動與傳輸.最新的Java 數據網格規範JSR-347中加入了分佈式代碼執行與Map/reduce 的API 支持,各主流分佈式緩存產品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支持這一新的編程模型.

 

 

分佈式緩存應用場景：

1) 頁面緩存.用來緩存Web 頁面的內容片斷,包括HTML、CSS 和圖片等,多應用於社交網站等;
2) 應用對象緩存.緩存系統做爲ORM 框架的二級緩存對外提供服務,目的是減輕數據庫的負載壓力,加速應用訪問;
3) 狀態緩存.緩存包括Session 會話狀態及應用橫向擴展時的狀態數據等,這類數據通常是難以恢復的,對可用性要求較高,多應用於高可用集羣;（解決分佈式Web部署的session同步問題）
4) 並行處理.一般涉及大量中間計算結果須要共享;
5) 事件處理.分佈式緩存提供了針對事件流的連續查詢(continuous query)處理技術,知足實時性需求;
6) 極限事務處理.分佈式緩存爲事務型應用提供高吞吐率、低延時的解決方案,支持高併發事務請求處理,多應用於鐵路、金融服務和電信等領域.

7）雲計算領域提供分佈式緩存服務（例如：青雲、 

UnitedStack等）

6） 

任何須要用到緩存的地方，解決本地緩存數據量過小問題。分佈式緩存能有效防止本地緩存失效數據庫雪崩現象。

 

 

 

兩大開源緩存系統對比，Memcache VS Redis：

一、Redis不只僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。而memcache只支持簡單數據類型，須要客戶端本身處理複雜對象

二、Redis支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候能夠再次加載進行使用（PS：持久化在rdb、aof）。Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，而後在子進程中循環全部的數據，將數據寫成爲RDB文件。  AOF日誌的全稱是append only file，從名字上咱們就能看出來，它是一個追加寫入的日誌文件。與通常數據庫的binlog不一樣的是，AOF文件是可識別的純文本，它的內容就是一個個 的Redis標準命令。固然，並非發送發Redis的全部命令都要記錄到AOF日誌裏面，只有那些會致使數據發生修改的命令纔會追加到AOF文件。那麼每一條修改數據的命令都生成一條日誌。（PS：memcache不支持數據持久存儲）

三、因爲Memcache沒有持久化機制，所以宕機全部緩存數據失效。Redis配置爲持久化，宕機重啓後，將自動加載宕機時刻的數據到緩存系統中。具備更好的災備機制。

四、Memcache可使用Magent在客戶端進行一致性hash作分佈式。Redis支持在服務器端作分佈式（PS:Twemproxy/Codis/Redis-cluster多種分佈式實現方式）

五、Memcached的簡單限制就是鍵（key）和Value的限制。最大鍵長爲250個字符。能夠接受的儲存數據不能超過1MB（可修改配置文件變大），由於這是典型slab 的最大值，不適合虛擬機使用。而Redis的Key長度支持到512k。

六、Redis使用的是單線程模型，保證了數據按順序提交。Memcache須要使用cas保證數據一致性。CAS（Check and Set）是一個確保併發一致性的機制，屬於「樂觀鎖」範疇；原理很簡單：拿版本號，操做，對比版本號，若是一致就操做，不一致就放棄任何操做

cpu利用。因爲Redis只使用單核，而Memcached可使用多核，因此平均每個核上Redis在存儲小數據時比Memcached性能更 高。而在100k以上的數據中，Memcached性能要高於Redis 。（PS：Redis能夠經過開啓多個實例來提升CPU利用率，Memcache默認是單線程，須要編譯指定參數才能支持多線程。因爲分佈式緩存是IO密集型系統，因此性能不少程度受限於網絡通訊，memcache使用了libevent網絡庫，redis本身實現了一套本身通訊的庫。線程也不是影響吞吐量的重要因素。如第一點來講，通常狀況下，程序處理內存數據的速度遠高於網卡接收的速度。使用線程好處是能夠同時處理多條鏈接，在極端狀況下，可能會提升響應速度。可是單線程有時候比多線程 或多進程更快，比須要考慮併發、鎖，也不會增長上下文切換等開銷，也即代碼更加簡潔，執行效率更高。）

七、memcache內存管理：使用Slab Allocation。原理至關簡單，預先分配一系列大小固定的組，而後根據數據大小選擇最合適的塊存儲。避免了內存碎片。（缺點：不能變長，浪費了必定空間）memcached默認狀況下下一個slab的最大值爲前一個的1.25倍。八、redis內存管理： Redis經過定義一個數組來記錄全部的內存分配狀況， Redis採用的是包裝的malloc/free，相較於Memcached的內存 管理方法來講，要簡單不少。因爲malloc 首先以鏈表的方式搜索已管理的內存中可用的空間分配，致使內存碎片比較多。

 

總結：

其實對於企業選型Memcache、Redis而言，更多仍是應該看業務使用場景（由於Memcache、Redis二者都具備足夠高的性能和穩定性）。倘若業務場景須要用到持久化緩存功能、或者支持多種數據結構的緩存功能，那麼Redis則是最佳選擇。

（PS：Redis集羣解決方式也優於Memcache，Memcache在客戶端一致性hash的集羣解決方案，Redis採用無中心的服務器端集羣解決方案）

綜上所述：爲了讓緩存系統可以支持更多的業務場景，選擇Redis會更優。（目前也愈來愈多的廠商選擇Redis）。

 

 

接下來重點對比Redis三大集羣解決方案對比，Twemproxy VS Codis VS Redis-cluster

Redis集羣三種常見的解決方案：

一、客戶端分片：這種方案將分片工做放在業務程序端，程序代碼根據預先設置的路由規則，直接對多個Redis實例進行分佈式訪問。這樣的好處是，不依賴於第三方分佈式中間件，實現方法和代碼都本身掌控，可隨時調整，不用擔憂踩到坑。這其實是一種靜態分片技術。Redis實例的增減，都得手工調整分片程序。基於此分片機制的開源產品，如今仍很少見。這種分片機制的性能比代理式更好（少了一箇中間分發環節）。但缺點是升級麻煩，對研發人員的我的依賴性強——須要有較強的程序開發能力作後盾。若是主力程序員離職，可能新的負責人，會選擇重寫一遍。因此，這種方式下，可運維性較差。出現故障，定位和解決都得研發和運維配合着解決，故障時間變長。所以這種方案，難以進行標準化運維，不太適合中小公司（除非有足夠的DevOPS）。

二、代理 分片：這種方案，將分片工做交給專門的代理程序來作。代理程序接收到來自業務程序的數據請求，根據路由規則，將這些請求分發給正確的Redis實例並返回給業務程序。這種機制下，通常會選用第三方代理程序（而不是本身研發），由於後端有多個Redis實例，因此這類程序又稱爲分佈式中間件。這樣的好處是，業務程序不用關心後端Redis實例，運維起來也方便。雖然會所以帶來些性能損耗，但對於Redis這種內存讀寫型應用，相對而言是能容忍的。這是咱們推薦的集羣實現方案。像基於該機制的開源產品Twemproxy，Codis即是其中表明，應用很是普遍。

三、服務器端分片：創建在基於無中心分佈式架構之上（沒有代理節點性能瓶頸問題）。Redis-Cluster即爲官方基於該架構的解決方案。Redis Cluster將全部Key映射到16384個Slot中，集羣中每一個Redis實例負責一部分，業務程序經過集成的Redis Cluster客戶端進行操做。客戶端能夠向任一實例發出請求，若是所需數據不在該實例中，則該實例引導客戶端自動去對應實例讀寫數據。Redis Cluster的成員管理（節點名稱、IP、端口、狀態、角色）等，都經過節點之間兩兩通信，按期交換並更新。

 

接下來分別講解各解決方案表明產品實現方式優缺點：

Twemproxy：

Twemproxy是一種代理分片機制，由Twitter開源。Twemproxy做爲代理，可接受來自多個程序的訪問，按照路由規則，轉發給後臺的各個Redis服務器，再原路返回。這個方案瓜熟蒂落地解決了單個Redis實例承載能力的問題。固然，Twemproxy自己也是單點，須要用Keepalived作高可用方案。這麼些年來，Twemproxy是應用範圍最廣、穩定性最高、最久經考驗的分佈式中間件。只是，他還有諸多不方便之處。Twemproxy最大的痛點在於，沒法平滑地擴容/縮容。這樣增長了運維難度：業務量突增，需增長Redis服務器；業務量萎縮，須要減小Redis服務器。但對Twemproxy而言，基本上都很難操做。或者說，Twemproxy更加像服務器端靜態sharding。有時爲了規避業務量突增致使的擴容需求，甚至被迫新開一個基於Twemproxy的Redis集羣。Twemproxy另外一個痛點是，運維不友好，甚至沒有控制面板。

 

Codis：

Codis由豌豆莢於2014年11月開源，基於Go和C開發，是近期涌現的、國人開發的優秀開源軟件之一。現已普遍用於豌豆莢的各類Redis業務場景，從各類壓力測試來看，穩定性符合高效運維的要求。性能更是改善不少，最初比Twemproxy慢20%；如今比Twemproxy快近100%（條件：多實例，通常Value長度）。Codis具備可視化運維管理界面。Codis無疑是爲解決Twemproxy缺點而出的新解決方案。所以綜合方面會因爲Twemproxy不少。目前也愈來愈多公司選擇Codis。Codis引入了Group的概念，每一個Group包括1個Redis Master及至少1個Redis Slave，這是和Twemproxy的區別之一。這樣作的好處是，若是當前Master有問題，則運維人員可經過Dashboard「自助式」切換到Slave，而不須要當心翼翼地修改程序配置文件。爲支持數據熱遷移（Auto Rebalance），出品方修改了Redis Server源碼，並稱之爲Codis Server。Codis採用預先分片（Pre-Sharding）機制，事先規定好了，分紅1024個slots（也就是說，最多能支持後端1024個Codis Server），這些路由信息保存在ZooKeeper中。

 

Redis-cluster：

reids-cluster在redis3.0中推出，支持Redis分佈式集羣部署模式。採用無中心分佈式架構。全部的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.節點的fail是經過集羣中超過半數的節點檢測失效時才生效.客戶端與redis節點直連,不須要中間proxy層.客戶端不須要鏈接集羣全部節點,鏈接集羣中任何一個可用節點便可，減小了代理層，大大提升了性能。redis-cluster把全部的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->key之間的關係。目前Jedis已經支持Redis-cluster。從計算架構或者性能方面無疑Redis-cluster是最佳的選擇方案。（PS：雖然Redis-cluster從方案選型上面比較佔據優點，可是因爲Redis-cluster剛推出不久，雖然官方宣傳已經發布的是文檔版本，但穩定性方面還有待驗證）