爲什麼只有一次語義不可行？

Question

在Erlang有最佳希望的RPC語義中，SUN RPC至少有一次，而Java RMI最多隻有一次，但沒有人擁有一次語義。

爲什麼只有一次語義似乎不可行？

例如，如果客戶端不斷重新發送唯一標記的請求，直到收到答覆並且服務器跟蹤所有處理的請求以便不重複請求。那不會是一次嗎？

Answer 1

請考慮如果服務器在執行請求和記錄它已執行請求之間發生崩潰，會發生什麼情況？

您可以通過記錄請求獲得最多一次，然後執行。如果你在兩者之間發生碰撞，那麼你已經（錯誤地）將其記錄爲已執行，所以你不會再這樣做。因此，最多一次

奇怪的是，這個（超時）是專利：http://www.freepatentsonline.com/7162512.html。除了我上面提到的，它並不能保證一次。

你至少得到一次，然後記錄下來。如果兩者之間發生碰撞，如果請求重複，則會再次執行。

但它不是一個真正可行的在任何情況下說「恰好一次」

（有網絡錯誤，而不是服務器崩潰類似的場景）

Answer 2

我認爲答案是，你需要一個無限期的時間來獲得這些語義，因爲客戶端將不得不等待來自服務器的確定結果，這可能永遠不會到來。這個要求在真實的網絡上是不切實際的。

如果客戶端曾經放棄嘗試（或者如果服務器在完成事務之前長時間關閉，或者在發出完成信號之前，取決於它執行這些事情的順序），那麼可能沒有辦法讓客戶知道請求是否被接收和處理。實際上，RPC系統可能希望遵守默認的TCP超時，所以不希望等待服務器發生明確的成功或失敗。

雖然這是一個猜測：我從來沒有設計過RPC協議。

Answer 3

像IBM的WebSphere MQ這樣的高端消息總線確實要提供一次交付。實際上，這是默認行爲（截至我上次使用WMQ時......）。他們通過Write-ahead logs和各種鎖定技術來實現這一點。

當然，我並不懷疑在他們的法律文件中的某個地方埋沒了「恰好一次」的意思，「實際上，一次」的意思是「消息可能會或可能不會被傳遞一次，不止一次，或者多次，或者少於零。」以覆蓋他們的背部，但它在絕大多數情況下都能正常工作，包括踢出電源線，將軸連接到網絡基礎設施等。