一.引言

• 快取是 分散式系統 中重要元件，主要解決資料高併發，大資料場景下，熱點資料訪問的效能安全問題，提供高效能的資料快速訪問。
• 快取的原理：將資料放到更快的儲存中、將資料快取到離應用最近的位置、將資料快取到離使用者最近的位置。

二.快取的流程（淺談）

1.快取大致流程：

• F5(不走快取) —> 瀏覽器快取/應用快取 —> Nginx代理 —>Redis快取 —>本地資料庫快取 —> RDBMS
  接下來，分步驟瞭解下：

2.F5(不走快取)

• refresh重新整理頁面，不走快取（就近儲存，減少請求量）

3.瀏覽器快取/應用快取

• 本地快取 map結構，url作為key
• 因為網站短時間內變化少，具備了快取條件，可以快取到本地，提升響應速度和使用者體驗

4.Nginx代理伺服器

• 負載均衡/動靜分離
• freemaker頁面靜態化技術，可以把頁面靜態元素抽離出來作為快取，因為頁面主要改變的是資料，頁面大致佈局不變。
• 使用代理平臺（定時，主動推送，然後直接在平臺上拿資料即可）

5.Redis快取（NoSQL產品）

• NoSQL是弱事務控制（提升了速度，使用者體驗好）
• 大資料分析（非精準，分析出規律和趨勢）
• 利用MyBatis的一級，二級快取

6.本地資料庫快取

• Mybatis和Oracle、MySQL本地資料庫快取，可以消解使用者請求量

三.轉載 - 分散式快取那些事兒

原文連結：http://blog.csdn.net/dinglang_2009/article/details/9071075
（作者：dinglang_2009）
http://os.51cto.com/art/201306/397999.htm

在前面的一些文章中，從實戰的角度，講解了有關 memcached的應用、容災、監控等等。但是缺乏對理論的講解和原理性的剖析。本文將從理論的角度去介紹，讓大家從巨集觀上對“分散式快取、nosql”等技術有所瞭解，以便進一步學習和使用。在構建大規模的web應用時，快取技術可以說是必備的，學習的必要性不言而喻。

分散式快取概述

1.1 分散式快取的特性

分散式快取具有如下特性:

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.2 典型應用場景

分散式快取的典型應用場景可分為以下幾類:

1. 頁面快取.用來快取Web 頁面的內容片段,包括HTML、CSS 和圖片等,多應用於社交網站等;

2. 應用物件快取.快取系統作為ORM 框架的二級快取對外提供服務,目的是減輕資料庫的負載壓力,加速應用訪問;

3. 狀態快取.快取包括Session 會話狀態及應用橫向擴充套件時的狀態資料等,這類資料一般是難以恢復的,對可用性要求較高,多應用於高可用叢集;

4. 並行處理.通常涉及大量中間計算結果需要共享;

5. 事件處理.分散式快取提供了針對事件流的連續查詢(continuous query)處理技術,滿足實時性需求;

6. 極限事務處理.分散式快取為事務型應用提供高吞吐率、低延時的解決方案,支援高併發事務請求處理,多應用於鐵路、金融服務和電信等領域.

1.3 分散式快取的發展

分散式快取經歷了多個發展階段,由最初的本地快取到彈性快取平臺直至彈性應用平臺[8],目標是朝著構建更好的分散式系統方向發展(如下圖所示).

1. 本地快取:資料儲存在應用程式碼所在記憶體空間.優點是可以提供快速的資料訪問;缺點是資料無法分散式共享,無容錯處理.典型的,如Cache4j;

2. 分散式快取系統:資料在固定數目的叢集節點間分佈儲存.優點是快取容量可擴充套件(靜態擴充套件);缺點是擴充套件過程中需要大量配置,無容錯機制.典型的,如 Memcached;

3. 彈性快取平臺:資料在叢集節點間分佈儲存,基於冗餘機制實現高可用性.優點是可動態擴充套件,具有容錯能力;缺點是複製備份會對系統性能造成一定影響.典型的,如 Windows Appfabric Caching;

4. 彈性應用平臺:彈性應用平臺代表了雲環境下分散式快取系統未來的發展方向.簡單地講,彈性應用平臺是彈性快取與程式碼執行的組合體,將業務邏輯程式碼轉移到資料所在節點執行,可以極大地降低資料傳輸開銷,提升系統性能.典型的,如 GigaSpaces XAP.

