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

# 設計考量
<a name="design"></a>

其他要考慮的設計重點：
+ **錯誤處理**：如果快取因任何原因而無法使用，應用程式應繼續執行，就好像所有項目都是快取遺失一樣。快取層的存在不應將脆弱性新增至應用程式。
+ **TTL**：可以為所有快取項目設定單一 TTL 值，或根據項目 （例如 `get_item`、 `query`或 `scan`快取） 使用不同的 TTL 值。對於負快取項目 （未傳回項目的請求），也可以有不同的 TTL 值。
+ **耗用容量**：當您傳回快取的回應時，建議您調整回應中的`ConsumedCapacity`指標，以表示零讀取耗用。
+ **移除回應中繼資料**：您也應該移除回應中的 `ResponseMetadata`區段。這可避免有人看到 的風險，`RequestId`並認為它在前幾個小時的實際時間是最新的。
+ **新增快取中繼資料**：將`CacheMetadata`區段新增至回應會很有幫助。本節可以報告儲存值的時間 （用於測量過時），以及儲存值的用戶端程式庫和版本 （在從格式變更的某個版本無縫升級到另一個版本時可能很有用）。
+ **判斷資料表結構描述**：若要從寫入操作判斷主索引鍵以進行快取失效，您必須知道資料表的結構描述。您可以在每個資料表的第一次使用 （僅限一次） 時，在 ElastiCache 中使用`describe_table`呼叫和長期快取來取得此資訊。
+ **接受而不是建構用戶端**：在建構函數中接受 DynamoDB 和 Redis 用戶端執行個體 （而不是根據傳入參數在 shim 中建置它們） 的優點是它可讓建構函數的發起人決定詳細資訊，例如是否`read_from_replicas=True`應設定 。
+ **命名空間功能**：在建構函數中支援選用的命名空間非常方便，它會隔離所有快取讀取和寫入該命名空間。使用命名空間非常適合用於測試，因為每個使用不同命名空間的執行似乎從空快取開始，並且沒有先前執行的副作用。您也可以透過變更命名空間，模擬在生產環境中 清空完整快取。這可以透過自動將字首新增至每個查詢金鑰來實作。
+ **掃描快取**：很難知道是否應快取`scan`呼叫。執行一次性完整資料表掃描時，您不想使用不會再次讀取的大型掃描資料頁面來填充快取。另一方面，許多工作負載會重複掃描，特別是針對較小的資料表，以提供最新的完整資料表資料給多個下游消費者。一種危害是實作系統，其中需要兩個呼叫，而且每個呼叫都有相同的簽章 （在 TTL 期間內），以便快取產生的掃描回應。這可避免在一次性完整資料表掃描期間填入快取，同時讓緊密的掃描迴圈獲得快取的好處。第一次掃描會在快取中放置一個小型預留位置，將請求標示為已完成一次。第二次掃描會將字符值取代為實際承載，最大可達 1 MB。