轉載：https://blog.csdn.net/sinat_29581293/article/details/51956964
在數據層引入緩存，有以下幾個好處：
- 提升數據讀取速度
- 提升系統擴展能力，通過擴展緩存，提升系統承載能力
- 降低存儲成本，Cache+DB的方式可以承擔原有需要多台DB才能承擔的請求量，節省機器成本
根據業務場景，通常緩存有以下幾種使用方式
- 懶漢式(讀時觸發)：寫入DB后, 然后把相關的數據也寫入Cache
- 飢餓式(寫時觸發)：先查詢DB里的數據, 然后把相關的數據寫入Cache
- 定期刷新：適合周期性的跑數據的任務，或者列表型的數據，而且不要求絕對實時性
======================
最近關注了一些緩存框架的特性和實現，包括OSCache、JCS、Ehcache、Memcached等等，公司的兩個緩存框架，以及一個標准JSR 107（JCache），發現一些諸多類同的方面。如果你不夠熟悉以上，不妨先看看這兩篇文章：《OSCache框架源碼解析》和《Ehcache詳細解讀》，再看下面的內容也許會有更多想法。之后再思考，如果要自己去實現一套緩存框架，需要考慮哪些東西？
1、為哪些數據做緩存？
- 模型對象，這在業務邏輯層面最常見。
- 數據庫查詢結果集。
- 頁面緩存、頁面片段緩存。
- 運算結果集，尤其對於冪等性服務。
- 外部接口查詢結果。
2、緩存框架的核心：
緩存生命周期管理，很多重要特性都是圍繞它來展開的。
舉例：
3、重要特性，這些特性不一定全部要具備，但是多數都要包含：
- 一致性選擇。緩存框架的設計必須首先考慮這一點。通常我們見到的緩存框架都是最終一致性的，允許獲取數據有一定的延遲窗口。一致性關系到緩存的生命周期，是緩存的核心理念之一。
- 分級存儲。也和緩存生命周期密切相關。至少應包括內存和磁盤兩級存儲，有些緩存框架包含組網內部節點的分級等等，允許用戶管理緩存數據在不同級別存儲中的躍遷。分級存儲還包括對存儲數據的管理，以提高數據獲取的效率；包括躍遷策略的定制，比如在某一級滿足怎樣的超時策略可以發生向下躍遷。
- 規約配置，默認配置。可以支持XML、properties、DSL編程等等多種配置方式，但是最重要的是，要提供一個默認配置，允許用戶在簡單配置或者零配置的情況下使用緩存。
- 集群、分布式，這意味着一定的伸縮性。包括內部通信協議選擇，比如節點之間使用JMS、RMI或RESTful方式通信等等；包括節點熱部署和節點發現能力，這通常都使用組播消息來實現；包括集群的方式，是Server-Client群、消息總線方式還是節點對等，等等。
- 定制擴展性。尤其是淘汰算法、事件監聽、持久化策略等等，都要允許用戶方便地自定義。
4、相對較次要的特性：
- 統計能力。包括各級緩存命中情況統計，生命周期長度統計。
- 批量接口、異步接口。包括緩存分組能力。
- 緩存數據存儲校驗。
- Web支持。特指Web容器中，對於頁面存儲的額外支持。
- 免鎖數據處理。
- 緩存狀態監控。
- 無侵入式攔截，注解編程支持。
- 運行時參數調整。
……
5、核心模型應該包括哪些？
- CacheManager：模型管理對象，可以是多實例的，也可以是單實例的。
- Cache：通過CacheManager創建出來的緩存容器，內部包含了真正的緩存承載體，至少開放add/remove/flush等接口。
- CacheMap：真正的緩存承載體，大致上都是一個Map，各種類型的Map。
- CacheEntity：緩存條目，相當於CacheMap里面的每一條Entry。
- CacheEvent：緩存事件，比如CacheEntity的創建、更新、刪除等等。
- CacheEventListener：緩存事件相應的監聽器。
- CacheEvictionAlgorithm：緩存淘汰算法，常見的有LRU、LFU、FIFO等等。
--------------------------------------------------------------------------------------------------------------------------------
2012-6-10：
任何一個緩存框架，它要解決什么樣的問題？
數據的訪問、存取、計算太慢、太不穩定、太消耗資源，同時，這樣的操作存在重復性。因此希望有這樣一種中間媒介，放置在其間，只保存自己關心的數據，而不關心具體數據邏輯內容，對於重復性的操作給出響應。對於數據和服務的使用者，它是透明的。
從請求和數據流向的角度看，一個完整的緩存框架應該包括這樣幾個部分：
- 操作捕獲
- 緩存數據存儲
- 緩存數據讀取
- 緩存數據流動
因此緩存框架的功能都是圍繞數據展開的，它的核心就是緩存數據的整個生命周期。
但是其中每一項都可以拆分和解耦成許多部分，以緩存數據存儲為例，可以拆分成：
- key生成
- value封裝、元數據封裝
- 索引生成
- 文件結構生成
- 序列化、反序列化
- 淘汰算法
- 過期檢查
- 存儲數據預處理
- 持久化媒介
……轉自：http://raychase.iteye.com/blog/1549570
但是看的到的不同實現越多，越發發現難以跳出這個思維慣性的圈子了。
===============================緩存在高並發場景下常見的問題=============================
轉載：https://www.cnblogs.com/dinglang/p/6133501.html
緩存一致性問題
當數據時效性要求很高時，需要保證緩存中的數據與數據庫中的保持一致，而且需要保證緩存節點和副本中的數據也保持一致，不能出現差異現象。這就比較依賴緩存的過期和更新策略。一般會在數據發生更改的時，主動更新緩存中的數據或者移除對應的緩存。
緩存並發問題
緩存過期后將嘗試從后端數據庫獲取數據，這是一個看似合理的流程。但是，在高並發場景下，有可能多個請求並發的去從數據庫獲取數據，對后端數據庫造成極大的沖擊，甚至導致 “雪崩”現象。此外，當某個緩存key在被更新時，同時也可能被大量請求在獲取，這也會導致一致性的問題。那如何避免類似問題呢？我們會想到類似“鎖”的機制，在緩存更新或者過期的情況下，先嘗試獲取到鎖，當更新或者從數據庫獲取完成后再釋放鎖，其他的請求只需要犧牲一定的等待時間，即可直接從緩存中繼續獲取數據。
緩存穿透問題
緩存穿透在有些地方也稱為“擊穿”。很多朋友對緩存穿透的理解是：由於緩存故障或者緩存過期導致大量請求穿透到后端數據庫服務器，從而對數據庫造成巨大沖擊。
這其實是一種誤解。真正的緩存穿透應該是這樣的：
在高並發場景下，如果某一個key被高並發訪問，沒有被命中，出於對容錯性考慮，會嘗試去從后端數據庫中獲取，從而導致了大量請求達到數據庫，而當該key對應的數據本身就是空的情況下，這就導致數據庫中並發的去執行了很多不必要的查詢操作，從而導致巨大沖擊和壓力。
可以通過下面的幾種常用方式來避免緩存傳統問題：
- 緩存空對象
對查詢結果為空的對象也進行緩存，如果是集合，可以緩存一個空的集合（非null），如果是緩存單個對象，可以通過字段標識來區分。這樣避免請求穿透到后端數據庫。同時，也需要保證緩存數據的時效性。這種方式實現起來成本較低，比較適合命中不高，但可能被頻繁更新的數據。
- 單獨過濾處理
對所有可能對應數據為空的key進行統一的存放，並在請求前做攔截，這樣避免請求穿透到后端數據庫。這種方式實現起來相對復雜，比較適合命中不高，但是更新不頻繁的數據。
緩存顛簸問題
緩存的顛簸問題，有些地方可能被成為“緩存抖動”，可以看做是一種比“雪崩”更輕微的故障，但是也會在一段時間內對系統造成沖擊和性能影響。一般是由於緩存節點故障導致。業內推薦的做法是通過一致性Hash算法來解決。這里不做過多闡述，可以參照其他章節
緩存的雪崩現象
緩存雪崩就是指由於緩存的原因，導致大量請求到達后端數據庫，從而導致數據庫崩潰，整個系統崩潰，發生災難。導致這種現象的原因有很多種，上面提到的“緩存並發”，“緩存穿透”，“緩存顛簸”等問題，其實都可能會導致緩存雪崩現象發生。這些問題也可能會被惡意攻擊者所利用。還有一種情況，例如某個時間點內，系統預加載的緩存周期性集中失效了，也可能會導致雪崩。為了避免這種周期性失效，可以通過設置不同的過期時間，來錯開緩存過期，從而避免緩存集中失效。
從應用架構角度，我們可以通過限流、降級、熔斷等手段來降低影響，也可以通過多級緩存來避免這種災難。
此外，從整個研發體系流程的角度，應該加強壓力測試，盡量模擬真實場景，盡早的暴露問題從而防范。
緩存無底洞現象
該問題由 facebook 的工作人員提出的， facebook 在 2010 年左右，memcached 節點就已經達3000 個，緩存數千 G 內容。
他們發現了一個問題---memcached 連接頻率，效率下降了，於是加 memcached 節點，
添加了后，發現因為連接頻率導致的問題，仍然存在，並沒有好轉，稱之為”無底洞現象”。
目前主流的數據庫、緩存、Nosql、搜索中間件等技術棧中，都支持“分片”技術，來滿足“高性能、高並發、高可用、可擴展”等要求。有些是在client端通過Hash取模（或一致性Hash）將值映射到不同的實例上，有些是在client端通過范圍取值的方式映射的。當然，也有些是在服務端進行的。但是，每一次操作都可能需要和不同節點進行網絡通信來完成，實例節點越多，則開銷會越大，對性能影響就越大。
主要可以從如下幾個方面避免和優化：
- 數據分布方式
有些業務數據可能適合Hash分布，而有些業務適合采用范圍分布，這樣能夠從一定程度避免網絡IO的開銷。
- IO優化
可以充分利用連接池，NIO等技術來盡可能降低連接開銷，增強並發連接能力。
- 數據訪問方式
一次性獲取大的數據集，會比分多次去獲取小數據集的網絡IO開銷更小。
當然，緩存無底洞現象並不常見。在絕大多數的公司里可能根本不會遇到。