1.4 分散式快取與NoSQL

NoSQL 又稱為Not Only Sql,主要是指非關係型、分散式、支援水平擴充套件的資料庫設計模式.NoSQL 放棄了傳統關係型資料庫嚴格的事務一致性和正規化約束,採用弱一致性模型.相對於NoSQL 系統,傳統資料庫難以滿足雲環境下應用資料的儲存需求,具體體現在以下3 個方面:

1. 根據CAP 理論,一致性(consistency)、可用性(availability)和分割槽容錯(partition tolerance)這3 個要素最多同時滿足兩個,不可能三者兼顧.對雲平臺中部署的大量Web 應用而言,資料可用性與分割槽容錯的優先順序通常更高,所以一般會選擇適當放鬆一致性約束.傳統資料庫的事務一致性需求制約了其橫向伸縮與高可用技術的實現;

2. 傳統資料庫難以適應新的資料儲存訪問模式.Web 2.0 站點以及雲平臺中存在大量半結構化資料,如使用者Session 資料、時間敏感的事務型資料、計算密集型任務資料等,這些狀態資料更適合以Key/Value 形式儲存,不需要RDBMS 提供的複雜的查詢與管理功能;

3. NoSQL 提供低延時的讀寫速度,支援水平擴充套件,這些特性對擁有海量資料訪問請求的雲平臺而言是至關重要的.傳統關係型資料無法提供同樣的效能,而記憶體資料庫容量有限且不具備擴充套件能力.分散式快取作為NoSQL 的一種重要實現形式,可為雲平臺提供高可用的狀態儲存與可伸縮的應用加速服務,與其他NoSQL 系統間並無清晰的界限.平臺中應用訪問與系統故障均具有不可預知性,為了更好地應對這些挑戰,應用軟體在架構時通常採用無狀態設計,大量狀態資訊不再由元件、容器或平臺來管理,而是直接交 付給後端的分散式快取服務或NoSQL 系統.

1.5 分散式快取與極限事務處理

隨著雲端計算與 Web 2.0 的進一步發展,許多企業或組織時常會面對空前的需求:百萬級的併發使用者訪問、每秒數以千計的併發事務處理、靈活的彈性與可伸縮性、低延時及7×24×365 可用性等.傳統事務型應用面臨極限規模的併發事務處理,出現了極限事務處理型應用,典型的有鐵路售票系統.Wikipedia 認為,極限事務處理是每秒多於500 事務或高於10 000 次併發訪問的事務處理 Gartner 將極限事務處理(extreme transactionprocessing,簡稱XTP)定義為一種為事務型應用的開發、部署、管理和維護供支援的應用模式,特點是對效能、可擴充套件性、可用性、可管理性等方面的極限需求.Gartner 在其報告中預測指出,極限事務處理型應用的規模將由2005 年的10%提升至2010 年的20%,極限事務處理技術是未來5 年~10 年的熱點技術.極限事務處理的引入,無疑給傳統Web 三層架構帶來了新的挑戰.即,如何在廉價的、標準化的硬體和軟體平臺之上,對大容量、業務關鍵型的事務處理應用提供良好的支撐.分散式快取作為一種關鍵的XTP 技術,可為事務型應用提供高吞吐率、低延時的技術解決方案.其延遲寫(write-behind)機制可提供更短的響應時間,同時極大地降低資料庫的事務處理負載,分階段事件驅動架構(staged event-driven architecture)可以支援大規模、高併發的事務處理請求.此外,分散式快取在記憶體中管理事務並提供資料的一致性保障,採用資料複製技術實現高可用性,具有較優的擴充套件性與效能組合.

四.轉載 - 快取技術的詳解

原文連結：https://blog.csdn.net/qq_26517369/article/details/78330694
（作者：qq_26517369）
一、快取概述

快取是分散式系統中的重要元件，主要解決高併發，大資料場景下，熱點資料訪問的效能問題。提供高效能的資料快速訪問。

1、快取的原理

將資料寫入/讀取速度更快的儲存（裝置）；

將資料快取到離應用最近的位置；

將資料快取到離使用者最近的位置。

2、快取分類

