共計 5519 個字符，預計需要花費 14 分鐘才能閱讀完成。
行業資訊
服務器
云計算
Memcache 及 Redis 分布式緩存集群方案特性使用場景優缺點對比及選型是怎么樣的
Memcache 及 Redis 分布式緩存集群方案特性使用場景優缺點對比及選型是怎么樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
分布式緩存集群方案特性使用場景優缺點對比及選型
分布式緩存特性：
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：
1、Redis 不僅僅支持簡單的 k / v 類型的數據，同時還提供 list，set，zset，hash 等數據結構的存儲。而
memcache 只支持簡單數據類型，需要客戶端自己處理復雜對象
2、Redis 支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用（PS：持久化在 rdb、aof）。Redis 借助了 fork 命令的 copy on write 機制。在生成快照時，將當前進程 fork 出一個子進程，然后在子進程中循環所有的數據，將數據寫成為 RDB 文件。 AOF 日志的全稱是 append only file，從名字上我們就能看出來，它是一個追加寫入的日志文件。與一般數據庫的 binlog 不同的是，AOF 文件是可識別的純文本，它的內容就是一個個 的 Redis 標準命令。當然，并不是發送發 Redis 的所有命令都要記錄到 AOF 日志里面，只有那些會導致數據發生修改的命令才會追加到 AOF 文件。那么每一條修改數據的命令都生成一條日志。（PS：memcache 不支持數據持久存儲）
3、由于 Memcache 沒有持久化機制，因此宕機所有緩存數據失效。Redis 配置為持久化，宕機重啟后，將自動加載宕機時刻的數據到緩存系統中。具有更好的災備機制。
4、Memcache 可以使用 Magent 在客戶端進行一致性 hash 做分布式。Redis 支持在服務器端做分布式（PS:Twemproxy/Codis/Redis-cluster 多種分布式實現方式）
5、Memcached 的簡單限制就是鍵（key）和 Value 的限制。最大鍵長為 250 個字符。可以接受的儲存數據不能超過 1MB（可修改配置文件變大），因為這是典型 slab 的最大值，不適合虛擬機使用。而 Redis 的 Key 長度支持到 512k。
6、Redis 使用的是單線程模型，保證了數據按順序提交。Memcache 需要使用 cas 保證數據一致性。CAS（Check and Set）是一個確保并發一致性的機制，屬于“樂觀鎖”范疇；原理很簡單：拿版本號，操作，對比版本號，如果一致就操作，不一致就放棄任何操作
cpu 利用。由于 Redis 只使用單核，而 Memcached 可以使用多核，所以平均每一個核上 Redis 在存儲小數據時比 Memcached 性能更 高。而在 100k 以上的數據中，Memcached 性能要高于 Redis 。（PS：Redis 可以通過開啟多個實例來提高 CPU 利用率，Memcache 默認是單線程，需要編譯指定參數才能支持多線程。由于分布式緩存是 IO 密集型系統，所以性能很多程度受限于網絡通信，memcache 使用了 libevent 網絡庫，redis 自己實現了一套自己通信的庫。線程也不是影響吞吐量的重要因素。如第一點來說，一般情況下，程序處理內存數據的速度遠高于網卡接收的速度。使用線程好處是可以同時處理多條連接，在極端情況下，可能會提高響應速度。但是單線程有時候比多線程 或多進程更快，比需要考慮并發、鎖，也不會增加上下文切換等開銷，也即代碼更加簡潔，執行效率更高。）
7、memcache 內存管理：使用 Slab Allocation。原理相當簡單，預先分配一系列大小固定的組，然后根據數據大小選擇最合適的塊存儲。避免了內存碎片。（缺點：不能變長，浪費了一定空間）memcached 默認情況下下一個 slab 的最大值為前一個的 1.25 倍。8、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 集群三種常見的解決方案：
1、客戶端分片：這種方案將分片工作放在業務程序端，程序代碼根據預先設置的路由規則，直接對多個 Redis 實例進行分布式訪問。這樣的好處是，不依賴于第三方分布式中間件，實現方法和代碼都自己掌控，可隨時調整，不用擔心踩到坑。這實際上是一種靜態分片技術。Redis 實例的增減，都得手工調整分片程序。基于此分片機制的開源產品，現在仍不多見。這種分片機制的性能比代理式更好（少了一個中間分發環節）。但缺點是升級麻煩，對研發人員的個人依賴性強——需要有較強的程序開發能力做后盾。如果主力程序員離職，可能新的負責人，會選擇重寫一遍。所以，這種方式下，可運維性較差。出現故障，定位和解決都得研發和運維配合著解決，故障時間變長。因此 這種方案，難以進行標準化運維，不太適合中小公司（除非有足夠的 DevOPS）。
2、代理 分片：這種方案，將分片工作交給專門的代理程序來做。代理程序接收到來自業務程序的數據請求，根據路由規則，將這些請求分發給正確的 Redis 實例并返回給業務程序。
這種機制下，一般會選用第三方代理程序（而不是自己研發），因為后端有多個 Redis 實例，所以這類程序又稱為分布式中間件。
這樣的好處是，業務程序不用關心后端 Redis 實例，運維起來也方便。雖然會因此帶來些性能損耗，但對于 Redis 這種內存讀寫型應用，相對而言是能容忍的。
這是我們推薦的集群實現方案。像基于該機制的開源產品 Twemproxy，Codis 便是其中代表，應用非常廣泛。
3、服務器端分片：建立在基于無中心分布式架構之上（沒有代理節點性能瓶頸問題）。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 剛推出不久，雖然官方宣傳已經發布的是文檔版本，但穩定性方面還有待驗證）
看完上述內容，你們掌握 Memcache 及 Redis 分布式緩存集群方案特性使用場景優缺點對比及選型是怎么樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
