排隊requiests更新客戶端或服務器端的數據？

所以我有一個可排序列的網格。在每次排序時，都會有一個類似UpdataGridSorting的操作，它會向服務器POST請求發送新數據。排隊requiests更新客戶端或服務器端的數據？

在服務器上，有一種方法可以更新數據庫中的數據。它以一種非常糟糕的方式做到這一點：沒有鎖來防止數據庫中的同步數據更新，只有更新時用於讀取的鎖。

因此我遇到了一個問題：當用戶在排序上多次點擊時，會發送幾個請求，他們可能會同時覆蓋數據並創建髒數據。

所以我的解決方法是在某些方面對請求進行排隊，並且在以前的更新完成之前不更新數據庫。哪一方最好創建隊列？

現在我的意圖是：

saveGridColumnSorting = (dataToSend, action, forceSend) -> 
    if not forceSend 
     queue.enqueue(dataToSend.id); 
    if queue.lenght > 1 and not forceSend 
     return 
    $.ajax(
      url: url + "/" + action, 
      data: dataToSend, 
      success: (data) -> 
       if (queue.lenght > 0) 
        saveGridColumnSorting(queue.dequeue()); 
     ) 
    return

另外，如果你能看到XY問題，請參考的模式或值得信賴的來源，這將有助於在你的答案來解決X。

來源

2016-01-27 cassandrad

它是什麼樣的分類？公共資源，如全球電話簿？或者只是爲了動態的每用戶顯示目的？ –

@YamMarcovic，我的答案有什麼不同？這是公共電網中的每用戶數據。你想知道傳輸的數據量或數據庫更新花費的時間嗎？ – cassandrad

那麼，在客戶端有一個隊列的方案證明它在行動。但是，發現了另一種方法：在用戶執行某些操作時及時阻止用戶界面。對列排序不太好，但仍然比排隊請求更安全。在服務器端排隊會導致複雜性增加，特別是對於MVC應用程序。

來源

2016-02-07 15:08:41 cassandrad

尤其是如果系統是針對多個用戶（就像你在評論中所說的那樣），那麼在做這個客戶端時存在明顯的風險。對於初學者來說，這是一個安全漏洞。其次，當你有多個用戶發出這些呼叫時會發生什麼？

所以它肯定應該發生在服務器上。同時，也許使用隊列執行這樣的任務並不是最明智的選擇，因爲通過這樣做，一個用戶可以輕鬆地爲其他人創建拒絕服務，通過填補隊列，甚至導致整體由於內存不足而崩潰的事情。

還有一個問題，當用戶A請求按照某種方式排序時會發生什麼情況，然後在重新讀取數據庫之前，用戶B已經提交了自己的已經處理過的排序請求。第一個用戶會不會得到錯誤的輸出，可能他們沒有意識到這一點？

爲了避免所有這些問題—和提供的，它可能在內存方面，可能沒有提供—你可能會選擇保留結果集，你將每個請求的排序的緩存副本等信息，而不是修改實際的數據庫。另外，如果數據庫引擎可以以只讀的方式進行自我排序，那麼應該使用這種方法。

來源

2016-01-27 15:54:09

通過「公共電網」，我記住這個網格在每個用戶的頁面上，而不是每個用戶共享一個網格。不同的用戶有不同的數據，當然，排序設置存儲在不同的記錄中，以便用戶只能打破他的設置。 – cassandrad

排隊requiests更新客戶端或服務器端的數據？

回答

相關問題