在分散式系統中，快取的應用非常廣泛，從部署角度有以下幾個方面的快取應用。

CDN快取；

反向代理快取；

分散式Cache；

本地應用快取；

3、快取媒介

常用中介軟體：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等；

快取的內容：檔案，資料，物件；

快取的介質：CPU，記憶體（本地，分散式），磁碟（本地，分散式）

4、快取設計

快取設計需要解決以下幾個問題：

快取什麼？

哪些資料需要快取：1.熱點資料；2.靜態資源。

快取的位置？

CDN，反向代理，分散式快取伺服器，本機（記憶體，硬碟）

如何快取的問題？

過期策略

固定時間：比如指定快取的時間是30分鐘；

相對時間：比如最近10分鐘內沒有訪問的資料；

同步機制

實時寫入；（推）

非同步重新整理；（推拉）

二、CDN快取

CDN主要解決將資料快取到離使用者最近的位置，一般快取靜態資原始檔（頁面，指令碼，圖片，視訊，檔案等）。國內網路異常複雜，跨運營商的網路訪問會很慢。為了解決跨運營商或各地使用者訪問問題，可以在重要的城市，部署CDN應用。使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。

1、CND原理

CDN的基本原理是廣泛採用各種快取伺服器，將這些快取伺服器分佈到使用者訪問相對集中的地區或網路中，在使用者訪問網站時，利用全域性負載技術將使用者的訪問指向距離最近的工作正常的快取伺服器上，由快取伺服器直接響應使用者請求。

（1）未部署CDN應用前

網路請求路徑：

請求：本機網路（區域網）——》運營商網路——》應用伺服器機房

響應：應用伺服器機房——》運營商網路——》本機網路（區域網）

在不考慮複雜網路的情況下，從請求到響應需要經過3個節點，6個步驟完成一次使用者訪問操作。

（2）部署CDN應用後

網路路徑：

請求：本機網路（區域網）——》運營商網路

響應：運營商網路——》本機網路（區域網）

在不考慮複雜網路的情況下，從請求到響應需要經過2個節點，2個步驟完成一次使用者訪問操作。

與不部署CDN服務相比，減少了1個節點，4個步驟的訪問。極大的提高的系統的響應速度。

2、CDN優缺點

優點（摘自百度百科）：

本地Cache加速：提升訪問速度，尤其含有大量圖片和靜態頁面站點。

映象服務：消除了不同運營商之間互聯的瓶頸造成的影響，實現了跨運營商的網路加速，保證不同網路中的使用者都能得到良好的訪問質量。

遠端加速：遠端訪問使用者根據DNS負載均衡技術智慧自動選擇Cache伺服器，選擇最快的Cache伺服器，加快遠端訪問的速度。

頻寬優化：自動生成伺服器的遠端Mirror（映象）cache伺服器，遠端使用者訪問時從cache伺服器上讀取資料，減少遠端訪問的頻寬、分擔網路流量、減輕原站點WEB伺服器負載等功能。

叢集抗攻擊：廣泛分佈的CDN節點加上節點之間的智慧冗餘機制，可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響，同時保證較好的服務質量。

缺點：

動態資源快取，需要注意實時性；

解決：主要快取靜態資源，動態資源建立多級快取或準實時同步；

如何保證資料的一致性和實時性需要權衡考慮；

解決：

（1）設定快取失效時間（1個小時，最終一致性）；

（2）資料版本號；

3、CND架構參考

摘自《雲宙視訊CDN系統》

4、CND技術實踐

目前，中小型網際網路公司，綜合成本考慮，一般租用第三方CDN服務，大型網際網路公司，採用自建或第三方結合的方式。比如淘寶剛開始使用第三方的，當流量很大後，第三方公司無法支撐其CDN流量，淘寶最後採用自建CDN的方式實現。

淘寶CDN，如下圖（來自網路）：

三、反向代理快取

反向代理是指在網站伺服器機房部署代理伺服器，實現負載均衡、資料快取、安全控制等功能。

1、快取原理

反向代理位於應用伺服器機房，處理所有對WEB伺服器的請求。如果使用者請求的頁面在代理伺服器上有緩衝的話，代理伺服器直接將緩衝內容傳送給使用者。如果沒有緩衝則先向WEB伺服器發出請求，取回資料，本地快取後再發送給使用者。通過降低向WEB伺服器的請求數，從而降低了WEB伺服器的負載。

