第一章：快取為王

• 快取為王，不同的語境中所代表的快取意義不同。

• 快取的一個主要目的在於提高使用者體驗，是一種非功能性約束。

• 大型網站架構
  

• 頁面快取，不用多次渲染

  • 頁面自身對元素進行快取；

  • 服務端黃金靜態頁面或動態頁面；

• 瀏覽器快取：根據一套與伺服器約定的規則進行工作，如在http頭設定expires
  

  • Cache-Control/Expires的優先順序高於Last-Modified.ETag

• 網路快取

  • web代理快取，Squid

  • 邊緣快取，Varnish、CDN

• 服務端快取

  • msql快取（Query Cache）：
    

  • 平臺級快取：java（Ehcache，Cacheonix，Voldemort，JBoss Cache，OSCache）

  • 應用級快取：Redis、MongoDb、Memcachaed

    • redis:去中心化，通過Gossip協議交換狀態；客戶端與節點直連

• 多級快取架構：Nginx本地快取解決熱點資料快取問題；Redis分散式快取減少訪問回源率；Tomcat快取防止快取失效/崩潰之後的衝擊；資料庫換成提高查詢效率
  

第二章分散式系統理論

2.2 分散式系統概念

• 分拆鎖和分離鎖：如果一個鎖守護多個相互獨立的狀態變數，則可以分拆鎖；分拆鎖的集合會分離鎖；ConcurrentHashMap使用到分離鎖

• 分散式系統中的任何節點也都是無狀態的

• 快取雪崩：大量key在統一時間失效

  • 解決方案：即使查詢空也快取空結果，並設定較短的過期時間；單執行緒寫快取

2.3 分散式系統理論

• CAP理論（一致性，可用性，分割槽容忍性）:CAP並不是三選二，大多數情況下Ｃ和Ａ可以同時滿足，所以實質上是需要一種當Ｐ出現時的應對策略

• ACID（原子性，一致性，隔離性，一致性）

• BASE（基本可用，軟狀態，最終一致性）

• Paxos演算法：解決分散式系統一致性問題的通訊協議

  • 兩階段：Prepare，Accept

  • 進一步閱讀《從Paxos到ZooKeeper》

• 一致性演算法還有：2PC、3PC、Raft演算法、Lease機制

• MVCC（基於多版本併發控制），如InnoDB。

  • 儲存引擎會給每張表增加兩個欄位：create version和delete version

  • 查詢操作必須滿足：當前版本號>=create version且<delete version，才會被查詢到

• Gossip是一種去中心化思路的分散式協議，解決狀態在叢集中的傳播和一致性問題。

2.4 分散式系統設計策略

• 如何檢測或者；保障高可用；容錯處理；重試機制；負載均衡。

2.5 分散式系統設計實踐

• 全域性id生成

  • snowFlake：41位時間序列 + 10位機器標識 + 12位計數順序號

  • id快取，如換成1000個id

• 雜湊取模分配

  • 一致性雜湊：就是將所有的桶連成環，當有新節點加入時，只要將新節點加入位置之前的資料順時針移動到下一個節點中即可。

• 路由表；資料拆分

第三章 動手寫快取

3.1 快取定義規範：

• CachingProvider -> CacheManager -> Cache -> Entry

3.2 快取框架的實現

• 參考Ehcache、Guava

• 簡單設計的快取框架結構

  

• 工程結構和類圖

  

• SPI機制：META_INF/services下的檔案javax.cache.spi.CachingProvider

  • Service Provider Interface，是JDK內建的一種服務提供發現機制。用於為某個介面尋找服務實現的機制，有點類似IOC

  • SPI的使用約定：使用loads的迭代器會遍歷所有實現類

    

第四章 Ehcache與Guava Cache

• Ehcache

  • 快速簡單，是目前最快的java換成之一，不需要複雜配置，API易於使用與部署

  • 多種快取策略，LRU、LFU、FIFO

  • 快取資料有兩級，記憶體+磁碟，所以無需當心容量問題

  • 快取資料會在虛擬機器重啟過程中寫入磁碟，Ehcache是地一個引入快取資料持久化儲存的開源java快取框架

  • 可通過RMI、可插入API等方式做分散式快取

  • 具有快取和快取管理器的監聽介面

4.2 Ehcache使用介紹

• APP - > CacheManager -> Cache -> Element

• 架構：

  

  • Cache Replication：用於處理快取同步

  • InProcess APIS：對外開放常用的API

  • Network：通訊協議，即網路呼叫介面的方式

  • Ehcache Core：快取核心功能的實現

• 配置項：

  

• SDK使用

  

• Spring+Ehcache

  • EhCacheManagerFactoryBean用於載入Ehcache配置檔案；註解功能通過<cache:annotation-drive.......>開啟

    

  • @Cacheable @CachePut @CacheEvict @CacheConfig

4.3 Ehcache叢集介紹

• 叢集方式：RMI、JMS、Ehcache Server;

4.4 Ehcache（本地快取）的適用場景

• 場景要求：

  • 較少更新資料表，因為Ehcache作為Hibernate快取時，更新表操作會情況所有與該表相關的快取。

  • 併發以及一致性要求不嚴格，多臺伺服器快取不能實時同步；高一致要求建議使用Redis、Memcached等集中式快取。

• 本地快取+分散式快取（集中式換成 redis）

  

  • 將Ehcahe作為二級快取，當Redis宕機可以繼續抗住大量請求。

  • 採用一定的同步策略，維護本地快取和分散式快取的一致性（定時輪詢、主動通知）。

4.5 Guava Cache的使用

• 更新鎖定：當查詢一個未被快取的key時，若併發量很大，則可能都從源中讀取資料，該機制保證之讓一個請求讀源

第五章 從Memcached開始瞭解集中式快取

5.1 memcached基礎知識

• memcached伺服器並沒有分散式功能，不能進行通訊，分散式實現在於客戶端

5.2 memcached記憶體儲存

• 

• 完整的item包含如下，共32位元組

  • key：鍵

  • nkey：鍵長

  • flags：使用者定義的flag

  • nbytes：值長（包括換行符號）

  • suffix：字尾buffer

  • nsuffix：字尾長

5.3 典型問題解析

• 過期機制：

  • Lazy Expiration：只有GET和LRU會刪除過期資料，不在監視過期時間上耗費CPU時間

  • LRU

• 熱點資料

• CAS：通過版本號進行控制，gets+set

第六章 memcached周邊技術

6.1 Twemcache

• 有Twitter研發團隊根據Memcached v1.4.4開發的

• git地址：http://github.com/twitter/twemcache

6.2 Twemproxy(不關注)

6.3 Mcrouter