第一部分

介紹

什麼是快取？

一般來說，快取是一種技術，其中應用程式中的物件儲存在稱為快取的臨時儲存區域中。快取本身可以被認為是記憶體中的資料結構。快取物件可以是從昂貴和耗時的操作的結果到靜態網頁或後端資料庫的內容的任何東西。快取使應用程式免於獲取相同資訊（從任何資料來源）或通過在需要時儲存到中間快取記憶體並從中獲取時，重複執行相同的昂貴計算。

快取提供了幾個好處，這就是為什麼它在需要快速訪問資料的使用情況下大量利用的原因。正確的快取可以提高效能，減少資源使用，並提高響應速度。

通常，在企業應用程式中，快取記憶體充當中間的低延遲資料來源，並位於應用程式和後端系統之間。

注意：這是一個相當簡單的表示，讓你開始。

第二部分

Java快取景觀（Landscape）

Java生態系統已經為快取解決方案提供了堅實的支援，其中有幾個產品和框架可供選擇。一些廣泛使用的解決方案是：

• Hazelcast
• Oracle Coherence
• Infinispan
• Ehcache
• Apache Ignite
• GridGain
• GemFire

為了建立一組標準的API來抽象這些異構快取解決方案，JSR 107：Java臨時快取API啟動。

第三部分

JCache API (JSR 107)

什麼是JCache

JCache是用於快取的Java API。 它提供了一組通用介面和類，可用於將Java物件臨時儲存在記憶體中。

為什麼使用JCache?

快取不是Java世界中的一個新概念 - 甚至一般來說。 如前所述，有幾種企業級快取解決方案已經可用 - 因此，為什麼要在您的應用程式中已經使用的特定供應商/產品上選擇JCache？

有兩個主要好處：

可移植性：JCache允許您在客戶端應用程式中使用標準API，將其與實際的供應商實現分離。 這反過來使您的應用程式在各種JCache實現之間可移植。

關於供應商特定功能？

JCache允許使用與特定JCache介面/類相對應的等效供應商API。這將在後續章節中詳細討論。

第四部分

JCache深潛(Deep dive)

基本構件

這裡是一個簡單的程式碼段，讓你開始。詳情將在下一節中探討。

CachingProvider cachingProvider = Caching. getCachingProvider();

CacheManager cacheManager = cachingProvider. getCacheManager();

MutableConfiguration<String, String> config = new MutableConfiguration();

Cache<String, String> cache = cacheManager. createCache("JDKCodeNames",config);

cache.put("JDK1.5","Tiger");

cache.put("JDK1.6","Mustang");

cache.put("JDK1.7","Dolphin");

String jdk7CodeName = cache.get("JDK1.7");

Cache

javax.cache.Cache是一種型別安全的資料結構，允許應用程式臨時儲存資料（作為鍵值對）。它的語義類似於java.util.Map物件，但它與Map不完全相同。Cache介面通過其API暴露了幾個特性，但是下面列出了一些基本特性：

Entry

如其名稱所示，javax.cache.Entry表示快取記憶體中的鍵值對。如前所述，在快取記憶體中可以有多個這樣的條目。 條目是一個暴露最小操作的簡單實體，例如分別通過getKey和getValue方法獲取鍵和值。

CacheManager

javax.cache.CacheManager介面幫助處理快取物件，並執行諸如快取建立，銷燬和內省（獲取有關其自身的相關詳細資訊）之類的操作。讓我們來看一些常見的操作：

CachingProvider

Caching

此類用於通過getCachingProvider及其過載版本獲取javax.cache.CacheProvider物件的控制代碼。注意：還有其他方法可以獲得CachingProvider。除此之外，快取類還提供了下表中指出的其他功能：

第五部分

API概述

將JCache視為一組模組是很好的，每個模組都提供了一個特定的功能。JCache API是這樣分拆，它是很容易和直觀的，以這種方式探索它。

核心(Core)

基本構建塊部分中介紹的API構成了我們可以稱為JCache核心的大部分，因為這些類/介面（以及它們各自的提供者實現）是API的基礎。

配置（Configuration）

JCache API提供了一組標準的介面和實現，通過它們可以以程式設計方式配置快取。javax.cache.configuration.MutableConfiguration及其構建器類API有助於配置。可以配置以下快取記憶體特性：

MutableConfiguration<String,String> config = new MutableConfiguration();

config.setReadThrough(true);

到期政策（Expiration Policies）

顧名思義，可以在快取上實施到期策略，這將根據策略語義確定自動逐出或從快取中刪除條目。

