本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 適用於電子商務應用程式的 Amazon ElastiCache (Valkey)
電子商務應用程式受益於應用程式伺服器與資料庫之間的記憶體內快取層。執行 Valkey 的 Amazon ElastiCache 為經常存取的資料提供低於毫秒的讀取延遲，包括產品目錄項目、庫存計數、搜尋結果和使用者工作階段，可降低資料庫負載，並改善流量尖峰期間的回應時間。
## 叢集組態
根據您的資料量、輸送量需求和操作偏好設定，選擇叢集類型。
**電子商務的叢集類型比較**
| 叢集類型 | 最適合 | 擴展 | 考量事項 |
| --- | --- | --- | --- |
| 無伺服器 | 可變流量模式、新應用程式、沒有快取操作專業知識的團隊 | 自動 — 根據需求擴展運算和記憶體 | 不需要容量規劃。可變成本模型 - 您支付使用量的費用。 |
| 節點型 （啟用叢集模式） | 可預測的高輸送量工作負載，需要精細控制碎片和節點類型 | 碎片和複本的手動或自動擴展 | 需要容量規劃。固定成本模型 - 無論使用率為何，您皆需支付佈建容量的費用。每個叢集最多支援 500 個節點。 |
對於大多數電子商務應用程式，Serverless 提供最簡單的生產路徑。當您有可預測的流量基準，且需要更多對叢集拓撲、節點類型和擴展行為的控制時，請遷移至節點型叢集。
**建議的叢集設定**
| 設定 | Value | 理由 |
| --- | --- | --- |
| 引擎 | 最新穩定版本 | 使用 ElastiCache 中可用的最新穩定 Valkey 版本。與 Redis OSS 命令完全相容。提供優於先前版本的效能改善。 |
| Multi-AZ | 已啟用 | 如果主節點失敗，則自動容錯移轉至另一個可用區域中的複本。生產電子商務工作負載的必要項目。 |
| 傳輸中加密 | 已啟用 (TLS) | 加密應用程式與快取叢集之間的資料。處理使用者工作階段或任何 PII 的工作負載需要。 |
| 靜態加密 | 已啟用 | 加密磁碟上的資料 （備份、交換）。合規工作負載需要。 |
| 子網路群組 | 私有隔離子網路 (2 個以上可用AZs) | 無法存取網際網路。只能從應用程式的安全群組存取。 |
## 產品資料的關鍵設計
設計可預測、可偵錯和範圍的快取金鑰，以避免跨資料類型發生衝突。
**金鑰命名慣例**
| 資料類型 | 金鑰模式 | 值類型 | 範例 |
| --- | --- | --- | --- |
| 產品詳細資訊 | `product:{id}` | 雜湊 | `product:12345` → {name， price， description， imageUrl} |
| 庫存計數 | `inventory:{sku}` | 字串 （整數） | `inventory:SKU-A100` → 42 |
| 使用者工作階段 | `session:{sessionId}` | 雜湊 | `session:abc123` → {userId、購物車、lastAccess} |
| 搜尋結果 | `search:{queryHash}` | 字串 (JSON) | `search:sha256(q=shoes&page=1)` → 【產品 IDs】 |
| 類別清單 | `category:{slug}:page:{n}` | 清單 | `category:electronics:page:1` → 【產品 IDs】 |
關鍵設計最佳實務：
+ 使用冒號做為分隔符號，以取得可讀性和工具支援。
+ 讓金鑰保持簡短 — 長金鑰會耗用記憶體和網路頻寬。
+ 包含資料類型字首，以避免產品、工作階段和其他可能共用數值 IDs實體發生衝突。
+ 將雜湊用於多欄位物件 （產品、工作階段），以允許部分讀取和更新，而無需擷取整個值。
## 資料類型的 TTL 策略
根據資料變更的頻率和過時程度來設定 TTL time-to-live) 值，而不會影響客戶體驗。
**電子商務資料的建議 TTLs**
| 資料類型 | TTL | 失效觸發 | 理由 |
| --- | --- | --- | --- |
| 產品詳細資訊 | 5 分鐘 | 賣方編輯產品 | 產品描述和影像不常變更。短到足以合理快速地取得編輯，而不會在每次變更時明確失效。 |
| 庫存計數 | 30 秒 | 購買或補藥 | 過時的庫存可能會導致過度銷售。非常短的 TTL 可確保計數經常重新整理。購買時明確失效，以立即獲得準確性。 |
| 搜尋結果 | 60 秒 | 無 （僅限 TTL 型） | 搜尋索引會定期更新。快取可減少搜尋引擎負載。新產品會在 60 秒內出現，而不會明確失效。 |
| 使用者工作階段 | 24 小時 | 登出或工作階段到期 | 工作階段會在瀏覽期間持續存在。重新整理每個存取的 TTL，讓作用中工作階段保持運作狀態。登出時明確刪除 。 |
| 類別清單 | 2 分鐘 | 從類別新增/移除產品 | 類別頁面具有高流量。簡短快取可在瀏覽期間大幅減少資料庫查詢。 |
## 快取並行模式
快取旁模式 （也稱為延遲載入） 是電子商務應用程式最常見的快取策略。您的應用程式會先檢查快取，並只在快取遺漏時查詢資料庫。
**讀取路徑 （虛擬程式碼）**
```
FUNCTION getProduct(productId):
cacheKey = "product:" + productId
// Step 1: Check the cache
cachedValue = cache.GET(cacheKey)
IF cachedValue exists:
RETURN deserialize(cachedValue) // Cache hit — sub-millisecond
// Step 2: Cache miss — query database
product = database.query("SELECT * FROM products WHERE id = ?", productId)
IF product not found:
RETURN null
// Step 3: Write to cache with TTL
cache.SET(cacheKey, serialize(product), EXPIRE = 300) // 5 minutes
RETURN product
```
**寫入路徑 （虛擬程式碼）**
```
FUNCTION updateProduct(productId, updatedFields):
// Step 1: Update the database (source of truth)
database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)
// Step 2: Invalidate the cache (don't update it)
cache.DELETE("product:" + productId)
// Next read will trigger a cache miss and repopulate from database
```
**重要**
一律使 （刪除） 無效，而不是在寫入時更新快取。這可減少過時讀取覆寫較新值的競爭條件窗口。下一個讀取會從資料庫重新填入快取，這是事實的來源。請注意，較窄的競爭條件仍然存在 - 如果並行讀取在寫入發生之前從資料庫擷取資料，則可以在快取金鑰刪除之後使用過時的資料重新填入快取。對於大多數電子商務工作負載，短 TTL 會讓此成為可接受的。如果您需要嚴格的一致性，請使用分散式鎖定或版本化寫入。
**處理快取失敗**
```
FUNCTION getProductWithFallback(productId):
TRY:
RETURN getProduct(productId) // Normal cache-aside path
CATCH cacheConnectionError:
// Cache is unavailable — fall back to database directly
RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
// Log the error, trigger an alarm, but don't fail the request
```
設計您的應用程式，讓快取失敗降低效能 （回應較慢），但不會中斷功能。資料庫做為備用。
## 快取失效策略
失效可確保使用者在更新後看到目前的資料。根據必須多快顯示變更，選擇策略。
**失效方法**
| 方法 | 運作方式 | 使用情況 |
| --- | --- | --- |
| 寫入時刪除 | 應用程式會在更新資料庫後立即刪除快取金鑰。 | 大部分寫入 （產品編輯、庫存變更）。簡單、可靠，可避免過時的資料。 |
| 僅限 TTL 過期 | 不要使 失效 - 讓 TTL 自然過期。 | 可接受短暫過時的資料 （搜尋結果、類別清單、分析）。 |
| 事件驅動失效 | 背景程序會接聽資料庫變更事件，並使受影響的金鑰失效。 | 寫入路徑和快取位於不同服務的系統，或單一資料庫變更影響許多快取金鑰的系統。 |
對於也使用 Amazon CloudFront 作為 CDN 層的市場應用程式，請跨兩個層協調失效：刪除 ElastiCache 金鑰*並*傳送 CloudFront 快取失效 （或快取標籤失效），讓使用者在應用程式和邊緣層查看更新的內容。
## 連線管理
+ **使用連線集區** — 為每個快取操作建立新的 TLS 連線會增加延遲。維護持久性連線集區，並在請求之間重複使用它們。
+ **設定連線逾時** — 使用短連線逾時 (1–2 秒） 和較短的命令逾時 (100–500 毫秒）。如果快取未快速回應，請返回資料庫，而不是封鎖請求。
+ **正常處理容錯移轉** — 發生異地同步備份容錯移轉時，連線至舊的主要中斷。您的連線集區應該會偵測中斷的連線，並自動重新連線。大多數用戶端程式庫都會處理此問題，但請驗證測試中的行為。
+ **使用叢集的組態端點** — 針對啟用的叢集模式，請連線至組態端點，而不是個別節點端點。組態端點會自動將請求路由到正確的碎片。
## 要監控的關鍵指標
**電子商務快取的建議 Amazon CloudWatch 警示**
| 指標 | Threshold | Period | Action |
| --- | --- | --- | --- |
| CacheHitRate | < 80% | 5 分鐘。 | 調查 — 低命中率表示您的 TTLs 可能太短、金鑰設計不佳或工作集超過記憶體。 |
| EngineCPUUtilization | > 70% | 5 分鐘。 | 向上擴展 （較大的節點） 或向外擴展 （更多碎片）。高 CPU 表示快取處理的命令超過其可有效處理的次數。 |
| DatabaseMemoryUsagePercentage | > 80% | 5 分鐘。 | 移出的風險。增加記憶體 （擴展） 或減少儲存的資料 （較短TTLs、較少的快取資料類型）。 |
| 移出 | > 0 持續 | 1 分鐘 | 快取已滿，並移除資料以騰出空間。增加快取遺漏。在較不重要的資料上擴展記憶體或減少 TTLs。 |
| CurrConnections | > 用戶端集區大小的 80% | 5 分鐘。 | 接近耗盡的連線集區。增加集區大小、減少連線保留時間，或調查應用程式程式碼中的連線洩漏。以您應用程式設定的集區大小為基礎，而不是伺服器上限 (65，000)。 |
## 常見問答集
### 我應該何時使用無伺服器與節點型？
當您的流量無法預測 （新市場、季節性尖峰）、您想要避免容量規劃，或您的團隊沒有快取操作專業知識時，請使用 Serverless。當您的流量模式穩定、您需要精細控制碎片，或持續輸送量使節點型更具成本效益時，切換到節點型。
### 我應該使用 Valkey 或 Redis OSS 嗎？
使用 Valkey 進行新部署。Valkey 是新 ElastiCache 叢集的預設引擎，與 Redis OSS 命令和資料結構完全相容，並接收持續開發。現有的 Redis OSS 叢集會繼續運作：在方便使用就地引擎升級時遷移至 Valkey。
### 當快取無法使用時會發生什麼情況？
您的應用程式應將快取視為最佳化，而非相依性。如果快取無法使用，請返回直接查詢資料庫。回應時間將較高，但應用程式仍能正常運作。啟用異地同步備份時，完全快取無法使用的情況很少 – 容錯移轉至複本通常會在 30 秒內完成。
### 如何估計我需要的記憶體？
計算： （要快取的唯一項目數量） × （每個項目的平均大小） × (Valkey 資料結構的額外負荷係數為 1.2)。額外負荷會因物件大小和資料類型而異，較小物件的額外負荷會按比例增加。例如，100，000 個產品，每個 2 KB，額外負荷 1.2 倍 = 大約 240 MB。新增工作階段資料、搜尋結果和庫存計數。從頭頂開始 （使用 60% 的可用記憶體做為您的目標），並監控要調整的 DatabaseMemoryUsagePercentage 指標。