反向代理一般快取靜態資源，動態資源轉發到應用伺服器處理。常用的快取應用伺服器有Varnish、Ngnix、Squid。

2、Squid示例

Squid 反向代理一般只快取靜態資源，動態程式預設不快取。根據從 WEB 伺服器返回的 HTTP 頭標記來緩衝靜態頁面。有四個最重要 HTTP 頭標記：

Last-Modified：告訴反向代理頁面什麼時間被修改

Expires：告訴反向代理頁面什麼時間應該從緩衝區中刪除

Cache-Control：告訴反向代理頁面是否應該被緩衝

Pragma用來包含實現特定的指令，最常用的是 Pragma:no-cache

Squid 反向代理加速網站例項

通過DNS的輪詢技術，將客戶端的請求分發給其中一臺 Squid 反向代理伺服器處理；

如果這臺 Squid 快取了使用者的請求資源，則將請求的資源直接返回給使用者；

否則這臺 Squid 將沒有快取的請求根據配置的規則傳送給鄰居 Squid 和後臺的 WEB 伺服器處理；

這樣既減輕後臺 WEB 伺服器的負載，又提高整個網站的效能和安全性。

2、代理快取比較

常用的代理快取有Varnish，Squid，Ngnix，簡單比較如下：

（1）varnish和squid是專業的cache服務，nginx需要第三方模組支援；

（2） Varnish採用記憶體型快取，避免了頻繁在記憶體、磁碟中交換檔案，效能比Squid高；

（3）Varnish由於是記憶體cache，所以對小檔案如css,js,小圖片啥的支援很棒，後端的持久化快取可以採用的是Squid或ATS；

（4）Squid功能全而大，適合於各種靜態的檔案快取，一般會在前端掛一個HAProxy或nginx做負載均衡跑多個例項；

（5）Nginx採用第三方模組ncache做的緩衝，效能基本達到varnish，一般作為反向代理使用，可以實現簡單的快取。

四、分散式快取

CDN，反向代理快取，主要解決靜態檔案，或使用者請求資源的快取，資料來源一般為靜態檔案或動態生成的檔案（有快取頭標識）。

而分散式快取，主要指快取使用者經常訪問資料的快取，資料來源為資料庫。一般起到熱點資料訪問和減輕資料庫壓力的作用。

目前分散式快取設計，在大型網站架構中是必備的架構要素。常用的中介軟體有Memcache，Redis。

1、Memcache

Memcache是一個高效能，分散式記憶體物件快取系統，通過在記憶體裡維護一個統一的巨大的hash表，它能夠用來儲存各種格式的資料，包括影象、視訊、檔案以及資料庫檢索的結果等。簡單的說就是將資料呼叫到記憶體中，然後從記憶體中讀取，從而大大提高讀取速度。

Memcache特性：

（1）使用實體記憶體作為快取區，可獨立執行在伺服器上。每個程序最大2G，如果想快取更多的資料，可以開闢更多的Memcache程序（不同埠）或者使用分散式Memcache進行快取，將資料快取到不同的物理機或者虛擬機器上。

（2）使用key-value的方式來儲存資料，這是一種單索引的結構化資料組織形式，可使資料項查詢時間複雜度為O(1)。

（3）協議簡單：基於文字行的協議，直接通過telnet在memcached伺服器上可進行存取資料操作，簡單，方便多種快取參考此協議。

（4）基於Libevent高效能通訊：Libevent是一套利用C開發的程式庫，它將BSD系統的kqueue，Linux系統的epoll等事件處理功能封裝成一個介面，與傳統的select相比，提高了效能。

（5）內建的記憶體管理方式：所有資料都儲存在記憶體中，存取資料比硬碟快，當記憶體滿後，通過LRU演算法自動刪除不使用的快取，但沒有考慮資料的容災問題，重啟服務，所有資料會丟失。

（6）分散式：各個memcached伺服器之間互不通訊，各自獨立存取資料，不共享任何資訊。伺服器並不具有分散式功能，分散式部署取決於Memcache客戶端。

