7月安卓手機性能榜：紅魔8S Pro再奪榜首
7月份的手機市場風平浪靜，除了紅魔和努比亞帶來了兩款搭載驍龍8Gen2領先版處理器的新機之外，別的也想不到有什么新品了，這也正常，通常6月7月都是手機廠商修整的時間，進入8月份之
在大規模秒殺活動中，針對單一商品的庫存扣減請求峰值可以輕松達到幾萬、甚至幾十萬QPS，如常見的搶茅臺活動。在這種場景下再基于數據庫進行庫存扣減就顯得無能為力了，記住一個關鍵指標：在MySQL中，目前單行更新操作的的性能約為500QPS。對于動輒幾萬QPS的庫存扣減來說，這個量級肯定是偏低了。
所以為了應對這種高并發場景，業界提出了一種方案叫 熱點散列，即今天群里討論的庫存分桶。
其方案如下圖所示：將同一商品的庫存提前分配至多個“桶”中，根據路由規則（隨機、UID取模）將庫存請求路由至不同的桶，從而將集中于單實例的請求分散，此方案類似于水平擴展。
圖片
至于“分桶”的技術實現，很多技術文章或解決方案都建議采用Redis來實現。具體而言，對任一秒殺活動的商品，可將其分成N份，每份對一個緩存Key，緩存Key的構成必須遵循一定的規律，便于路由，示例如下：
key: inventoryId_1，value: 庫存數量
key: inventoryId_2, value: 庫存數量
...
key: inventoryId_N, value: 庫存數量
在扣減庫存時，可以根據Key的編號區間，采用隨機算法，UID取模等方式確定一個編號，然后組裝Key訪問緩存。
舉個例子，假如inventoryId為20221821，將庫存分配至100個桶，則根據相應Key的區間為[1,100]。
服務端收到商品庫存扣減請求后，將請求中的參數UID取模，假設UID % 100 = 67，則組裝Key為 20221821_67，基于20221821_67扣減對應緩存桶中的庫存。
熱點散列的核心思想為：在緩存中扣減庫存，以提升系統的吞吐量；緩存扣減成功后，異步向數據庫寫入庫存扣減流水并更新庫存；此外，還需要通過定時任務等機制實現緩存與數據庫的庫存總量同步。
這個方案看上去很不錯，但也會存在如下三個問題：
一、在緩存中扣減庫存如何保證冪等性呢？若冪等性防控不足，則可能出現重復扣減，進而導致少賣。
二、緩存寫操作和數據庫寫操作無法通過事務機制來保證強一致性，那么該如何有效的保證庫存數據的一致性呢？
三、用戶所見的庫存應為總庫存，即便總庫存充足，一旦分桶，如何保證用戶請求被路由到的分桶油足夠的庫存呢？
所以個人覺得，熱點散列在理論上是解決庫存熱點問題最有效的方案，但在實際應用中，需要考慮的細節非常多。基于緩存的庫存扣減的方案是比較粗糙的，它只滿足一些特定場景的需要。對于淘寶、京東這類在想商品規模達數十億的大型電商平臺而言，所面臨的問題要復雜得多，除了穩定性、可靠性、一致性，還包括庫存分配，庫存碎片，庫存擴縮容、流量傾斜、商品少賣、商品超賣等。
上次去阿里交流的時候，阿里專家唐三說：在阿里，庫存架構采用的方案是做庫存單元化架構，這種方案應該是大型電商平臺庫存系統的終極解決方案。
本文鏈接：http://m.www897cc.com/showinfo-26-70416-0.html高并發秒殺方案：熱點散列，庫存分桶，你需要了解一下
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 大規模敏捷測試怎么做（集成篇）
下一篇： 司空見慣的錯誤檢測，原來還有這么多干貨!
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號