快取寫入行為 - AWS 方案指引

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

快取寫入行為

本指南說明讀取快取,其中項目會在第一次讀取時快取。寫入快取會在寫入操作期間將項目推送至快取,但本指南不建議這樣做,原因有兩個:

  • 寫入項目時,沒有跡象指出它會很快被讀取,而且寫入未使用的快取項目會很浪費。

  • 快取的項目可能會在不同的簽章金鑰下快取多次。例如,不同的投影表達式會產生不同的快取項目。因此,不清楚您應該在請求進入之前將項目存放在哪個簽章金鑰下。您可能會認為只完整快取項目一次更為優雅,如果請求指定ProjectionExpression參數,請在快取包裝函式中即時套用投影。遺憾的是,這增加了很大的複雜性,因為它需要實作非微不足道ProjectionExpression文法。讓快取包裝函式變得非常簡單,因此它只會快取先前發生的請求,並盡可能避免建立新的回應。讓資料庫成為 ProjectionExpression 解譯的唯一位置。這可消除簡單的寫入快取模型。

不過,寫入操作可以很智慧,而且可以主動使先前存放且與寫入項目相關的任何項目快取項目失效。這可讓項目快取保持新狀態,而不必等待 TTL 過期。快取項目會在下一次讀取時重新填入。

注意

相較於類似設計的關聯式資料庫快取整合,此 DynamoDB 整合的主要優點是每次寫入 DynamoDB 時一律會指定所寫入項目的主要金鑰。讀取快取可以監看寫入呼叫,並執行確切的立即項目快取失效。當您使用關聯式資料庫時, UPDATE陳述式不會識別可能受影響的項目,而且除了透過 TTL 之外,沒有被動方式使快取的資料列項目失效。

寫入呼叫會實作此邏輯流程:

  • 針對資料庫執行寫入操作。

  • 如果操作成功,請擷取寫入的資料表和主索引鍵。

  • 使任何與主索引鍵相關的項目快取項目失效。

需要一些內務,才能完成最後一個步驟。項目快取項目存放在其簽章的雜湊下,因此必須知道要使哪些金鑰失效。您可以透過在快取中維護項目主索引鍵與該主索引鍵相關聯的已儲存簽章清單之間的映射來執行此操作。這是必須失效的項目清單。

以下是先前提供的資料表:

虛擬程式碼

ElastiCache 金鑰計算

ElastiCache 值

get_item(t1, k1, p1)

hash('get', t1, k1, p1) = 0xad4c812a

{ 'Item': … }

get_item(t1, k1, p2)

hash('get', t1, k2, p2) = 0x045deaab

{ 'Item': … }

get_item(t1, k2, p1)

hash('get', t1, k2, p1) = 0x9cda78af

{ 'Item': … }

以及先前的內務管理資料表:

作業

ElastiCache 金鑰計算

ElastiCache 值

資料表 的追蹤項目清單t1,索引鍵 k1

hash('list', t1, k1)

( 0xad4c812a, 0x045deaab )

資料表 的追蹤項目清單t1,索引鍵 k2

hash('list', t1, k2)

( 0x9cda78af )

假設資料表上有寫入操作,t1且項目具有主索引鍵 k1。下一個步驟是使與該項目相關的項目失效。

以下是完整的邏輯:

  • 針對資料庫執行寫入操作。

  • 如果操作成功,請擷取寫入的資料表和主索引鍵。

  • 從快取中提取與該主索引鍵相關聯的已儲存雜湊簽章清單。

  • 使這些項目快取項目失效。

  • 刪除該主索引鍵的內務清單。

在項目寫入操作中,有一個方法可以主動使查詢快取項目失效,真是太棒了。不過,為此建立設計非常困難,因為幾乎無法有效且可靠地判斷哪些快取查詢結果會受到更新項目的影響。因此,查詢快取項目沒有比透過 TTL 設定過期更好的選項。