（7）快取策略：memcached的快取策略是LRU（最近最少使用）到期失效策略。在memcached記憶體儲資料項時，可以指定它在快取的失效時間，預設為永久。當memcached伺服器用完分配的內時，失效的資料被首先替換，然後也是最近未使用的資料。在LRU中，memcached使用的是一種Lazy Expiration策略，自己不會監控存入的key/vlue對是否過期，而是在獲取key值時檢視記錄的時間戳，檢查key/value對空間是否過期，這樣可減輕伺服器的負載。

Memcache工作原理：

Memcache的工作流程如下：

（1）先檢查客戶端的請求資料是否在memcached中，如有，直接把請求資料返回，不再對資料庫進行任何操作。

（2） 如果請求的資料不在memcached中，就去查資料庫，把從資料庫中獲取的資料返回給客戶端，同時把資料快取一份到memcached中（memcached客戶端不負責，需要程式實現）。

（3） 每次更新資料庫的同時更新memcached中的資料，保證一致性。

（4） 當分配給memcached記憶體空間用完之後，會使用LRU（Least Recently Used，最近最少使用）策略加上到期失效策略，失效資料首先被替換，然後再替換掉最近未使用的資料。

Memcache叢集

memcached 雖然稱為“分散式 ” 快取伺服器，但伺服器端並沒有 “ 分散式 ” 功能。每個伺服器都是完全獨立和隔離的服務。 memcached 的分散式，是由客戶端程式實現的。

當向memcached叢集存入/取出key value時，memcached客戶端程式根據一定的演算法計算存入哪臺伺服器，然後再把key value值存到此伺服器中。

存取資料分二步走，第一步，選擇伺服器，第二步存取資料。

分散式演算法(Consistent Hashing)：

選擇伺服器演算法有兩種，一種是根據餘數來計算分佈，另一種是根據雜湊演算法來計算分佈。

餘數演算法：

先求得鍵的整數雜湊值，再除以伺服器臺數，根據餘數確定存取伺服器。

優點：計算簡單，高效。

缺點：在memcached伺服器增加或減少時，幾乎所有的快取都會失效。

雜湊演算法：（一致性Hash）

先算出memcached伺服器的雜湊值，並將其分佈到0到2的32次方的圓上，然後用同樣的方法算出儲存資料的鍵的雜湊值並對映至圓上，最後從資料對映到的位置開始順時針查詢，將資料儲存到查詢到的第一個伺服器上，如果超過2的32次方，依然找不到伺服器，就將資料儲存到第一臺memcached伺服器上。

如果添加了一臺Memcached伺服器，只在圓上增加伺服器的逆時針方向的第一臺伺服器上的鍵會受到影響。

一致性Hash演算法：解決了餘數演算法增加節點命中大幅額度降低的問題，理論上，插入一個實體節點，平均會影響到：虛擬節點數 /2 的節點資料的命中。

2、Redis

Redis 是一個開源（BSD許可）的，基於記憶體的，多資料結構儲存系統。可以用作資料庫、快取和訊息中介軟體。 支援多種型別的資料結構，如 字串（strings）， 雜湊（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與範圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。

內建了 複製（replication），LUA指令碼（Lua scripting）， LRU驅動事件（LRU eviction），事務（transactions） 和不同級別的 磁碟持久化（persistence）， 並通過 Redis哨兵（Sentinel）和自動分割槽（Cluster）提供高可用性（high availability）。

Redis常用資料型別

String

常用命令：set，get，decr，incr，mget。

應用場景：String是最常用的一種資料型別，與Memcache的key value儲存方式類似。

實現方式：String在Redis內部儲存預設就是一個字串，被redisObject所引用，當遇到incr，decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

Hash

常用命令：hget，hset，hgetall 。

應用場景：以儲存一個使用者資訊物件資料，為例：

實現方式：Redis Hash對應的Value，內部實際就是一個HashMap，實際這裡會有2種不同實現。

（1）Hash的成員比較少時Redis為了節省記憶體會採用類似一維數 組的方式來緊湊儲存，而不會採用真正的HashMap結構，對應的value redisObject的encoding為zipmap。

（2）當成員數量增大時會自動轉成真正的HashMap，此時encoding為ht。

List

常用命令：lpush,rpush,lpop,rpop,lrange。

應用場景：Redis list的應用場景非常多，也是Redis最重要的資料結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現。

