# PERF03-BP05 實作利用快取的資料存取模式
<a name="perf_data_access_patterns_caching"></a>

 為快速擷取經常存取的資料，實作利用快取的存取模式。 

 **常見的反模式：** 
+  您快取的資料經常變更。 
+  您以為快取的資料能夠持久儲存且永遠可用，因而過於依賴。 
+  您未考慮快取資料的一致性。 
+  您未監控快取實作的效率。 

 **建立此最佳實務的優勢：** 將資料儲存在快取中可改善讀取延遲、讀取輸送量、使用者體驗和整體效率，並降低成本。 

 **未建立此最佳實務時的曝險等級**：中 

## 實作指引
<a name="implementation-guidance"></a>

 快取是軟體或硬體的元件，其用途在於儲存資料，以便未來請求相同的資料時，能夠更快且更有效率地提供服務。若儲存在快取中的資料遺失，可以透過重複先前的計算或從其他資料存放區提取的方式重新建構該資料。 

 資料快取可能是改善整體應用程式效能並減輕基礎主要資料來源負擔的最有效策略之一。資料可在應用程式中的多個層級快取，例如在進行遠端呼叫的應用程式內，稱為 *用戶端快取*，或者使用快速的次要服務來儲存資料，稱為 *遠端快取*。 

 **用戶端快取** 

 透過用戶端快取，每個用戶端 (查詢後端資料儲存的應用程式或服務) 都可將特定的查詢結果儲存在本機上，並在指定的時間內保留。這樣就能透過先查看本機用戶端快取，減少整體網路對資料儲存的請求數量。如果結果不存在，應用程式就可以查詢資料儲存，並將這些結果儲存在本機上。此模式可讓每個用戶端將資料儲存在最靠近的位置 (用戶端本身)，進而將延遲降至最低。用戶端也可在後端資料儲存無法使用時，繼續為部分查詢提供服務，以提高整體系統的可用性。 

 這種方法的缺點是，若有多個用戶端，則可能會將相同的快取資料儲存在本機上。這樣會導致這些用戶端之間發生重複使用儲存和資料不一致的情況。某一個用戶端可能快取了查詢的結果，而過了一分鐘後，另一個用戶端也可能執行相同的查詢，但得到不同的結果。 

 **遠端快取** 

 為了解決用戶端之間資料重複的問題，可使用快速的外部服務 (也稱為 *遠端快取)*來儲存查詢的資料。每個用戶端都會在查詢後端資料儲存之前查看遠端快取，而不會查看本機資料存放區。這種策略可讓用戶端之間的回應更趨一致、提高儲存資料的效率，以及增加快取的資料量，因為儲存空間的擴展與用戶端無關。 

 遠端快取的缺點是，整個系統可能產生較高的延遲，因為需要額外的網路跳轉來查看遠端快取。用戶端快取可與遠端快取一起使用，以提供多層次快取來改善延遲。 

### 實作步驟
<a name="implementation-steps"></a>

1.  找出可有效利用快取的資料庫、API 和網路服務。有大量讀取工作負載、高讀寫比例或擴展成本昂貴的服務，都適合使用快取。 
   +  [資料庫快取](https://aws.amazon.com/caching/database-caching/) 
   +  [啟用 API 快取以提升回應能力](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html) 

1.  確定最適合您存取模式的適當快取策略類型。 
   +  [快取策略](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Strategies.html) 
   +  [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/) 

1.  遵循適合您的資料存放區的 [快取最佳實務](https://aws.amazon.com/caching/best-practices/) 。 

1.  為所有資料設定快取失效策略，例如存留時間 (TTL)，以便在資料時效性與減輕後端資料儲存壓力之間取得平衡。 

1.  在用戶端中啟用像是自動連線重試、指數退避、用戶端逾時和連線共用等功能 (如果有的話)，因為這些功能可以改善效能和可靠性。 
   +  [最佳實務：Redis 用戶端和 Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) 

1.  設定 80% 或更高的目標來監控快取命中率。較低的值可能表示快取大小不足，或存取模式無法有效利用快取。 
   +  [我應該監控哪些指標？](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
   +  [在 Amazon ElastiCache 上監控 Redis 工作負載的最佳實務](https://www.youtube.com/watch?v=c-hTMLN35BY) 
   +  [使用 Amazon CloudWatch 監控 Amazon ElastiCache (Redis OSS) 的最佳實務](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 

1.  實作 [資料複寫](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) 將讀取卸載到多個執行個體，並改善資料讀取效能和可用性。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [使用 Amazon ElastiCache Well-Architected Lens](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WellArchitechtedLens.html) 
+  [使用 Amazon CloudWatch 監控 Amazon ElastiCache (Redis OSS) 的最佳實務](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) 
+  [我應該監控哪些指標？](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.WhichShouldIMonitor.html) 
+  [使用 Amazon ElastiCache 大幅提高效能白皮書](https://docs.aws.amazon.com/whitepapers/latest/scale-performance-elasticache/scale-performance-elasticache.html) 
+  [快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 

 **相關影片：** 
+  [Amazon ElastiCache 學習路徑](https://pages.awscloud.com/GLB-WBNR-AWS-OTT-2021_LP_0003-DAT_AmazonElastiCache.html) 
+  [專為使用 Amazon ElastiCache 最佳實務獲得成功而設計](https://youtu.be/_4SkEy6r-C4) 

 **相關範例：** 
+  [使用 Amazon ElastiCache (Redis OSS) 大幅提高 MySQL 資料庫效能](https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/)