Memcache及Redis分布式緩存集群方案特性使用場(chǎng)景優(yōu)缺點(diǎn)對(duì)比及選型是怎么樣的

Memcache及Redis分布式緩存集群方案特性使用場(chǎng)景優(yōu)缺點(diǎn)對(duì)比及選型是怎么樣的，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

分布式緩存集群方案特性使用場(chǎng)景優(yōu)缺點(diǎn)對(duì)比及選型

分布式緩存特性：

1) 高性能:當(dāng)傳統(tǒng)數(shù)據(jù)庫面臨大規(guī)模數(shù)據(jù)訪問時(shí),磁盤I/O 往往成為性能瓶頸,從而導(dǎo)致過高的響應(yīng)延遲.分布式緩存將高速內(nèi)存作為數(shù)據(jù)對(duì)象的存儲(chǔ)介質(zhì),數(shù)據(jù)以key/value 形式存儲(chǔ),理想情況下可以獲得DRAM 級(jí)的讀寫性能;
2) 動(dòng)態(tài)擴(kuò)展性:支持彈性擴(kuò)展,通過動(dòng)態(tài)增加或減少節(jié)點(diǎn)應(yīng)對(duì)變化的數(shù)據(jù)訪問負(fù)載,提供可預(yù)測(cè)的性能與擴(kuò)展性;同時(shí),最大限度地提高資源利用率;
3) 高可用性:可用性包含數(shù)據(jù)可用性與服務(wù)可用性兩方面.基于冗余機(jī)制實(shí)現(xiàn)高可用性,無單點(diǎn)失效(single point of failure),支持故障的自動(dòng)發(fā)現(xiàn),透明地實(shí)施故障切換,不會(huì)因服務(wù)器故障而導(dǎo)致緩存服務(wù)中斷或數(shù)據(jù)丟失.動(dòng)態(tài)擴(kuò)展時(shí)自動(dòng)均衡數(shù)據(jù)分區(qū),同時(shí)保障緩存服務(wù)持續(xù)可用;
4) 易用性:提供單一的數(shù)據(jù)與管理視圖;API 接口簡(jiǎn)單,且與拓?fù)浣Y(jié)構(gòu)無關(guān);動(dòng)態(tài)擴(kuò)展或失效恢復(fù)時(shí)無需人工配置;自動(dòng)選取備份節(jié)點(diǎn);多數(shù)緩存系統(tǒng)提供了圖形化的管理控制臺(tái),便于統(tǒng)一維護(hù);
5) 分布式代碼執(zhí)行(distributed code execution):將任務(wù)代碼轉(zhuǎn)移到各數(shù)據(jù)節(jié)點(diǎn)并行執(zhí)行,客戶端聚合返回結(jié)果,從而有效避免了緩存數(shù)據(jù)的移動(dòng)與傳輸.最新的Java 數(shù)據(jù)網(wǎng)格規(guī)范JSR-347中加入了分布式代碼執(zhí)行與Map/reduce 的API 支持,各主流分布式緩存產(chǎn)品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支持這一新的編程模型.

分布式緩存應(yīng)用場(chǎng)景：

1) 頁面緩存.用來緩存Web 頁面的內(nèi)容片段,包括HTML、CSS 和圖片等,多應(yīng)用于社交網(wǎng)站等;
2) 應(yīng)用對(duì)象緩存.緩存系統(tǒng)作為ORM 框架的二級(jí)緩存對(duì)外提供服務(wù),目的是減輕數(shù)據(jù)庫的負(fù)載壓力,加速應(yīng)用訪問;
3) 狀態(tài)緩存.緩存包括Session 會(huì)話狀態(tài)及應(yīng)用橫向擴(kuò)展時(shí)的狀態(tài)數(shù)據(jù)等,這類數(shù)據(jù)一般是難以恢復(fù)的,對(duì)可用性要求較高,多應(yīng)用于高可用集群;（解決分布式Web部署的session同步問題）
4) 并行處理.通常涉及大量中間計(jì)算結(jié)果需要共享;
5) 事件處理.分布式緩存提供了針對(duì)事件流的連續(xù)查詢(continuous query)處理技術(shù),滿足實(shí)時(shí)性需求;
6) 極限事務(wù)處理.分布式緩存為事務(wù)型應(yīng)用提供高吞吐率、低延時(shí)的解決方案,支持高并發(fā)事務(wù)請(qǐng)求處理,多應(yīng)用于鐵路、金融服務(wù)和電信等領(lǐng)域.
 

7）云計(jì)算領(lǐng)域提供分布式緩存服務(wù)（例如：青云、

UnitedStack等）

6）

