大型分佈式系統中的緩存架構

時間 2019-11-11

標籤大型分佈式系統緩存架構欄目系統架構简体版

原文原文鏈接

做者：陳彩華css

來自：51cto技術棧（ID：blog51cto）數據庫

本文主要介紹大型分佈式系統中緩存的相關理論，常見的緩存組件以及應用場景。編程

緩存概述後端

緩存概述緩存

緩存的分類服務器

緩存主要分爲四類，以下圖：網絡

緩存的分類數據結構

CDN 緩存架構

CDN(Content Delivery Network 內容分發網絡)的基本原理是普遍採用各類緩存服務器，將這些緩存服務器分佈到用戶訪問相對集中的地區或網絡中。併發

在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求。

應用場景：主要緩存靜態資源，例如圖片，視頻。

CDN 緩存應用以下圖：

未使用 CDN 緩存

使用 CDN 緩存

CDN 緩存優勢以下圖：

優勢

反向代理緩存

反向代理位於應用服務器機房，處理全部對 Web 服務器的請求。

若是用戶請求的頁面在代理服務器上有緩衝的話，代理服務器直接將緩衝內容發送給用戶。

若是沒有緩衝則先向 Web 服務器發出請求，取回數據，本地緩存後再發送給用戶。經過下降向 Web 服務器的請求數，從而下降了 Web 服務器的負載。

應用場景：通常只緩存體積較小靜態文件資源，如 css、js、圖片。

反向代理緩存應用以下圖：

反向代理緩存應用圖

開源實現以下圖：

開源實現

本地應用緩存

指的是在應用中的緩存組件，其最大的優勢是應用和 Cache 是在同一個進程內部，請求緩存很是快速，沒有過多的網絡開銷等。

在單應用不須要集羣支持或者集羣狀況下各節點無需互相通知的場景下使用本地緩存較合適。

同時，它的缺點也是應爲緩存跟應用程序耦合，多個應用程序沒法直接的共享緩存，各應用或集羣的各節點都須要維護本身的單獨緩存，對內存是一種浪費。

應用場景：緩存字典等經常使用數據。

緩存介質以下圖所示：

緩存介質

編程直接實現以下圖：

編程直接實現

Ehcache

基本介紹：Ehcache 是一種基於標準的開源緩存，可提升性能，卸載數據庫並簡化可伸縮性。

它是使用最普遍的基於 Java 的緩存，由於它功能強大，通過驗證，功能齊全，並與其餘流行的庫和框架集成。

Ehcache 能夠從進程內緩存擴展到使用 TB 級緩存的混合進程內/進程外部署。

Ehcache 應用場景以下圖：

Ehcache 應用場景

Ehcache 的架構以下圖：

Ehcache 架構圖

Ehcache 的主要特徵以下圖：

Ehcache 主要特徵

Ehcache 緩存數據過時策略以下圖：

緩存數據過時策略

Ehcache 過時數據淘汰機制：即懶淘汰機制，每次往緩存放入數據的時候，都會存一個時間，在讀取的時候要和設置的時間作 TTL 比較來判斷是否過時。

Guava Cache

基本介紹：Guava Cache 是 Google 開源的 Java 重用工具集庫 Guava 裏的一款緩存工具。

Guava Cache 特色與功能以下圖：

Guava Cache 特色與功能

Guava Cache 的應用場景以下圖：

Guava Cache 應用場景

Guava Cache 的數據結構以下圖：

Guava Cache 數據結構圖

Guava Cache 結構特色

Guava Cache 的緩存更新策略以下圖：

Guava Cache 緩存更新策略

Guava Cache 的緩存回收策略以下圖：

Guava Cache 緩存回收策略

分佈式緩存

指的是與應用分離的緩存組件或服務，其最大的優勢是自身就是一個獨立的應用，與本地應用隔離，多個應用可直接的共享緩存。

分佈式緩存的主要應用場景以下圖：

分佈式緩存應用場景

分佈式緩存的主要接入方式以下圖：

分佈式緩存接入方式

下面介紹分佈式緩存常見的 2 大開源實現 Memcached 和 Redis。

Memcached

Memcached 是一個高性能，分佈式內存對象緩存系統，經過在內存裏維護一個統一的巨大的 Hash 表，它可以用來存儲各類格式的數據，包括圖像、視頻、文件以及數據庫檢索的結果等。

簡單的說就是將數據調用到內存中，而後從內存中讀取，從而大大提升讀取速度。

Memcached 的特色以下圖：

Memcached 特色

