轎車從天而降電動車主被撞身亡 超速搶道所致：現(xiàn)場視頻讓網(wǎng)友吵翻
近日，上海青浦區(qū)法院判決轎車從天而降電動車主被撞身亡案，轎車車主被判有期徒刑一年。案件顯示當(dāng)時男子駕駛轎車在上海某路段行駛，前車忽然轉(zhuǎn)彎提速超車，
在大規(guī)模秒殺活動中，針對單一商品的庫存扣減請求峰值可以輕松達到幾萬、甚至幾十萬QPS，如常見的搶茅臺活動。在這種場景下再基于數(shù)據(jù)庫進行庫存扣減就顯得無能為力了，記住一個關(guān)鍵指標(biāo)：在MySQL中，目前單行更新操作的的性能約為500QPS。對于動輒幾萬QPS的庫存扣減來說，這個量級肯定是偏低了。
所以為了應(yīng)對這種高并發(fā)場景，業(yè)界提出了一種方案叫 熱點散列，即今天群里討論的庫存分桶。
其方案如下圖所示：將同一商品的庫存提前分配至多個“桶”中，根據(jù)路由規(guī)則（隨機、UID取模）將庫存請求路由至不同的桶，從而將集中于單實例的請求分散，此方案類似于水平擴展。
圖片
至于“分桶”的技術(shù)實現(xiàn)，很多技術(shù)文章或解決方案都建議采用Redis來實現(xiàn)。具體而言，對任一秒殺活動的商品，可將其分成N份，每份對一個緩存Key，緩存Key的構(gòu)成必須遵循一定的規(guī)律，便于路由，示例如下：
key: inventoryId_1，value: 庫存數(shù)量
key: inventoryId_2, value: 庫存數(shù)量
...
key: inventoryId_N, value: 庫存數(shù)量
在扣減庫存時，可以根據(jù)Key的編號區(qū)間，采用隨機算法，UID取模等方式確定一個編號，然后組裝Key訪問緩存。
舉個例子，假如inventoryId為20221821，將庫存分配至100個桶，則根據(jù)相應(yīng)Key的區(qū)間為[1,100]。
服務(wù)端收到商品庫存扣減請求后，將請求中的參數(shù)UID取模，假設(shè)UID % 100 = 67，則組裝Key為 20221821_67，基于20221821_67扣減對應(yīng)緩存桶中的庫存。
熱點散列的核心思想為：在緩存中扣減庫存，以提升系統(tǒng)的吞吐量；緩存扣減成功后，異步向數(shù)據(jù)庫寫入庫存扣減流水并更新庫存；此外，還需要通過定時任務(wù)等機制實現(xiàn)緩存與數(shù)據(jù)庫的庫存總量同步。
這個方案看上去很不錯，但也會存在如下三個問題：
一、在緩存中扣減庫存如何保證冪等性呢？若冪等性防控不足，則可能出現(xiàn)重復(fù)扣減，進而導(dǎo)致少賣。
二、緩存寫操作和數(shù)據(jù)庫寫操作無法通過事務(wù)機制來保證強一致性，那么該如何有效的保證庫存數(shù)據(jù)的一致性呢？
三、用戶所見的庫存應(yīng)為總庫存，即便總庫存充足，一旦分桶，如何保證用戶請求被路由到的分桶油足夠的庫存呢？
所以個人覺得，熱點散列在理論上是解決庫存熱點問題最有效的方案，但在實際應(yīng)用中，需要考慮的細節(jié)非常多。基于緩存的庫存扣減的方案是比較粗糙的，它只滿足一些特定場景的需要。對于淘寶、京東這類在想商品規(guī)模達數(shù)十億的大型電商平臺而言，所面臨的問題要復(fù)雜得多，除了穩(wěn)定性、可靠性、一致性，還包括庫存分配，庫存碎片，庫存擴縮容、流量傾斜、商品少賣、商品超賣等。
上次去阿里交流的時候，阿里專家唐三說：在阿里，庫存架構(gòu)采用的方案是做庫存單元化架構(gòu)，這種方案應(yīng)該是大型電商平臺庫存系統(tǒng)的終極解決方案。
本文鏈接：http://www.www897cc.com/showinfo-26-70416-0.html高并發(fā)秒殺方案：熱點散列，庫存分桶，你需要了解一下
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 大規(guī)模敏捷測試怎么做（集成篇）
下一篇： 司空見慣的錯誤檢測，原來還有這么多干貨!
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號