在我的博文裡面關於分布式系統的資料一致性問題(二)
裡面主要介紹了資料分布的情況下保證一致性的情況，在第二篇文章裡面，我這裡提出了三個問題
訂單系統呼叫支付系統支付訂單，支付成功，但是返回給訂單系統資料超時，訂單還是
i（初始狀態），但是此時會員帳戶餘額
100,
會員肯定會馬上找京東罵京東，為啥不給老子發貨，我都付錢了
訂單系統呼叫支付系統成功，狀態也已經更新成功，但是通知倉庫發貨失敗，這個時候訂單是
p（已支付）狀態，此時會員帳戶餘額是
100,
但是倉庫不會發貨。會員也要罵京東。
訂單系統呼叫支付系統成功，狀態也已經更新成功，然後通知倉庫發貨，倉庫告訴訂單系統，沒有貨了。這個時候資料狀態和第二種情況一樣。
重點分析解決了第乙個的問題以及相應的方案，發現在資料分布的環境下，很難絕對的保證資料一致性（任何一段區間），但是有辦法通過一種補償機制，最終保證資料的一致性。
在下面在分析一下第二個問題
這裡面有兩種方式：
1 非同步方式：通過類似
mq（訊息通知）的機制，這個是非同步的通知 2
同步呼叫：類似於遠端過程呼叫
對於同步的呼叫的方式，比較簡單，我們能夠及時獲取結果，對於非同步的通知，就必須採用請求，應答的方式進行，這一點在（
關於分布式系統的資料一致性問題(一)
）裡面有介紹。這裡面就不再闡述。
來看看第三個問題
我覺得這是乙個很有意思的問題，我們還是考慮幾種解決的方案 1
在會員下單的時刻，就告訴倉庫，我要你把貨物留下來， 2
在會員支付訂單時候，在支付之前檢查倉庫有沒有貨，如果沒有貨，就告知會員木有貨物了 3
如果會員支付成功，這個時候沒有貨了，就會退款給使用者或者等待有貨的時候在發貨
正常情況，京東的倉庫一般都是有貨的，所以影響到的會員很少，但是在秒殺和營銷的時候，這個時候就不一定了，我們考慮假設倉庫有10臺
iphone
如果採用第一種方案，
1 在會員下單的時候，相當於庫存就
-1，那麼使用者惡意拍下來，沒有去支付，就影響到了其他使用者的購買。京東可以設定乙個訂單超時時間，如果這段時間內沒有支付，就自動取消訂單 2
在會員支付之前，檢查倉庫有貨，這種方案了，對於使用者體驗不好，但是對於京東比較好，至少我東西都賣出去了。那些沒有及時付款的使用者，只能投訴了京東無故取消訂單 3
第三種方案，這個方案體驗更不好，而且使用者感覺受到京東欺詐，但是對於京東來說，比第二種方案更有益，畢竟我還可以多賣出一點東西。
個人覺得，京東應該會採用第二種或者第三種方式來處理這類情況，我在微博上搜尋了
「京東無故取消訂單」，發現果真和我預料的處理方式。不過至於這裡的無故取消是不是技術上的原因我不知道，如果真的是技術上的原因，我覺得京東可以採用不同的處理方案。對於秒殺和**商品，可以考慮第一種方案，大多數人都會直接付款，畢竟便宜啊，如果使用者搶不到便宜的東西，抱怨當然很大了。這樣可以照顧大多數使用者的體驗。對於一般的訂單，可以採用第二種或者第三種方式，這種情況下，發生付款之後倉庫沒有貨的情況會比較少，並且就算發生了，使用者也會覺得無所謂，大不了退錢嗎，這樣就可以實現自己的利益最大化而最低程度的減少使用者體驗。
而鐵道部在這個問題上，採用的是第一種方案，為什麼和京東不一樣，就是因為使用者體驗，如果使用者把票都買了，你告訴我木有票了，旅客會殺人的。哈哈，不過鐵道部不擔心票賣不出去，第一種方案對他影響沒有什麼。
說了這麼多，就是說
分布式環境下（資料分布）要任何時刻保證資料一致性是不可能的，只能採取妥協的方案來保證資料最終一致性。這個也就是著名的
cap定理。
關於分布式系統的資料一致性問題 一
關於分布式系統的資料一致性問題 一 最近寫了乙個關於 鐵道部購票系統的若干文章 鐵道部新客票系統的設計 一 鐵道部新客票系統的設計 二 鐵道部新客票系統的設計 三 正好遇到乙個博友，諮詢了乙個問題，這個問題正好可以作為分布式系統的資料一致性的簡單例子，當然，這個只是比較簡單的情況 現在先丟擲問題，假...
關於分布式系統的資料一致性問題 三
本文轉至 為方便日後查閱 在我的博文裡面 關於分布式系統的資料一致性問題 二 裡面主要介紹了資料分布的情況下保證一致性的情況，在第二篇文章裡面，我這裡提出了三個問題 訂單系統呼叫支付系統支付訂單，支付成功，但是返回給訂單系統資料超時，訂單還是i 初始狀態 但是此時會員帳戶餘額100,會員肯定會馬上找...
關於分布式系統的資料一致性問題 三
在我的博文裡面關於分布式系統的資料一致性問題 二 裡面主要介紹了資料分布的情況下保證一致性的情況，在第二篇文章裡面，我這裡提出了三個問題 訂單系統呼叫支付系統支付訂單，支付成功，但是返回給訂單系統資料超時，訂單還是i 初始狀態 但是此時會員帳戶餘額100,會員肯定會馬上找京東罵京東，為啥不給老子發貨...