任何需要用到緩存的地方，解決本地緩存數(shù)據(jù)量太小問題。分布式緩存能有效防止本地緩存失效數(shù)據(jù)庫雪崩現(xiàn)象。

兩大開源緩存系統(tǒng)對(duì)比， Memcache VS Redis：

1、Redis不僅僅支持簡(jiǎn)單的k/v類型的數(shù)據(jù)，同時(shí)還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。而 memcache只支持簡(jiǎn)單數(shù)據(jù)類型，需要客戶端自己處理復(fù)雜對(duì)象

2、Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用（PS：持久化在rdb、aof）。Redis借助了fork命令的copy on write機(jī)制。在生成快照時(shí)，將當(dāng)前進(jìn)程fork出一個(gè)子進(jìn)程，然后在子進(jìn)程中循環(huán)所有的數(shù)據(jù)，將數(shù)據(jù)寫成為RDB文件。  AOF日志的全稱是append only file，從名字上我們就能看出來，它是一個(gè)追加寫入的日志文件。與一般數(shù)據(jù)庫的binlog不同的是，AOF文件是可識(shí)別的純文本，它的內(nèi)容就是一個(gè)個(gè) 的Redis標(biāo)準(zhǔn)命令。當(dāng)然，并不是發(fā)送發(fā)Redis的所有命令都要記錄到AOF日志里面，只有那些會(huì)導(dǎo)致數(shù)據(jù)發(fā)生修改的命令才會(huì)追加到AOF文件。那么每一條修改數(shù)據(jù)的命令都生成一條日志。（PS：memcache不支持?jǐn)?shù)據(jù)持久存儲(chǔ)）

3、由于Memcache沒有持久化機(jī)制，因此宕機(jī)所有緩存數(shù)據(jù)失效。Redis配置為持久化，宕機(jī)重啟后，將自動(dòng)加載宕機(jī)時(shí)刻的數(shù)據(jù)到緩存系統(tǒng)中。具有更好的災(zāi)備機(jī)制。

4、Memcache可以使用Magent在客戶端進(jìn)行一致性hash做分布式。Redis支持在服務(wù)器端做分布式（PS:Twemproxy/Codis/Redis-cluster多種分布式實(shí)現(xiàn)方式）

5、Memcached的簡(jiǎn)單限制就是鍵（key）和Value的限制。最大鍵長(zhǎng)為250個(gè)字符?？梢越邮艿膬?chǔ)存數(shù)據(jù)不能超過1MB（可修改配置文件變大），因?yàn)檫@是典型slab 的最大值，不適合虛擬機(jī)使用。而Redis的Key長(zhǎng)度支持到512k。

6、Redis使用的是單線程模型，保證了數(shù)據(jù)按順序提交。Memcache需要使用cas保證數(shù)據(jù)一致性。CAS（Check and Set）是一個(gè)確保并發(fā)一致性的機(jī)制，屬于“樂觀鎖”范疇；原理很簡(jiǎn)單：拿版本號(hào)，操作，對(duì)比版本號(hào)，如果一致就操作，不一致就放棄任何操作

cpu利用。由于Redis只使用單核，而Memcached可以使用多核，所以平均每一個(gè)核上Redis在存儲(chǔ)小數(shù)據(jù)時(shí)比Memcached性能更 高。而在100k以上的數(shù)據(jù)中，Memcached性能要高于Redis 。（PS：Redis可以通過開啟多個(gè)實(shí)例來提高CPU利用率，Memcache默認(rèn)是單線程，需要編譯指定參數(shù)才能支持多線程。由于分布式緩存是IO密集型系統(tǒng)，所以性能很多程度受限于網(wǎng)絡(luò)通信，memcache使用了libevent網(wǎng)絡(luò)庫，redis自己實(shí)現(xiàn)了一套自己通信的庫。線程也不是影響吞吐量的重要因素。如第一點(diǎn)來說，一般情況下，程序處理內(nèi)存數(shù)據(jù)的速度遠(yuǎn)高于網(wǎng)卡接收的速度。使用線程好處是可以同時(shí)處理多條連接，在極端情況下，可能會(huì)提高響應(yīng)速度。但是單線程有時(shí)候比多線程 或多進(jìn)程更快，比需要考慮并發(fā)、鎖，也不會(huì)增加上下文切換等開銷，也即代碼更加簡(jiǎn)潔，執(zhí)行效率更高。）

