在我的博文里面 關于分布式系統的數據一致性問題(二) 里面主要介紹了數據分布的情況下保證一致性的情況，在第二篇文章里面，我這里提出了三個問題

訂單系統調用支付系統支付訂單，支付成功，但是返回給訂單系統數據超時，訂單還是I（初始狀態），但是此時會員帳戶余額100,會員肯定會馬上找京東罵京東，為啥不給老子發貨，我都付錢了

訂單系統調用支付系統成功，狀態也已經更新成功，但是通知倉庫發貨失敗，這個時候訂單是P（已支付）狀態，此時會員帳戶余額是100,但是倉庫不會發貨。會員也要罵京東。

訂單系統調用支付系統成功，狀態也已經更新成功，然后通知倉庫發貨，倉庫告訴訂單系統，沒有貨了。這個時候數據狀態和第二種情況一樣。

?

重點分析解決了第一個的問題以及相應的方案，發現在數據分布的環境下，很難絕對的保證數據一致性（任何一段區間），但是有辦法通過一種補償機制，最終保證數據的一致性。

?

在下面在分析一下第二個問題

• 訂單系統調用支付系統成功，狀態也已經更新成功，但是通知倉庫發貨失敗，這個時候訂單是P（已支付）狀態，此時會員帳戶余額是100,但是倉庫不會發貨。會員也要罵京東。

通過在上一篇文章里面分析過，這個相對來說是比較簡單的，我可以采取重試機制，如果發現通知倉庫發貨失敗，就一致重試，

這里面有兩種方式：

1 異步方式：通過類似MQ（消息通知）的機制，這個是異步的通知

2 同步調用：類似于遠程過程調用

對于同步的調用的方式，比較簡單，我們能夠及時獲取結果，對于異步的通知，就必須采用請求，應答的方式進行，這一點在（關于分布式系統的數據一致性問題(一)）里面有介紹。這里面就不再闡述。

?

來看看第三個問題

• 訂單系統調用支付系統成功，狀態也已經更新成功，然后通知倉庫發貨，倉庫告訴訂單系統，沒有貨了。這個時候數據狀態和第二種情況一樣。

我覺得這是一個很有意思的問題，我們還是考慮幾種解決的方案

1 在會員下單的時刻，就告訴倉庫，我要你把貨物留下來，

2 在會員支付訂單時候，在支付之前檢查倉庫有沒有貨，如果沒有貨，就告知會員木有貨物了

3 如果會員支付成功，這個時候沒有貨了，就會退款給用戶或者等待有貨的時候在發貨

?

正常情況，京東的倉庫一般都是有貨的，所以影響到的會員很少，但是在秒殺和營銷的時候，這個時候就不一定了，我們考慮假設倉庫有10臺iphone

如果采用第一種方案，

1 在會員下單的時候，相當于庫存就-1，那么用戶惡意拍下來，沒有去支付，就影響到了其他用戶的購買。京東可以設置一個訂單超時時間，如果這段時間內沒有支付，就自動取消訂單

2 在會員支付之前，檢查倉庫有貨，這種方案了，對于用戶體驗不好，但是對于京東比較好，至少我東西都賣出去了。那些沒有及時付款的用戶，只能投訴了京東無故取消訂單

3 第三種方案，這個方案體驗更不好，而且用戶感覺受到京東欺詐，但是對于京東來說，比第二種方案更有益，畢竟我還可以多賣出一點東西。

?

個人覺得，京東應該會采用第二種或者第三種方式來處理這類情況，我在微博上搜索了 “京東 無故取消訂單”，發現果真和我預料的處理方式。不過至于這里的無故取消是不是技術上的原因我不知道，如果真的是技術上的原因，我覺得京東可以采用不同的處理方案。對于秒殺和促銷商品，可以考慮第一種方案，大多數人都會直接付款，畢竟便宜啊，如果用戶搶不到便宜的東西，抱怨當然很大了。這樣可以照顧大多數用戶的體驗。對于一般的訂單，可以采用第二種或者第三種方式，這種情況下，發生付款之后倉庫沒有貨的情況會比較少，并且就算發生了，用戶也會覺得無所謂，大不了退錢嗎，這樣就可以實現自己的利益最大化而最低程度的減少用戶體驗。

?

而鐵道部在這個問題上，采用的是第一種方案，為什么和京東不一樣，就是因為用戶體驗，如果用戶把票都買了，你告訴我木有票了，旅客會殺人的。哈哈，不過鐵道部不擔心票賣不出去，第一種方案對他影響沒有什么。

?

說了這么多，就是說 分布式環境下（數據分布）要任何時刻保證數據一致性是不可能的，只能采取妥協的方案來保證數據最終一致性。這個也就是著名的CAP定理。

轉載于:https://www.cnblogs.com/aigongsi/archive/2012/09/25/2701396.html

總結

以上是生活随笔為你收集整理的关于分布式系统的数据一致性问题(三)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。