此客戶端服務器設計是否有意義？這是否實用？

Question

我一直在努力的應用程序的基本思想是允許用戶組在閃存卡的「堆棧」上進行協作。最終，應用程序將作爲客戶端 - 服務器系統（與iOS應用作爲客戶端，和一個Rails應用程序的服務器）

這種設計的要求，因爲我看到他們，就像這樣：

1. 它需要處理合並編輯順利。由於許多用戶將編輯每個堆棧，並且因爲每個客戶端可能無法在完成後立即上載其更改，因此設計需要能夠優雅地協調對共享數據的不一致更改。
2. 它需要高效。由於許多用戶將通過他們的單元連接訪問應用程序，因此我需要最大限度地減少從服務器上載和下載的數據量，以確保應用程序能夠在這些連接上快速運行，並減少已受限客戶端的數據使用量。

本來我只是走簡單的路線，讓客戶端在每次同步時向服務器發送一個「批量」報告，這意味着每個堆棧的整個本地副本將被上傳，然後服務器會處理所有這些事情，然後將整個新數據集發送到客戶端，然後將這些準確副本保存爲離線查看和編輯，然後將其合併到以前客戶端編輯的主副本中。

我看到這個問題，牢記我的設計要求，主要是它的效率非常低。客戶端應用程序不僅不得不浪費時間上傳和下載所有這些數據，還必須將所有新信息寫入其本地數據存儲區，儘管其中大部分信息與以前的副本相同。我也無法理解服務器如何以有效且合乎邏輯的方式理解衝突編輯的意義。

所以這裏就是我想出了：

每當客戶端進行了更改共享堆棧，除了改變自己的數據庫的副本，它會記下變化的包括什麼被改變，如何，何時，以及由誰改變。當客戶端下次與服務器同步時，無論在第二天還是幾天內，都會將此「收到」操作發送到服務器，而不是整個本地數據副本。

在那裏，服務器首先存儲這些行爲的後代，然後執行數據的服務器副本上的所有更改。然後，它使用這個收據數據庫來抓取自上次客戶端與數據庫同步以來對Stack的所有相關更改。只有這些信息纔會發送回客戶端，客戶端會在其本地副本上運行更改。

使用此日誌記錄了客戶端所做的所有更改，服務器可以決定哪些更改使其他更改無效（例如，如果用戶刪除了一張卡，然後在與此更改同步之前，另一用戶編輯了正常的卡，那麼刪除將失效）。雖然執行起來很複雜，但理論上這對我的合併問題來說是一個理想的解決方案。

那麼你怎麼看？

這是一個可行的解決方案？你在我的總體規劃中是否看到任何明顯的漏洞？

謝謝！

Answer 1

有一點需要注意的是不能從設備信任時間作爲算法的一部分：

Can I Rely on the iOS Device Clock Being Correct?

我關於這一點，併合並/交織處理線程會談答案。

您可能需要考慮兩個用戶是否在同一張卡上編輯同一個有衝突的數據。由於您不能相信時間，因此客戶端確實知道上次同步的最後一個「服務器時間標記」，因此您可以將所有更改記錄在最後一個同步服務器標記中。所做的就是獎勵客戶端進行同步，因爲客戶端可以確信（服務器的時間）唯一可以交換的變化。

希望有所幫助。絕對是一個複雜的話題，要做到正確（和一般）。