實現方式：Redis list的實現為一個雙向連結串列，可以支援反向查詢和遍歷，方便操作。不過帶來了部分額外的記憶體開銷，Redis內部的很多實現，包括髮送緩衝佇列等也都是用的這個資料結構。

Set

常用命令：sadd,spop,smembers,sunion。

應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要儲存一個列表資料，又不希望出現重複資料時，set 是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。

實現方式：set的內部實現是一個value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

Sorted set

常用命令：zadd、zrange、zrem、zcard。

使用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過使用者額外提供一個優先順序(score)的引數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，可以選擇sorted set資料結構，比如twitter 的public timeline可以以發表時間作為score來儲存，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證資料的儲存和有序，HashMap裡放的是成員到score的對映，而跳躍表裡存放的 是所有的成員，排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的查詢效率，並且在實現上比較簡單。

Redis叢集

（1）通過keepalived實現的高可用方案

切換流程：

當Master掛了後，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務；

當Master起來後，VIP 地址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始作為從同步資料；

依次類推。

主從同時Down機情況：

非計劃性，不做考慮，一般也不會存在這種問題

計劃性重啟，重啟之前通過運維手段SAVE DUMP 主庫資料；需要注意順序：

關閉其中一臺機器上所有redis，是得master全部切到另外一臺機器（多例項部署，單機上既有主又有從的情況）；並關閉機器

依次dump主上redis服務

關閉主

啟動主，並等待資料load完畢

啟動從

刪除DUMP 檔案（避免重啟載入慢）

（2）使用Twemproxy 實現叢集方案

由twitter開源的c版本proxy，同時支援memcached和redis，目前最新版本為：0.2.4，持續開發中;https://github.com/twitter/twemproxy .twitter用它主要減少前端與快取服務間網路連線數。

特點：快、輕量級、減少後端Cache Server連線數、易配置、支援ketama、modula、random、常用hash分片演算法。

這裡使用keepalived實現高可用主備方案，解決proxy單點問題。

優點：

對於客戶端而言，redis叢集是透明的，客戶端簡單，遍於動態擴容；

Proxy為單點、處理一致性hash時，叢集節點可用性檢測不存在腦裂問題；

高效能，CPU密集型，而redis節點叢集多CPU資源冗餘，可部署在redis節點叢集上，不需要額外裝置。

3、Memcache與Redis的比較

（1）資料結構：Memcache只支援key value儲存方式，Redis支援更多的資料型別，比如Key value、hash、list、set、zset；

（2）多執行緒：Memcache支援多執行緒，Redis支援單執行緒；CPU利用方面Memcache優於Redis；

（3）持久化：Memcache不支援持久化，Redis支援持久化；

（4）記憶體利用率：Memcache高，Redis低（採用壓縮的情況下比Memcache高）；

（5）過期策略：Memcache過期後，不刪除快取，會導致下次取資料資料的問題，Redis有專門執行緒，清除快取資料；

五、本地快取

本地快取是指應用內部的快取，標準的分散式系統，一般有多級快取構成。本地快取是離應用最近的快取，一般可以將資料快取到硬碟或記憶體。

1、硬碟快取

將資料快取到硬碟到，讀取時從硬碟讀取。原理是直接讀取本機檔案，減少了網路傳輸消耗，比通過網路讀取資料庫速度更快。可以應用在對速度要求不是很高，但需要大量快取儲存的場景。

2、記憶體快取

直接將資料儲存到本機記憶體中，通過程式直接維護快取物件，是訪問速度最快的方式。

六、快取架構示例

職責劃分：

CDN：存放HTML、CSS、JS等靜態資源；

反向代理：動靜分離，只快取使用者請求的靜態資源；

分散式快取：快取資料庫中的熱點資料；

本地快取：快取應用字典等常用資料。

請求過程：

（1）瀏覽器向客戶端發起請求，如果CDN有快取則直接返回；

（2）如果CDN無快取，則訪問反向代理伺服器；

（3）如果反向代理伺服器有快取則直接返回；

（4）如果反向代理伺服器無快取或動態請求，則訪問應用伺服器；

（5）應用伺服器訪問本地快取；如果有快取，則返回代理伺服器，並快取資料；（動態請求不快取）

（6）如果本地快取無資料，則讀取分散式快取；並返回應用伺服器；應用伺服器將資料快取到本地快取（部分）；

