問題描述
如何在 dynamoDB 中實現 50 次寫入的事務？ (How can I implement a transaction of 50 writes in dynamoDB?)
我知道每筆交易有 25 件商品的硬性限制。但是，我確信有一種方法可以從頭開始為更多項目實施交易。我該怎麼做？
我在想，在每個項目上保留一個版本號。預先獲取所有項目，在插入期間驗證版本號是否相同。即樂觀鎖定。如果條件失敗，則還原所有失敗的項目。自然地，我可以想像還原可能會失敗，我需要對還原進行樂觀鎖定並最終陷入還原死鎖。
參考解法
方法 1:
The solution I found in the end was to implement pessimistic locking. It supports an arbitrary number of writes and reads and guarantees transactional consistency. The catch is if you're not careful, it's easy to run into deadlocks.
The idea is that you
- Create a lock table. Each row refers to a specific lock. The primary key of the lock table should be a string which I'll refer to as the lock‑key. Often you'll want to lock a specific entity so this is a reasonable format for the lock‑key
{table_name}#{primary_key}but it might be more arbitrary so any string will do. Rows in the lock table should also auto‑delete after a certain time period as per a ttl field ieTimeToLiveSpecification. - Before starting the transaction, acquire the lock. You do this by creating the row with your arbitrary lock‑key and with a conditional check that the row doesn't already exist. If it does exist the row creation should fail which means another process has already acquired the lock. You then need to poll, trying to recreate the lock row until the lock has been released.
- Once you have acquired the lock you need to keep the lock alive with a heartbeat to prevent other tasks from executing. The hearbeat process should increment a heartbeat property on the lock row which reflects the last‑active time of the lock. The ttl of the row should be greater than the heartbeat interval. Normally about double, so that the lock is not auto‑purged erroneously. If your process dies, the lock will be naturally released by the auto‑deletion of the ttl.
- If your task completes successfully it should delete the lock row freeing it up for other tasks.
(by david_adler、david_adler)