7、memcache內(nèi)存管理：使用Slab Allocation。原理相當(dāng)簡(jiǎn)單，預(yù)先分配一系列大小固定的組，然后根據(jù)數(shù)據(jù)大小選擇最合適的塊存儲(chǔ)。避免了內(nèi)存碎片。（缺點(diǎn)：不能變長(zhǎng)，浪費(fèi)了一定空間）memcached默認(rèn)情況下下一個(gè)slab的最大值為前一個(gè)的1.25倍。8、redis內(nèi)存管理： Redis通過定義一個(gè)數(shù)組來記錄所有的內(nèi)存分配情況， Redis采用的是包裝的malloc/free，相較于Memcached的內(nèi)存 管理方法來說，要簡(jiǎn)單很多。由于malloc 首先以鏈表的方式搜索已管理的內(nèi)存中可用的空間分配，導(dǎo)致內(nèi)存碎片比較多。

總結(jié)：

其實(shí)對(duì)于企業(yè)選型Memcache、Redis而言，更多還是應(yīng)該看業(yè)務(wù)使用場(chǎng)景（因?yàn)镸emcache、Redis兩者都具有足夠高的性能和穩(wěn)定性）。假若業(yè)務(wù)場(chǎng)景需要用到持久化緩存功能、或者支持多種數(shù)據(jù)結(jié)構(gòu)的緩存功能，那么Redis則是最佳選擇。

（PS：Redis集群解決方式也優(yōu)于Memcache，Memcache在客戶端一致性hash的集群解決方案，Redis采用無中心的服務(wù)器端集群解決方案）

綜上所述：為了讓緩存系統(tǒng)能夠支持更多的業(yè)務(wù)場(chǎng)景，選擇Redis會(huì)更優(yōu)。（目前也越來越多的廠商選擇Redis）。

接下來重點(diǎn)對(duì)比Redis三大集群解決方案對(duì)比， Twemproxy VS Codis VS Redis-cluster

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

1、客戶端分片： 這種方案將分片工作放在業(yè)務(wù)程序端，程序代碼根據(jù)預(yù)先設(shè)置的路由規(guī)則，直接對(duì)多個(gè)Redis實(shí)例進(jìn)行分布式訪問。這樣的好處是，不依賴于第三方分布式中間件，實(shí)現(xiàn)方法和代碼都自己掌控，可隨時(shí)調(diào)整，不用擔(dān)心踩到坑。 這實(shí)際上是一種靜態(tài)分片技術(shù)。Redis實(shí)例的增減，都得手工調(diào)整分片程序?；诖朔制瑱C(jī)制的開源產(chǎn)品，現(xiàn)在仍不多見。 這種分片機(jī)制的性能比代理式更好（少了一個(gè)中間分發(fā)環(huán)節(jié)）。但缺點(diǎn)是升級(jí)麻煩，對(duì)研發(fā)人員的個(gè)人依賴性強(qiáng)——需要有較強(qiáng)的程序開發(fā)能力做后盾。如果主力程序員離職，可能新的負(fù)責(zé)人，會(huì)選擇重寫一遍。 所以，這種方式下，可運(yùn)維性較差。出現(xiàn)故障，定位和解決都得研發(fā)和運(yùn)維配合著解決，故障時(shí)間變長(zhǎng)。因此 這種方案，難以進(jìn)行標(biāo)準(zhǔn)化運(yùn)維，不太適合中小公司（除非有足夠的DevOPS）。

2、代理 分片：這種方案，將分片工作交給專門的代理程序來做。代理程序接收到來自業(yè)務(wù)程序的數(shù)據(jù)請(qǐng)求，根據(jù)路由規(guī)則，將這些請(qǐng)求分發(fā)給正確的Redis實(shí)例并返回給業(yè)務(wù)程序。 這種機(jī)制下，一般會(huì)選用第三方代理程序（而不是自己研發(fā)），因?yàn)楹蠖擞卸鄠€(gè)Redis實(shí)例，所以這類程序又稱為分布式中間件。 這樣的好處是，業(yè)務(wù)程序不用關(guān)心后端Redis實(shí)例，運(yùn)維起來也方便。雖然會(huì)因此帶來些性能損耗，但對(duì)于Redis這種內(nèi)存讀寫型應(yīng)用，相對(duì)而言是能容忍的。 這是我們推薦的集群實(shí)現(xiàn)方案。像基于該機(jī)制的開源產(chǎn)品Twemproxy，Codis便是其中代表，應(yīng)用非常廣泛。

3、服務(wù)器端分片：建立在基于無中心分布式架構(gòu)之上（沒有代理節(jié)點(diǎn)性能瓶頸問題）。Redis-Cluster即為官方基于該架構(gòu)的解決方案。 Redis Cluster將所有Key映射到16384個(gè)Slot中，集群中每個(gè)Redis實(shí)例負(fù)責(zé)一部分，業(yè)務(wù)程序通過集成的Redis Cluster客戶端進(jìn)行操作?？蛻舳丝梢韵蛉我粚?shí)例發(fā)出請(qǐng)求，如果所需數(shù)據(jù)不在該實(shí)例中，則該實(shí)例引導(dǎo)客戶端自動(dòng)去對(duì)應(yīng)實(shí)例讀寫數(shù)據(jù)。 Redis Cluster的成員管理（節(jié)點(diǎn)名稱、IP、端口、狀態(tài)、角色）等，都通過節(jié)點(diǎn)之間兩兩通訊，定期交換并更新。

