消息服務在電商中的實踐

1 商品和訂單服務中使用MQ

1.1 同步

在訂單生成的時候直接扣庫存，這是最初等的方式扣庫存，這種方式比較簡單，可是也有一系列的問題：

• 會形成有不少訂單把產品庫存扣除而並無支付，這就須要有一個後臺腳本，將一段時間內沒有支付的訂單的庫存釋放，把訂單取消掉
• 即時扣庫存，併發差

1,3商品服務,操做商品服務的 db
2,4 訂單服務.操做訂單服務的 db

避免訪問不一樣服務的 db

1.2 改形成基於消息隊列的異步操做

首先考慮只將第四步異步化
分析:2,4都是操做db,第四步再也不等待,
1,2,3成功後即反饋給用戶
以後經過消息通知服務異步下單,若第4步異步下單失敗了,傾向於重試操做,試圖從新生成訂單,消息隊列的消息也是可回溯的

訂單建立完成後,處於排隊狀態,而後服務發佈一個事件Order Created 到消息隊列中
即訂單服務向外界發送消息:我建立了一個訂單
由MQ 轉發給訂閱該消息的服務

若是商品服務收到建立訂單消息以後執行扣庫存操做
注意,這裏可能由於某些不可抗因素致使扣庫存失敗
不管成功與否,商品服務都會發送一個扣庫存消息到 MQ 中,消息內容即扣庫存的結果
訂單服務會訂閱扣庫存的結果,接收到該消息後

• 若是扣庫存成功,將訂單的狀態改成已確認,即下單成功
• 若是扣庫存失敗,將訂單的狀態改成已取消,即下單失敗

欲實現上述模型要求,須要如下保證

* 可靠消息投遞

服務發出的消息,必定會被MQ收到

* 用戶體驗的變化
前端配合排隊中等界面

商品/訂單服務都變成異步化,適合秒殺類場景,當流量不大時,並不太適合如此改造

2 異步化設計

對於 CAP 理論

• zk保證 AP
• eurake 保證 CP

最終分析實例

當訂單支付成功後，會有一個出庫過程，既然有這個過程，就有可能出庫失敗， 他的流程是怎麼樣子的呢？
庫存有兩部分：一個緩存redis層，一個數據庫mysql層

1 當客服新增了5個庫存，那麼，緩存redis和數據庫mysql層都須要增長5個庫存，這個使用分佈式事務的最終一致性來知足要麼全加，要麼全不加庫存

2 當訂單生成的時候，須要扣除庫存，先扣除redis庫存，若是扣除成功，則生成訂單進行支付，這個過程不扣除mysql庫存

3 當redis庫存扣乾淨，這個產品就沒法下單了，下單就會失敗,就把外層的給擋住了

4 在第2步扣除redis庫存成功後，生成訂單，進行支付，支付成功，返回個人訂單中心， 會發現有一個出庫過程

5 出庫過程
一個MQ異步解耦的任務隊列,這個過程是扣除mysql庫存

• 若是扣mysql庫存成功，出庫成功，完成下訂單整個流程，進入發貨狀態
• 若是扣mysql庫存失敗，出庫失敗，進行一系列的操做
  • 訂單狀態改爲取消
  • 返還redis庫存
  • 退款

redis庫存和mysql庫存

支付前是預扣，是扣redis庫存，是鎖定庫存的過程
支付後是真正扣，扣mysql庫存，保證庫存最終一致

可是，在極端狀況下會存在數據不一致

• 若是redis庫存 = mysql庫存，不會有問題
• 若是redis庫存 < mysql庫存，不會有超賣問題，但會存在實際有庫存，可是沒有賣的狀況
• 若是redis庫存 > mysql庫存，就會超賣，超賣的訂單，在出庫的過程當中會失敗

這樣整體不會出問題，mysql數據庫層，保證庫存最終不會出問題。

可是會有如下的問題：

數據庫庫存和redis庫存不一致，如何檢測？

若是檢測出來不一致，如何同步

沒有想出來好的方案
比較暴力的方式，就是找一個低峯期，譬如凌晨1點，週期性強行覆蓋。 可是極端狀況下仍是會存在同步後不許確，譬如在同步的過程當中，恰好有一個訂單在支付，這個訂單支付成功後，出庫的過程當中，扣除了mysql的庫存，可是沒有扣除redis的庫存

這個就是數據庫同步緩存的更新機制方面的問題
屬於一致性的邏輯設計的問題
`緩存數 = 數據庫庫存數 - 待扣數`
固然這裏面也還有其它的方案，以及考慮到一致性的要求高低，可使用簡單或複雜的方案
就看系統複雜度了，越是大系統就要拆得越細
好比待扣數又能夠放到一個隊列裏面，或者緩存裏面，同時有計數，直接讀計數就行
好比放到mongo，已支付待出庫的數量，通常也不會很大，count一下，也不會損失多少
因此通常系統都不能徹底保障數據鏈不出錯，但必定要有補償，就是出錯了能夠糾錯
要保障不出錯的代價顯然太大
同步是有一套刷新機制，能夠定時，也能夠經過MQ，或者監控不一至同步等等。。。
也叫作保障緩存數據的新鮮度
通常不會太長時間，半小時，幾分鐘都有可能，不一樣場景需求不同

買火車票的12306，晚上的時間都不能買票，這個時間估計是在同步庫存，將數據庫庫存同步到redis庫存中， 可是買火車票之類，在訂單生成前，必須扣除實際庫存，也就是要扣除mysql的庫存，

由於買火車票和購物不同，購物能夠付款後出庫，可是買票這種，支付前就必須出庫，所以，要將出庫過程提早， 只有出庫成功，才能生成訂單，一樣要引入redis庫存

先扣緩存中的庫存，扣除成功後，而後才能夠去扣mysql中的庫存

若是扣除緩存中的庫存失敗，就會擋在外面，返回庫存不足，這些請求不會穿刺到mysql中，擋住了大多數的請求壓力。

redis庫存會和mysql庫存不一致，極端狀況下是確定有的，須要進行庫存同步

• 當緩存庫存比數據庫庫存多，那麼就會出現，查詢有票，可是就沒法下單，下單的時候就說庫存不足，這個狀況下，就會形成數據庫壓力過大，不過12306應該有其餘手段來規避這個問題，不過，我確實遇到過，查詢的時候有票，可是沒法下單的狀況。

• 當緩存庫存比數據庫緩存少，那麼不會出問題，只會出現有票，可是沒有出售的狀況，等完成庫存同步一下， 明天又準確了。