架構閱讀筆記5

閱讀文章《

京東到家庫存系統架構設計

》目前，京東到家庫存系統經歷兩年多的線上考驗與技術迭代，現服務著萬級商家十萬級店鋪的規模，需求的變更與技術演進，我們是如何做到系統的穩定性與高可用呢，下圖會給你揭曉答案（通過強大的基礎服務平台讓應用、jvm、docker、物理機所有健康指標一目了然，7*24小時智慧型監控告警讓開發無須一直盯著監控，另外資料與業務相輔相成，用資料驗證業務需求，迭代業務需求，讓業務需求都盡可能的收益最大化，庫存系統的開發同學只需要關注業務需求，大版本上線前相應的測試同學會跟進幫你壓測，防止上線後潛在的效能瓶頸）。

庫存系統的架構很有意思，從上圖來看功能上其實並不複雜，但是他面臨的技術複雜度卻是相當高的，比如秒殺品在高併發的情況下如何防止超賣，另外庫存系統還不是乙個純技術的系統，需要結合使用者的行為特點來考慮，比如什麼時間進行庫存的扣減最合適，

商家銷售的商品數量是有限的，使用者下單後商品會被扣減，我們可以怎麼實現呢？

舉個例子：一件商品有1000個庫存，現在有1000個使用者，每個使用者計畫同時購買1000個。京東到家目前採用的是方案2，理由：

綜上所述，方案2也可能由於使用者下單預佔庫存但最終未支付，造成庫存30分鐘後才能被其它使用者使用的情況，但是相較於方案1，方案3無疑是折中的最好方案。

重複提交訂單造成的庫存重複扣減的後果是比較嚴重的。比如商家設定有1000件商品，而實際情況可能賣了900件就提示使用者無貨了，給商家造成無形的損失

可能出現重複提交訂單的情況：（3、提單系統重試）比如提單系統為了提高系統的可用性，在第一次呼叫庫存系統扣減介面超時後會重試再次提交扣減請求

好了，既然問題根源縷清楚了，我們一一對症下藥

（2、使用者惡意行為）採用令牌機制，使用者每次進入結算頁，提單系統會頒發乙個令牌id（全域性唯一），當使用者點選「提交訂單」按鈕時發起的網路請求中會帶上這個令牌id,這個時候提單系統會優先進行令牌id驗證，令牌id存在&令牌id訪問次數=1的話才會放行處理後續邏輯，否則直接返回

（3、提單系統重試）這種情況則需要後端系統（比如庫存系統）來保證介面的冪等性，每次呼叫庫存系統時均帶上訂單號，庫存系統會基於訂單號增加乙個分布式事務鎖，偽**如下：

int ret=redis.incr(orderid);

redis.expire(orderid,5,timeunit.minutes);

if(ret==1)elseelseelse else elseelse{

return "搶購失敗";

架構閱讀筆記5

架構閱讀筆記5

閱讀筆記5

《架構漫談》閱讀筆記

相關推薦