（7）如果分散式快取無資料，則應用程式讀取資料庫資料，並放入分散式快取。

七、快取常見問題

1、資料一致性

快取是在資料持久化之前的一個節點，主要是將熱點資料放到離使用者最近或訪問速度更快的介質中，加快資料的訪問，減小響應時間。

因為快取屬於持久化資料的一個副本，因此不可避免的會出現資料不一致問題。導致髒讀或讀不到資料的情況。資料不一致，一般是因為網路不穩定或節點故障導致。根據資料的操作順序，主要有以下幾種情況。

場景介紹

（1）先寫快取，再寫資料庫

如下圖：

假如快取寫成功，但寫資料庫失敗或響應延遲，則下次讀取（併發讀）快取時，就出現髒讀。

（2）先寫資料庫，再寫快取

如下圖：

假如寫資料庫成功，但寫快取失敗，則下次讀取（併發讀）快取時，則讀不到資料。

（3）快取非同步重新整理

指資料庫操作和寫快取不在一個操作步驟中，比如在分散式場景下，無法做到同時寫快取或需要非同步重新整理（補救措施）時候。

此種情況，主要考慮資料寫入和快取重新整理的時效性。比如多久內重新整理快取，不影響使用者對資料的訪問。

解決方法

第一個場景：這個寫快取的方式，本身就是錯誤的，需要改為先寫持久化介質，再寫快取的方式。

第二個場景：

（1）根據寫入快取的響應來進行判斷，如果快取寫入失敗，則回滾資料庫操作；此種方法增加了程式的複雜度，不建議採用；

（2）快取使用時，假如讀快取失敗，先讀資料庫，再回寫快取的方式實現。

第三個場景：

（1）首先確定，哪些資料適合此類場景；

（2）根據經驗值確定合理的資料不一致時間，使用者資料重新整理的時間間隔。

其他方法

（1）超時：設定合理的超時時間；

（2）重新整理：定時重新整理一定範圍內（根據時間，版本號）的資料；

以上是簡化資料讀寫場景，實際中會分為：

（1）快取與資料庫之間的一致性；

（2）多級快取之前的一致性；

（3）快取副本之前的一致性。

2、快取高可用

業界有兩種理論，第一套快取就是快取，臨時儲存資料的，不需要高可用。第二種快取逐步演化為重要的儲存介質，需要做高可用。

本人的看法是，快取是否高可用，需要根據實際的場景而定。臨界點是是否對後端的資料庫造成影響。

具體的決策依據需要根據，叢集的規模（資料，快取），成本（伺服器，運維），系統性能（併發量，吞吐量，響應時間）等方面綜合評價。

解決方法

快取的高可用，一般通過分散式和複製實現。分散式實現資料的海量快取，複製實現快取資料節點的高可用。架構圖如下：

其中，分散式採用一致性Hash演算法，複製採用非同步複製。

其他方法

（1）複製雙寫：快取節點的複製，由非同步改為雙寫，只有兩份都寫成功，才算成功。

（2）虛擬層：一致性Hash存在，假如其中一個HASH環不可用，資料會寫入臨近的環，當HASH可用時，資料又寫入正常的HASH環，會導致資料偏移問題。這種情況，可以考慮在HASH環前面加一個虛擬層實現。

（3）多級快取：比如一級使用本地快取，二級採用分散式Cahce，三級採用分散式Cache+本地持久化；

方式很多，需要根據業務場景靈活選擇。

3、快取雪崩

雪崩是指當大量快取失效時，導致大量的請求訪問資料庫，導致資料庫伺服器，無法抗住請求或掛掉的情況。

解決方法：

（1）合理規劃快取的失效時間；

（2）合理評估資料庫的負載壓力；

（3）對資料庫進行過載保護或應用層限流；

（4）多級快取設計，快取高可用。

4、快取穿透

快取一般是Key，value方式存在，當某一個Key不存在時會查詢資料庫，假如這個Key，一直不存在，則會頻繁的請求資料庫，對資料庫造成訪問壓力。

解決方法：

（1）對結果為空的資料也進行快取，當此key有資料後，清理快取；

（2）一定不存在的key，採用布隆過濾器，建立一個大的Bitmap中，查詢時通過該bitmap過濾。