注意：預設情況下，javax.cache.Cache中的條目不會過期。

JCache API提供的到期策略圍繞javax.cache.expiry.ExpiryPolicy介面及其即用型實現。

MutableConfiguration<String,String> config = new MutableConfiguration();

config.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ONE_MINUTE));

監聽器和過濾器(Listeners and Filters)

快取事件偵聽器允許客戶端程式碼針對他們可能感興趣的快取事件註冊回撥。javax.cache.event.CacheEntryListener充當提供合同（方法）的其他介面的（父）標記介面，可以按順序實現以對快取記憶體中的特定事件作出反應。 這些通常是單一的抽象方法，這使得它們非常適合Java 8 lambda風格的實現。

JCache還有過濾器，這有助於確定是否呼叫快取偵聽器。 當你想根據某些條件選擇性地呼叫對快取記憶體監聽器的呼叫時，這很方便。

CacheEntryCreatedListener<Long,TicketDetails> newTicketCreationListener = (cacheEntries) -> {

for(CacheEntryEvent ticketCreatedEvent : cacheEntries){

System.out.println(“Ticket ID: “ + ticketCreatedEvent.getKey());

System.out.println(“Ticket Details: “ + ticketCreatedEvent.getValue().toString());

}

};

CacheEntryEventFilter<Long,TicketDetails> entryEventFilter = (event) -> event.getSource().getName().equals(“TicketsCache”);

外部資源整合(External Resource Integration)

JCache API支援快取載入器和快取寫入器，這有助於將快取與外部資源整合。讀取操作是在javax.cache的幫助下完成的。 CacheLoader實現（如果在快取中找不到鍵，則會自動呼叫）從外部源檢索相應鍵的值。同樣，一個javax。 cache.CacheWriter實現同步外部源以響應快取中的更新和刪除條目。

public class TicketCacheLoaderWriter implements CacheLoader<Long, TicketDetails>, CacheWriter<Long, TicketDetails>{

  @Override

public TicketDetails load(Long ticketID) throws CacheLoaderException {

return getTicketDetails(ticketID); }

  @Override

public Map<Long, TicketDetails> loadAll(Iterable<? extends Long> ticketIDs) throws CacheLoaderException {

Map<Long, TicketDetails> tickets = new HashMap<>();

for(Long ticketID : ticketIDs){

tickets.put(ticketID, getTicketDetails(ticketID));

}

return Collections.unmodifiableMap(tickets); }

  private TicketDetails getTicketDetails(Long ticketID){

TicketDetails details = null;

//business logic to fetch ticket information

return details; }

  @Override

public void write(Cache.Entry<? extends Long, ? extends TicketDetails> ticketEntry) throws CacheWriterException{

writeTicketDetails(ticketEntry.getKey(), ticketEntry.getValue());}

  @Override

public void writeAll(Collection<Cache.Entry<? extends Long, ? extends TicketDetails>> ticketEntries) throws CacheWriterException {

for(Cache.Entry ticketEntry : ticketEntries){

          writeTicketDetails((Long) ticketEntry.getKey(), (TicketDetails) ticketEntry.getValue());}

}

@Override

public void delete(Object ticketID) throws CacheWriterException {

deleteTicket((Long) ticketID); }

  @Override

public void deleteAll(Collection<?> ticketIds) throws CacheWriterException {

for(Object ticketID : ticketIds){

deleteTicket((Long) ticketID); }

}

private void writeTicketDetails(Long ticketID, TicketDetails ticketDetails){

//business logic to delete ticket information

}

  private void deleteTicket(Long ticketID){

}

}

快取條目處理(Cache Entry Processing)

當快取在多個節點（JVM）上分散式（通常是這種情況）時，入口處理器特別有用。為了更新快取中的現有條目，可以遵循預設的一組步驟：

• 從快取獲取值
• 突變/更新它
• 將更新的值放回快取中

雖然這是完全正常的，但在效能方面（特別是當快取值很大時）效率不高。快取提供程式必須將快取值從眾多節點中的一個解序列到客戶端，然後將更新的（和序列化的）版本傳送回快取。如果連續進行多次這樣的呼叫，則問題放大。條目處理器允許客戶端通過將其傳送到快取節點而對快取條目應用變換，而不是從快取獲取條目，然後在本地進行變換。這顯著減少了網路流量以及序列化/反序列化費用。所有你需要做的是定義/實現由javax.cache.EntryProcessor介面表示的入口處理器，並在Cache.invoke或Cache.invokeAll方法中指定相同的入口處理器。

註解(Annotations)

