技術在處理數據存儲的最終一致性

如何現有持久性框架爲GAE，像物化，DataNucleus將，嫩枝等處理數據存儲的「最終一致」的本質？技術在處理數據存儲的最終一致性

我正在使用DatastoreService圖層中的數據存儲（我現在沒有使用這種持久性框架）。

在我的單元測試過程中，我有時會得到正確的對象數，有時候不會。這是預期的。

這是我的JUnit幫手配置：

private final LocalServiceTestHelper helper = 
    new LocalServiceTestHelper(new LocalDatastoreServiceTestConfig() 
     .setDefaultHighRepJobPolicyUnappliedJobPercentage(50));

現在，即使我已經放在PUT/GET在do-while循環與重試的方法（與4重試次數），它仍然偏出放/取實體。

那麼現在，對於那些指定的框架，他們是否能夠保證，如果我把3個對象，我會得到3個對象？如果是的話，它是如何實施的？

我能想到的唯一的事情就是使用Memcache，也就是說，我的方法將首先嚐試從它獲取實體，並且如果它錯過了這是檢查數據存儲的唯一時間。這是一種合理的方法，還是有更好的方法或正確的方法？

來源

2013-04-21 xybrek

對於Memcache而言，每一次投入和獲得成本會高嗎？在內存和CPU方面？ – 2013-04-21 06:16:10

您建議的緩存方法如何處理羣集應用程序？（多個實例讀取和寫入相同的記錄） – radai 2013-04-21 07:34:52

如果您希望您的查詢的強一致性則有兩種選擇：

）使用 ancestor 查詢。
）使用datastore get 操作，而不是查詢，他們有很強的一致性。

如果你仔細地構建你的密鑰名稱，通常可以使用gets而不是查詢。您的其他選擇，如果您需要對給定用戶「出現」一致的查詢，則應用一些小技巧：將用戶更改注入結果中。所以，如果他們改變他們的名字，並且你重定向到他們的個人資料頁面，那麼在發送他們之前將他們的改變注入結果。

來源

2013-04-21 17:34:22

好點，我記得那些基於查詢的人很難，即使我使用PreparedQuery的count方法失敗。 – xybrek 2013-04-21 17:37:52

是的，你必須使用祖先查詢，如果你想這是準確的。請記住，在某些情況下，使用祖先查詢將使用額外的索引，這意味着寫入費用會稍微高一些 - 無論是在金錢和時間方面。 – 2013-04-24 03:38:04

Objectify does 不是以任何方式，形狀或形式處理最終一致性。開發人員在使用Objectify或任何其他庫時必須牢記這一點。

圍繞查詢執行一個do/while循環，或者添加一個wait（）並不能保證強一致性。充其量，你會增加獲得最新結果的可能性，但這遠沒有確定。

Memcache在這裏也沒有提供任何保證，因爲它是不可靠的存儲。 memcache put（）函數是NO-OP是完全合法的，即什麼都不做。

要解決您的核心問題，您需要以強一致性的方式設計您的應用程序。因此，您可以使用強大的一致性數據存儲區讀取操作（如獲取或祖先查詢）。或者你可以通過HTTP傳遞一些數據。

來源

2013-04-21 08:00:29 Strom

強一致性？ – xybrek 2013-04-21 08:04:34

所以在我的單元測試中，我將不得不做一個你認爲會做的wait（）方法？我的意思是，我希望它不會失敗，即使一次，使用下面的設置：setDefaultHighRepJobPolicyUnappliedJobPercentage（50） – xybrek 2013-04-21 08:28:21

添加wait（）不會解決最終一致性，它只會增加獲取最新視圖的可能性。基本上和做循環一樣，就像你已經提到過的那樣。 – Strom 2013-04-21 13:05:15

如果您在Objectify中需要很強的一致性，那麼您可以執行祖先查詢see this article for an explanation and examples。但是，這比最終一致的查詢更加昂貴，因此儘可能地支持最終一致的查詢。

來源

2013-04-21 15:00:28

感謝您的回答。我可以生活在最終的一致性中，但不適用於用戶相關的查詢，最重要的是用於註冊系統。 – xybrek 2013-04-21 16:35:35

技術在處理數據存儲的最終一致性

回答

相關問題