

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 常見 ElastiCache 使用案例及 ElastiCache 如何提供協助
<a name="elasticache-use-cases"></a>

不論是提供最新的新聞、前 10 名排行榜、產品目錄或是出售活動門票，速度都是遊戲的重點。傳遞內容的速度，會顯著影響您網站和商業的成功與否。

在「[對於耐心不足的 Web 使用者來說，一眨眼的等待時間也嫌太長](http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0)」報導中，New York Times 指出，使用者可以注意到競爭網站之間 250 毫秒 (1/4 秒) 的差異。使用者傾向於放棄速度較慢的網站，而選擇速度較快的網站。Amazon 完成的測試，引自[網頁載入時間與訪客之間的關聯](http://pearanalytics.com/blog/2009/how-webpage-load-time-related-to-visitor-loss/)，指出每載入 100 毫秒 (1/10 秒) 的負載時間，銷售會下降 1%。

當某人想要資料，若這些資料已經過快取，您就可以更迅速提供資料。無論是網頁還是影響商業決策的報告，都適用同樣的道理。您的企業是否能快取您的網頁、以最短的延遲將其傳遞？

很顯然，需要最大的項目，就是您最想要快取的。但為何不快取較不常用的項目？ 即使是經過最佳化的資料庫查詢或遠端 API 呼叫，也會比從記憶體內快取擷取一般金鑰慢很多。*「明顯較慢」*這件事，就會造成客戶流失。

下列範例說明 ElastiCache 能提升您應用程式整體效能的一些方式。

**Topics**
+ [記憶體內資料存放區](#elasticache-use-cases-data-store)
+ [遊戲排行榜](#elasticache-for-redis-use-cases-gaming)
+ [訊息 (Pub/Sub)](#elasticache-for-redis-use-cases-messaging)
+ [建議資料 （雜湊）](#elasticache-for-redis-use-cases-recommendations)
+ [生成式 AI 應用程式的語意快取](#elasticache-for-redis-use-cases-semantic-caching)
+ [ElastiCache 客戶見證](#elasticache-use-cases-testimonials)

## 記憶體內資料存放區
<a name="elasticache-use-cases-data-store"></a>

記憶體內鍵/值存放區的主要目的，是提供超快速 (亞毫秒級延遲) 和經濟實惠的資料複本存取。大多數資料存放區，都具有經常存取但不常更新的資料區域。此外，對資料庫進行查詢，總是比在鍵/值對快取中找出鍵要更慢，且費用更高。執行某些資料庫查詢的費用特別昂貴。其中一個例子是涉及跨多個資料表之聯結的查詢，或具有密集型計算的查詢。透過快取這類查詢結果，您只需支付查詢的一次性費用。然後就可以快速擷取資料多次，而無需重新執行查詢。

### 我應該快取什麼？
<a name="elasticache-use-cases-data-store-what-to-cache"></a>

在決定要快取哪些資料時，請考慮下列因素：

**速度和費用** - 從資料庫取得資料，總是比從快取要來得慢，且費用更高。某些資料庫查詢在本質上比其他查詢更慢且更昂貴。例如，在多個資料表上執行聯結查詢，與簡單的單一資料表查詢相比，前者的速度明顯較慢且費用更高。如果需要以較慢且費用較高的查詢方式來取得所需資料，則適合改為快取。如果需要以相對快速和簡單的查詢來取得資料，仍可能適合使用快取，具體取決於其他因素。

**資料和存取模式** - 判斷要快取的內容也涉及了解資料本身及其存取模式。例如，快取快速變動或很少存取的資料並沒有意義。若要讓快取提供真正的益處，資料應為相對靜態且經常存取。例如社群媒體網站上的個人資料。相反地，如果快取資料不能提供速度或成本優勢，則不建議快取資料。例如，快取會傳回搜尋結果的網頁並沒有意義，因為查詢和結果通常都是獨一無二的。

**過時** - 根據定義，快取的資料是過時的資料。即使某些情況下並非過時，仍應該一律視為過時。若要判斷您的資料是否適合快取，您需要判斷應用程式對過時資料的容錯能力。

您的應用程式或許能承受某個內容中的過時資料，但不能承受另一個內容中的過時資料。例如，假設您的網站提供公開交易股票價格。在附有免責聲明，表示可能有 *n* 分鐘延遲的情況下，您的客戶可能會接受一定程度的過時性。但是，如果是向銷售或購買的經紀人提供股票價格，您需要即時的資料。

如果下列描述成立，便可考慮快取您的資料：
+ 與快取擷取相比，取得您資料的速度緩慢或費用高昂。
+ 使用者經常存取您的資料。
+ 您的資料相對保持無變動，或者資料會快速變動但過時性不夠成大問題。

如需詳細資訊，請參閱[Memcached 的快取策略](Strategies.md)

## 遊戲排行榜
<a name="elasticache-for-redis-use-cases-gaming"></a>

使用 Valkey 或 Redis OSS 排序集，您可以將排行榜的運算複雜性從應用程式移至叢集。

排行榜 (例如遊戲得分的前 10 名) 的運算方式很複雜。當有大量玩家同時遊戲且分數不斷變動時，運算尤其複雜。Valkey 和 Redis OSS 排序集保證唯一性和元素排序。使用排序集，每次將新元素新增至排序集時，都會即時重新排名。然後會以正確的數字順序新增至集合。

在下圖中，您可以查看 ElastiCache 遊戲排行榜的運作方式。

![影像：ElastiCache 遊戲排行榜圖表](http://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Gaming.png)


**Example Valkey 或 Redis OSS 排行榜**  
在此範例中，四名玩家及其分數會透過 `ZADD` 輸入排序清單中。`ZREVRANGEBYSCORE` 命令會依照分數列出玩家，由高至低。接下來，`ZADD` 會用於更新 June 的分數 (透過覆寫現有項目)。最後，`ZREVRANGEBYSCORE` 會依照分數由高至低列出玩家。清單顯示 June 的排名已上升。  

```
ZADD leaderboard 132 Robert
ZADD leaderboard 231 Sandra
ZADD leaderboard 32 June
ZADD leaderboard 381 Adam
			
ZREVRANGEBYSCORE leaderboard +inf -inf
1) Adam
2) Sandra
3) Robert
4) June

ZADD leaderboard 232 June

ZREVRANGEBYSCORE leaderboard +inf -inf
1) Adam
2) June
3) Sandra
4) Robert
```
下列命令可讓 June 得知她在所有玩家中的排名。由於排名以零為起始，*ZREVRANK* 會為排名第二的 June 傳回 1。  

```
ZREVRANK leaderboard June 
1
```

如需詳細資訊，請參閱有關已排序集的 [Valkey 文件](https://valkey.io/topics/sorted-sets/)。

## 訊息 (Pub/Sub)
<a name="elasticache-for-redis-use-cases-messaging"></a>

當您傳送電子郵件時，您會將郵件傳送給一或多個指定的收件人。在 Valkey 和 Redis OSS pub/sub 範式中，您會傳送訊息到特定頻道，不知道誰會收到它。訂閱該頻道的人員會收到訊息。例如，假設您訂閱了 *news.sports.golf* 頻道。您和 *news.sports.golf* 頻道的其他訂閱者，都會收到發佈至 *news.sports.golf* 頻道的所有訊息。

Pub/sub 功能與任何金鑰空間無關。因此，在任何層級上都不會造成干擾。在下圖中，您可以找到 ElastiCache 訊息與 Valkey 和 Redis OSS 的圖例。

![影像：ElastiCache 訊息圖表](http://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-PubSub.png)


### 訂閱
<a name="elasticache-use-cases-messaging-subscribing"></a>

若要接收某頻道的訊息，您需訂閱該頻道。您可以訂閱單一頻道、多個頻道或所有匹配某種模式的頻道。若要取消訂閱，請從您訂閱的指定頻道取消訂閱。或者，如果您使用模式比對功能進行訂閱，取消訂閱時也會使用與之前相同的模式。

**Example - 訂閱單一頻道**  
若要訂閱單一頻道，請使用 SUBSCRIBE 命令來指定您希望訂閱的頻道。在下列範例中，用戶端訂閱了 *news.sports.golf* 頻道。  

```
SUBSCRIBE news.sports.golf
```
一段時間過後，用戶端使用 UNSUBSCRIBE 命令來指定希望取消訂閱的頻道，並取消了訂閱。  

```
UNSUBSCRIBE news.sports.golf
```

**Example - 訂閱多個特定頻道**  
若要訂閱多個特定頻道，請使用 SUBSCRIBE 命令來列出頻道。在下列範例中，用戶端同時訂閱了*news.sports.golf*、*news.sports.soccer* 和 *news.sports.skiing* 頻道。  

```
SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
```
若要取消訂閱特定頻道，請使用 UNSUBSCRIBE 命令並指定希望取消訂閱的頻道。  

```
UNSUBSCRIBE news.sports.golf
```
若要取消訂閱多個頻道，請使用 UNSUBSCRIBE 命令並指定希望取消訂閱的頻道。  

```
UNSUBSCRIBE news.sports.golf news.sports.soccer
```
若要取消所有訂閱，請使用 `UNSUBSCRIBE` 並指定每個頻道。或使用 `UNSUBSCRIBE` 且不指定頻道。  

```
UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
```
或  

```
UNSUBSCRIBE
```

**Example - 使用模式匹配的訂閱**  
用戶端可以使用 PSUBSCRIBE 命令來訂閱匹配某種模式的所有頻道。  
在下列範例中，用戶端訂閱了所有體育頻道。您不需要分別列出所有體育頻道，如同使用 `SUBSCRIBE`。而是可透過 `PSUBSCRIBE` 命令使用模式比對功能。  

```
PSUBSCRIBE news.sports.*
```

**Example 取消訂閱**  
若要取消訂閱這些頻道，請使用 `PUNSUBSCRIBE` 命令。  

```
PUNSUBSCRIBE news.sports.*
```
+ 傳送至 [P]SUBSCRIBE 命令及 [P]UNSUBSCRIBE 命令的頻道字串必須相符。您不能對 *news.\** 使用 `PSUBSCRIBE`、對 *news.sports.\** 使用 `PUNSUBSCRIBE`，也不能對 *news.sports.golf* 使用 `UNSUBSCRIBE`。
+ `PSUBSCRIBE` 和 `PUNSUBSCRIBE` 不適用於 ElastiCache Serverless。

### 發布
<a name="elasticache-for-redis-use-cases-messaging-publishing"></a>

若要向某頻道中的所有訂閱者傳送訊息，請使用 `PUBLISH` 命令，指定頻道和訊息。下列範例將「這是個晴朗的星期六，我要前往連結了。」訊息發佈 到 *news.sports.golf* 頻道。

```
PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links."
```

用戶端無法發佈至其訂閱的頻道。

如需詳細資訊，請參閱 Valkey 文件中的 [Pub/Sub](https://valkey.io/topics/pubsub)。

## 建議資料 （雜湊）
<a name="elasticache-for-redis-use-cases-recommendations"></a>

在 Valkey 或 Redis OSS 中使用 INCR 或 DECR 可讓編譯建議變得簡單。當每次有使用者「喜歡」某項產品時，會遞增 *item:productID:like* 計數器。當每次有使用者「不喜歡」某項產品時，會遞增 *item:productID:dislike* 計數器。使用雜湊，您也可以維護喜歡或不喜歡產品的每個人清單。

**Example - 喜歡和不喜歡**  

```
INCR item:38923:likes
HSET item:38923:ratings Susan 1
INCR item:38923:dislikes
HSET item:38923:ratings Tommy -1
```

## 生成式 AI 應用程式的語意快取
<a name="elasticache-for-redis-use-cases-semantic-caching"></a>

由於與大型語言模型 (LLMs。您可以使用 ElastiCache 在生成式 AI 應用程式中進行語意快取，從而降低 LLM 推論呼叫的成本和延遲。透過語意快取，您可以使用向量型比對來尋找目前和先前提示之間的相似性，以傳回快取的回應。如果使用者的提示詞類似於先前的提示詞，則會傳回快取的回應，而不是進行新的 LLM 推論呼叫，從而降低生成式 AI 應用程式的成本，並提供更快的回應來改善使用者體驗。您可以設定提示的相似性閾值並套用標籤或數值中繼資料篩選條件，以控制哪些查詢路由至快取。

ElastiCache 向量搜尋提供的內嵌即時索引更新有助於確保快取隨著使用者提示和 LLM 回應流程持續更新。這種即時索引對於保持快取結果和快取命中率的新鮮度至關重要，特別是對於尖峰流量。此外，ElastiCache 透過成熟快取基本概念簡化語意快取的操作，例如每個金鑰 TTLs、可設定的移出策略、原子操作，以及豐富的資料結構和指令碼支援。

**生成式 AI 助理和代理器的記憶體**

您可以使用 ElastiCache 實作記憶體機制，將跨工作階段對話歷史記錄呈現給 LLMs，以提供更個人化的內容感知回應。對話式記憶體可讓生成式 AI 助理和客服人員保留和使用過去的互動，以個人化回應並改善相關性。不過，簡單地將所有先前的互動彙總到提示中是無效的，因為不相關的額外權杖會增加成本、降低回應品質，以及超出 LLM 內容視窗的風險。反之，您可以使用向量搜尋來擷取並提供每個 LLM 調用內容中最相關的資料。

ElastiCache for Valkey 提供與開放原始碼記憶體層的整合，提供內建連接器來存放和擷取 LLM 應用程式和代理程式的記憶體。ElastiCache 的向量搜尋提供快速索引更新、讓記憶體保持最新狀態，並讓新的記憶體立即可搜尋。低延遲向量搜尋可讓記憶體查詢快速進行，使其能夠實作在每個請求的線上路徑中，而不只是背景任務。除了向量搜尋之外，ElastiCache for Valkey 還提供工作階段狀態、使用者偏好設定和功能旗標的快取基本概念，提供單一服務，將短期工作階段狀態和長期「記憶體」存放在一個資料存放區中。

**擷取擴增產生 (RAG)**

RAG 是在提示中提供 LLMs up-to-date的程序，以改善回應的相關性。RAG 透過使用實際資料來源將輸出接地，減少幻覺並改善事實準確性。RAG 應用程式使用向量搜尋，從知識庫擷取語意相關內容。ElastiCache 提供的低延遲向量搜尋，適合在具有數百萬個向量以上的大型資料集的工作負載中實作 RAG。此外，線上向量索引更新的支援使得 ElastiCache 適合上傳工作流程需要確保任何上傳資料可立即搜尋的助理。代理式 AI 系統中的 RAG 可確保代理程式擁有up-to-date資訊，以準確執行動作。低延遲向量搜尋對於代理式 AI 系統中的 RAG 來說也很重要，其中單一查詢可以觸發多個 LLM 呼叫，並從基礎向量搜尋堆疊延遲。

下圖說明使用 ElastiCache 實作語意快取、記憶體機制和 RAG 來增強生產中生成式 AI 應用程式的範例架構。

![生成式 AI 助理執行的語意搜尋圖表。](http://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/dg/images/vector-search-gen-ai1.png)


**語意搜尋**

向量搜尋會根據意義或功能的親近度擷取最相關的文字、語音、影像或影片資料。此功能可讓機器學習應用程式依賴於各種資料模式的相似性搜尋，包括建議引擎、異常偵測、個人化和知識管理系統。建議系統使用向量表示法來擷取使用者行為和項目特性中的複雜模式，讓他們能夠建議最相關的內容。ElastiCache 的向量搜尋非常適合這些應用程式，因為其近乎即時的更新和低延遲，使得相似性比較能夠根據即時使用者互動提供即時、高度相關的建議。

## ElastiCache 客戶見證
<a name="elasticache-use-cases-testimonials"></a>

若要了解 Airbnb、PBS、Esri 和其他企業如何使用 Amazon ElastiCache，透過改善客戶體驗來促進業務成長，請參閱[其他人如何使用 Amazon ElastiCache](https://aws.amazon.com/elasticache/testimonials/)。

您也可以觀看其他 ElastiCache 客戶使用案例的[教學課程影片](Tutorials.md#tutorial-videos)。