JCache註釋（在javax.cache.annotation包中）幫助您將快取操作作為方面（從面向方面的範例角度）。這些註釋允許客戶端程式碼以宣告方式指定快取記憶體需求。 注意，這些註釋的功效取決於外部框架（如CDI，Guice等），它可以處理這些註冊並執行所需的操作。

預設情況下，JCache通過註釋公開有限數量的快取操作，但它們仍然有用。

注意：上述註釋適用於一個類（本質上是對該類中的所有方法強制執行）或一個或多個方法。

還有三個輔助註釋值得一提：

@CacheDefaults(cacheName=”TicketsCache”)

public class TicketingService{

@CachePut

public void persistTicket(long ticketID, @CacheValue TicketDetails details){

//domain logic to persist ticket information

}

@CacheResult

public TicketDetails findTicket(@CacheKey long ticketID){

TicketDetails details = null;

//execute domain logic to find ticket information

return details;

}

@CacheRemove

public void deleteTicket(@CacheKey long ticketID){

//domain logic to delete ticket information

}

@CacheRemoveAll

public void deleteAllTickets(){

    //domain logic to delete ticket information

} 

}

管理(Management)

JCache提供了MBean介面，其實現公開了快取配置和執行時效能監視相關的統計資訊。可以通過任何JMX客戶端或通過javax.management.MBeanServer API（程式化）跟蹤這些統計資訊。

MutableConfiguration<String,String> config = new MutableConfiguration();

config.setManagementEnabled(true);

config.setStatisticsEnabled(true);

SPI/擴充套件(Extensions)

javax.cache.spi包由單個介面組成：CachingProvider。我們已經看過這個類的具體細節，但讓我們從JCache供應商的角度來理解它。

JCache提供程式實現了此介面，為了使其可自動發現，在META-INF / services / javax.cache.spi.CachingProvider中聲明瞭具體類的完全限定類名，它必須在類路徑中可用。 一般來說，這是包裝在供應商實現JAR本身。 因此，您可以將此介面視為JCache提供程式的閘道器。

CacheManager cacheManager = Caching. getCachingProvider(“com.hazelcast.cache.impl.HazelcastCachingProvider”).getCacheManager();

CacheManager cacheManager = Caching. getCachingProvider(“com.tangosol.coherence.jcache.CoherenceBasedCachingProvider”).getCacheManager();

兩個世界最佳：與JCache一起使用供應商特定的功能

現在我相信你理解JCache（JSR 107）只是一個標準的API，由不同的供應商實現。標準的JCache API為您提供了一個鉤子，以利用具體的供應商特定的實現本身 - 你可以使用解包方法。 讓我們來看下錶中的細節。

注意：如果真正的CachingProvider可移植性是您正在尋找的，這顯然不推薦，因為您的應用程式將直接耦合到供應商特定的API。

//Hazelcast specific example

ICache<String,String> hazelcastICache = cache. unwrap(ICache.class);

第六部分

快取策略

快取策略是可以採用的方法，同時將快取解決方案實現為應用程式的一部分。快取層需求背後的驅動程式/用例因應用程式的需求而異。

讓我們來看看一些通常採用的快取策略以及JCache如何適應這種情況。 下表提供了快速快照，後面是一些詳細資訊：

快取拓撲（Cache Topology）

哪個快取拓撲/設定最適合您的應用程式？您的應用程式是否需要單節點快取記憶體或具有多個節點的協作快取記憶體？

策略/選項

從規範的角度來看，JCache不包括關於快取拓撲的任何細節或假設。

獨立(Standalone)：顧名思義，此設定由包含所有快取資料的單個節點組成。它相當於單節點叢集，不與其他正在執行的例項協作。

分散式(Distributed)：資料分佈在快取記憶體中的多個節點上，因此只有一個節點負責讀取特定條目。這是可能的通過分佈/分割槽的叢集
（即，所有節點具有相同數量的條目並且因此被負載平衡）。故障切換通過每個節點上的可配置備份進行處理。

複製(Replicated)：資料分佈在快取記憶體中的多個節點上，使得每個節點由完整的快取記憶體資料組成，因為每個群集節點包含所有資料;故障轉移不是一個問題。

快取模式(Cache Modes)

您希望快取記憶體在與應用程式相同的程序中執行，還是希望快取記憶體獨立存在（即服務模式）並在客戶端 - 伺服器模式下執行？

策略/選項

JCache不要求任何特定的快取模式。 它通過提供以快取記憶體模式無關方式設計的靈活API來包含這些原則。

以下模式通常在快取記憶體中是通用的：

