緩存分類，應用緩存、分佈式緩存

 

 

1、應用緩存（本地緩存）

java中的本地緩存，主要包括，構造單例map、guava、ehcache 三類。

 

爲何要有本地緩存？

在系統中，有些數據，數據量小，可是訪問十分頻繁（例如國家標準行政區域數據），針對這種場景，須要將數據寫到應用的本地緩存中，以提高系統的訪問效率，減小無謂的數據庫訪問（數據庫訪問佔用數據庫鏈接，同時網絡消耗比較大），可是有一點須要注意，就是緩存的佔用空間以及緩存的失效策略。

 

爲何是本地緩存，而不是分佈式的集羣緩存？

　　       一些和業務無關的小數據緩存，沒有必要搞分佈式的集羣緩存，目前涉及到訂單和商品的數據，會直接走DB進行請求，再加上分佈式緩存的構建，集羣維護成本比較高，不太適合緊急的業務項目。

 

本地緩存做用就是提升系統的運行速度，是一種空間換時間的取捨。它實質上是一個作key-value查詢的字典。 

 

分類：

1. java jdk map/ConcurrentMap

 

適用場景：數據量小，數據沒有失效時間要求

 

 jdk map侷限性：

一、  沒有緩存大小的設置，沒法限定緩存體的大小以及存儲數據的限制（max sizelimit）；

二、  沒有緩存的失效策略（eviction policies）；

三、  沒有弱鍵引用，在內存佔用吃緊的狀況下，JVM是沒法回收的（weakrererences keys）；

四、  沒有監控統計（statistics）；

五、  持久性存儲（persistent store）；

 

 

2. ehcache

 

優勢：功能強大，有失效策略、最大數量設置等，緩存的持久化只有企業版纔有，組件集羣的緩存同步，能夠經過jgroup來實現

缺點：功能強大的同時，也使其更加複雜

 

ehcache有集羣的功能，可是ehcache仍是適合一些簡單的應用緩存，好比方法級別的，緩存方法的返回值。或者看成一個Map來存儲不禁GC管理的、能夠持久化的數據，好比爬蟲url的存儲。

 

ehcache對併發的支持

       在高併發的狀況下，使用Ehcache緩存時，因爲併發的讀與寫，咱們讀的數據有多是錯誤的，咱們寫的數據也有可能意外的被覆蓋。所幸的是Ehcache爲咱們提供了針對於緩存元素Key的Read（讀）、Write（寫）鎖。當一個線程獲取了某一Key的Read鎖以後，其它線程獲取針對於同一個Key的Read鎖不會受到限制，但其它線程（包括獲取了該Key的Read鎖的線程）若是想獲取針對同一個Key的Write鎖就不行，它須要等到針對於該Key的Read鎖釋放後才能獲取其Write鎖；當一個線程獲取了某一Key的Write鎖以後，其它線程獲取同一個Key的Read鎖或者Write鎖的請求將等待針對於該Key的Write鎖釋放後才能繼續進行，可是同一個線程獲取該Key對應的Read鎖或者Write鎖將不須要等待。獲取了對應的鎖以後，記得在再也不須要該鎖後釋放該鎖。而且須要注意不要引發死鎖。

 

配置文件依賴：ehcache.xml 

 

 

3. Guava Cache 

 Guava Cache 是單個應用運行時的本地緩存。

 Guava Cache 與 ConcurrentMap很類似，但也不徹底同樣。最基本的區別是 ConcurrentMap 會一直保存全部添加的元素，直到顯式地移除。相對地，Guava Cache 爲了限制內存佔用，一般都設定爲自動回收元素。在某些場景下，儘管 LoadingCache 不回收元素，它也是頗有用的，由於它會自動加載緩存。

Guva是google開源的一個公共java庫，相似於Apache Commons，它提供了集合，反射，緩存，科學計算，xml，io等一些工具類庫。

cache只是其中的一個模塊。使用Guva cache可以方便快速的構建本地緩存。

 

缺點就是若是要組件集羣同步的話，須要本身實現這個功能。

 

 

2、分佈式緩存

 

1. memcache

 

 

 

2. redis

Redis的特色

• KV NoSQL
• 緩存在內存
• 支持多種數據結構
• 可持久化：AOF / RDB
• 高性能、高可靠
• 支持主從複製

 

 

 

3. mongodb

 

 

 

 

4. Apache Cassandra

Apache Cassandra 是一種分佈式非關係型數據庫，具備高性能、可擴展、無中心化等特徵。Cassandra 是適用於社交網絡業務場景的數據庫，適合實時事務處理和提供交互型數據。以 Amazon 徹底分佈式的 Dynamo 數據庫做爲基礎，結合 Google BigTable 基於列族（Column Family）的數據模型，實現 P2P 去中心化的存儲。

 

 

 

 

 

3、緩存一致性

緩存預熱？

A、全量預熱，固定的時間段移除全部，而後再全量預熱

適用場景：

一、數據更新不頻繁，例如天天晚上3點更新便可的需求；

 二、數據基本沒有變化，例如全國區域性數據；

B、增量預熱（緩存查詢，沒有，則查詢數據庫，有則放入緩存）

適用場景：

一、  數據更新要求緩存中同步更新的場景

 

​集羣內部，緩存的一致性如何保證？

若是採用ehcache的話，可使用框架自己的JGroup來實現組內機器之間的緩存同步。

若是是採用google的cacheBuilder的話，須要本身實現緩存的同步。

A、非實時生效數據：數據的更新不會時時發生，應用啓動的時候更新便可，而後定時程序定時去清理緩存；

B、須要實時生效數據：啓動時可預熱也可不預熱，可是緩存數據變動後，集羣之間須要同步