接下來分別講解各解決方案代表產(chǎn)品實(shí)現(xiàn)方式優(yōu)缺點(diǎn)：

Twemproxy：
 

Twemproxy是一種代理分片機(jī)制，由Twitter開源。Twemproxy作為代理，可接受來自多個(gè)程序的訪問，按照路由規(guī)則，轉(zhuǎn)發(fā)給后臺(tái)的各個(gè)Redis服務(wù)器，再原路返回。這個(gè)方案順理成章地解決了單個(gè)Redis實(shí)例承載能力的問題。當(dāng)然，Twemproxy本身也是單點(diǎn)，需要用Keepalived做高可用方案。這么些年來，Twemproxy是應(yīng)用范圍最廣、穩(wěn)定性最高、最久經(jīng)考驗(yàn)的分布式中間件。只是，他還有諸多不方便之處。Twemproxy最大的痛點(diǎn)在于，無法平滑地?cái)U(kuò)容/縮容。這樣增加了運(yùn)維難度：業(yè)務(wù)量突增，需增加Redis服務(wù)器；業(yè)務(wù)量萎縮，需要減少Redis服務(wù)器。但對(duì)Twemproxy而言，基本上都很難操作?；蛘哒f，Twemproxy更加像服務(wù)器端靜態(tài)sharding。有時(shí)為了規(guī)避業(yè)務(wù)量突增導(dǎo)致的擴(kuò)容需求，甚至被迫新開一個(gè)基于Twemproxy的Redis集群。Twemproxy另一個(gè)痛點(diǎn)是，運(yùn)維不友好，甚至沒有控制面板。

Codis：

Codis由豌豆莢于2014年11月開源，基于Go和C開發(fā)，是近期涌現(xiàn)的、國(guó)人開發(fā)的優(yōu)秀開源軟件之一?，F(xiàn)已廣泛用于豌豆莢的各種Redis業(yè)務(wù)場(chǎng)景，從各種壓力測(cè)試來看，穩(wěn)定性符合高效運(yùn)維的要求。性能更是改善很多，最初比Twemproxy慢20%；現(xiàn)在比Twemproxy快近100%（條件：多實(shí)例，一般Value長(zhǎng)度）。Codis具有可視化運(yùn)維管理界面。Codis無疑是為解決Twemproxy缺點(diǎn)而出的新解決方案。因此綜合方面會(huì)由于Twemproxy很多。目前也越來越多公司選擇Codis。Codis引入了Group的概念，每個(gè)Group包括1個(gè)Redis Master及至少1個(gè)Redis Slave，這是和Twemproxy的區(qū)別之一。這樣做的好處是，如果當(dāng)前Master有問題，則運(yùn)維人員可通過Dashboard“自助式”切換到Slave，而不需要小心翼翼地修改程序配置文件。為支持?jǐn)?shù)據(jù)熱遷移（Auto Rebalance），出品方修改了Redis Server源碼，并稱之為Codis Server。Codis采用預(yù)先分片（Pre-Sharding）機(jī)制，事先規(guī)定好了，分成1024個(gè)slots（也就是說，最多能支持后端1024個(gè)Codis Server），這些路由信息保存在ZooKeeper中。

Redis-cluster：

reids-cluster在redis3.0中推出，支持Redis分布式集群部署模式。采用無中心分布式架構(gòu)。 所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬.節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效.客戶端與redis節(jié)點(diǎn)直連,不需要中間proxy層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可，減少了代理層，大大提高了性能。redis-cluster把所有的物理節(jié)點(diǎn)映射到[0-16383]slot上,cluster 負(fù)責(zé)維護(hù)node<->slot<->key之間的關(guān)系。目前Jedis已經(jīng)支持Redis-cluster。從計(jì)算架構(gòu)或者性能方面無疑Redis-cluster是最佳的選擇方案。（PS：雖然Redis-cluster從方案選型上面比較占據(jù)優(yōu)勢(shì)，但是由于Redis-cluster剛推出不久，雖然官方宣傳已經(jīng)發(fā)布的是文檔版本，但穩(wěn)定性方面還有待驗(yàn)證）

看完上述內(nèi)容，你們掌握Memcache及Redis分布式緩存集群方案特性使用場(chǎng)景優(yōu)缺點(diǎn)對(duì)比及選型是怎么樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！