Memcached 的基本架構以下圖：

Memcached 基本架構

緩存數據過時策略：LRU（最近最少使用）到期失效策略，在 Memcached 內存儲數據項時，能夠指定它在緩存的失效時間，默認爲永久。

當 Memcached 服務器用完分配的內存時，失效的數據被首先替換，而後是最近未使用的數據。

數據淘汰內部實現：懶淘汰機制爲每次往緩存放入數據的時候，都會存一個時間，在讀取的時候要和設置的時間作 TTL 比較來判斷是否過時。

分佈式集羣實現：服務端並無「分佈式」功能。每一個服務器都是徹底獨立和隔離的服務。 Memcached 的分佈式，是由客戶端程序實現的。

數據讀寫流程圖

Memcached 分佈式集羣實現

Redis

Redis 是一個遠程內存數據庫（非關係型數據庫），性能強勁，具備複製特性以及解決問題而生的獨一無二的數據模型。

它能夠存儲鍵值對與 5 種不一樣類型的值之間的映射，能夠將存儲在內存的鍵值對數據持久化到硬盤，可使用複製特性來擴展讀性能。

Redis 還可使用客戶端分片來擴展寫性能，內置了複製（replication），LUA 腳本（Lua scripting），LRU 驅動事件（LRU eviction），事務（transactions）和不一樣級別的磁盤持久化（persistence）。

並經過 Redis 哨兵（Sentinel）和自動分區（Cluster）提供高可用性（High Availability）。

Redis 的數據模型以下圖：

Redis 數據模型

Redis 的數據淘汰策略以下圖：

Redis 數據淘汰策略

Redis 的數據淘汰內部實現以下圖：

Redis 數據淘汰內部實現

Redis 的持久化方式以下圖：

Redis 持久化方式

Redis 底層實現部分解析以下圖：

啓動的部分過程圖解

Server 端持久化的部分操做圖解

底層哈希表實現(漸進式Rehash)以下圖：

初始化字典

新增字典元素圖解

Rehash 執行流程

Redis 的緩存設計原則以下圖所示：

Redis 緩存設計原則

Redis 與 Memcached 的比較以下圖：

Redis 與 Memcached 比較

下面主要介紹緩存架構設計常見問題以及解決方案，業界案例。

分層緩存架構設計

緩存帶來的複雜度問題

常見的問題主要包括以下幾點：

數據一致性
緩存穿透
緩存雪崩
緩存高可用
緩存熱點

下面逐一介紹分析這些問題以及相應的解決方案。

數據一致性

由於緩存屬於持久化數據的一個副本，所以不可避免的會出現數據不一致問題，致使髒讀或讀不到數據的狀況。

數據不一致，通常是由於網絡不穩定或節點故障致使問題出現的常見 3 個場景以及解決方案：

緩存穿透

緩存通常是 Key-Value 方式存在，當某一個 Key 不存在時會查詢數據庫，假如這個 Key，一直不存在，則會頻繁的請求數據庫，對數據庫形成訪問壓力。

主要解決方案：

對結果爲空的數據也進行緩存，當此 Key 有數據後，清理緩存。
必定不存在的 Key，採用布隆過濾器，創建一個大的 Bitmap 中，查詢時經過該 Bitmap 過濾。

緩存雪崩

緩存高可用

緩存是否高可用，須要根據實際的場景而定，並非全部業務都要求緩存高可用，須要結合具體業務，具體狀況進行方案設計，例如臨界點是否對後端的數據庫形成影響。

主要解決方案：

分佈式：實現數據的海量緩存。
複製：實現緩存數據節點的高可用。

緩存熱點

一些特別熱點的數據，高併發訪問同一份緩存數據，致使緩存服務器壓力過大。

解決：複製多份緩存副本，把請求分散到多個緩存服務器上，減輕緩存熱點致使的單臺緩存服務器壓力

業界案例

案例主要參考新浪微博陳波的技術分享，能夠查看原文《百億級日訪問量的應用如何作緩存架構設計？》

技術挑戰

Feed 緩存架構圖

架構特色

新浪微博把 SSD 應用在分佈式緩存場景中，將傳統的 Redis/MC + MySQL 方式，擴展爲 Redis/MC + SSD Cache + MySQL 方式。

SSD Cache 做爲 L2 緩存使用，第一下降了 MC/Redis 成本太高，容量小的問題，也解決了穿透 DB 帶來的數據庫訪問壓力。

主要在數據架構、性能、儲存成本、服務化等不一樣方面進行了優化加強。

...

相關標籤/搜索