嵌入模式(Embedded mode)：當快取和應用程式在同一個JVM中共存時，快取可以說是以嵌入模式執行。快取與應用程式JVM一起工作和死亡。 此策略應在以下情況下使用：

•      您的應用程式和快取之間的緊密耦合不是一個問題
•      應用主機具有足夠的容量（儲存器）以適應快取記憶體的需求

客戶端 - 伺服器模式(Client-server mode)：在此設定中，應用程式充當獨立（遠端）快取記憶體層的客戶端。這應該在以下情況下使用：

•      快取基礎架構和應用程式需要獨立演進
•      多個應用程式使用統一的快取層，可以在不影響客戶端應用程式的情況下擴充套件

從多個組合中選擇

不同的快取模式和拓撲使得可以有多個選項可供選擇，具體取決於具體要求。

獨立嵌入式快取：與應用程式本身位於同一JVM中的單個快取節點

分散式嵌入式快取：多個快取（叢集）節點，每個節點共同位於應用程式JVM中，並且僅負責特定的快取條目

複製嵌入式快取：多個快取（叢集）節點，每個節點位於應用程式JVM內; 這裡快取的資料被複制到所有節點

獨立客戶端 - 伺服器快取：作為與應用程式不同的程序執行的單個快取節點

分散式客戶端 - 伺服器快取：多個快取（叢集）節點，以分散式方式協作並與客戶端應用程式隔離執行

複製的客戶端 - 伺服器快取：多個快取（叢集）節點，其中整個快取資料副本存在於每個節點上，並且快取本身作為與應用程式不同的程序執行

透明快取訪問

您正在設計異構應用程式的通用快取層。 理想情況下，您希望應用程式以透明方式訪問快取記憶體，而不會通過快取記憶體實現的細節汙染其核心邏輯。

策略/選項

如JCache Deep Dive部分中所述，通過CacheLoader和CacheWriter機制已經提取了與外部系統（如資料庫，檔案儲存庫，LDAP等）的整合，這些機制分別幫助您實現直接讀寫和直寫策略。

讀取通過(Read-Through)：從整合後端儲存獲取丟失的快取條目的過程。

直寫(Write-Through)：將快取條目（建立，更新，刪除）的更改推送到後端資料儲存中的過程。

重要的是要注意，用於特定快取記憶體的直讀和直寫操作的業務邏輯被限制在快取記憶體層本身內。因此，您的應用程式與快取的詳細資訊及其備份系統記錄保持隔離。
其他策略（非JCache）

後寫(Write-Behind)：此策略利用更有效的方法，其中快取記憶體更新批量（排隊）並非同步寫入後端儲存，而不是寫入通過策略採用的急切和同步策略。例如，Hazelcast通過其com.hazelcast.core支援Write-Behind策略。MapStore介面，當write-delay-seconds配置屬性大於0.請注意，這只是一個Hazelcast Map功能，不支援通過ICache擴充套件。

重新整理提前(Fresh-Ahead)：這是另一個有趣的策略，其中快取實現允許您根據特定因素從後端儲存重新整理快取資料，這可以用條目的到期時間表示。重新載入過程本質上是非同步的。例如，Oracle Coherence支援此策略，該策略由稱為重新整理提前因子的配置元素驅動，這是快取記憶體條目的過期時間的百分比。

快取資料質量

快取到期/逐出策略從快取資料質量角度是至關重要的。如果快取未調整到使其內容過期，則它不會獲得重新整理/重新載入/與其主倉庫/系統記錄同步的機會，並且可能最終返回過時或過時的資料。

您需要確保快取實施考慮到後備資料儲存（快取後）中的資料波動性，並有效地調整快取以維護質量資料。

策略/選項

在JCache Deep Dive部分中，您遇到了JCache-AccessedExpiryPolicy，CreatedExpiryPolicy，EternalExpiryPolicy，ModifiedExpiryPolicy和TouchedExpiryPolicy中提供的預設到期策略。除了這些策略，JCache允許您通過實現javax.cache.expiry.ExpiryPolicy介面來實現自定義驅逐策略。

Flexi-Eviction（非JCache）

JCache API允許您在特定快取記憶體上強制實施到期策略;因此，它適用於該快取中的所有條目。使用Hazelcast JCache實現，您可以通過提供在快取中為每個條目指定ExpiryPolicy的功能進一步微調。這由com.hazelcast.cache.ICache介面提供支援。

ICache<String,String> hazelcastICache = cache. unwrap(ICache.class);

hazelcastICache.put(“key2”, “value2”, new TouchedExpiryPolicy(Duration.FIVE_MINUTES));