秒殺系統設計中的數據處理

前兩篇文章，從業務端和技術端分析了秒殺系統的構建中咱們能夠採用的思路。收到部分同窗的留言，問了一些細節上的問題，今天會集中整理一下這些問題，做爲秒殺系列的一個收尾。

昨天提到了商品詳情頁要作靜態化的問題。實際上，頁面上仍是有一些動態數據，例如購買人數，購買比例這樣的動態數據（見下圖），那麼問題就來了，在秒殺條件下，這種頻繁更新的動態數據一旦數據更新不及時，會有大量的前端請求，透傳到後端來，會不會致使超賣呢？

這是一個很好的問題，我這裏的答案是，不會的，最終的一致性不是靠前端來完成的。在讀的場景下，爲了保證系統的總體性能，咱們是能夠容許必定的「髒數據」，這裏的不一致性的影響是頗有限的，只會讓少許一些本來已經沒有庫存的下單請求誤認爲還有庫存而已。在達到CAP的過程當中，須要有所平衡和取捨，這裏就是經過一致性來換取高可用性作平衡，來解決這種高併發的數據讀取問題。

從這個問題，咱們能夠引伸出一個咱們秒殺系統中讀寫數據的原則

讀數據： 不作強一致性校驗，數據經過分層校驗來修正。

寫數據： 寫數據進行強一致性校驗，經過限流保護來保證寫數據的成功性。

根據這個原則，在秒殺功能中，咱們會分層對數據流進行不一樣的處理方式：

1. 經過CDN，把大量靜態不須要檢驗的數據放在系統以外的地方；減小沒必要要的流量到服務器端。

2. 預加載用戶靜態信息，在前端讀系統中檢驗一些基本信息，如用戶是否具備秒殺資格、商品狀態是否正常、秒殺是否已經結束等；過濾大量無效請求。

3. 在寫數據系統中再校驗一些如是不是非法請求，寫的數據一致性如檢查庫存是否充足等；

4. 最後在數據庫層保證數據最終準確性，避免超賣。

處理併發鎖的一個思路

昨天的文章其實已經提到了兩個解決的辦法，1. 應用層對數據提交排隊，走隊列，下降併發度。 2. 水平分庫，物理上進行分流。

今天再提供一個野路子：

1. 將秒殺產品數據記錄A，拆分爲10條，A1, A2... A10。

2. 庫存數分擔到這10條記錄中。

3. 訂單服務有一個隨機函數Rom()，生成訂單記錄前，根據函數結果決定從某一條記錄中扣除庫存。

4. 秒殺結束後，經過程序，對訂單記錄進行一個批量處理，對訂單數據進行整合。

這個思路的出發點是以最小的代價下降單條行鎖的壓力，保證高壓下寫操做的成功率。固然，這背後是要創建一套產品和訂單的歸併映射邏輯。

掃描二維碼或手動搜索微信公衆號【架構棧】： ForestNotes

歡迎轉載，帶上如下二維碼便可