前兩篇文章，從業務端和技術端分析了秒殺系統的構建中我們可以採用的思路。收到部分同學的留言，問了一些細節上的問題，今天會集中整理一下這些問題，作為秒殺系列的一個收尾。
昨天提到了商品詳情頁要做靜態化的問題。實際上，頁面上還是有一些動態資料，例如購買人數，購買比例這樣的動態資料（見下圖），那麼問題就來了，在秒殺條件下，這種頻繁更新的動態資料一旦資料更新不及時，會有大量的前端請求，透傳到後端來，會不會導致超賣呢？
這是一個很好的問題，我這裡的答案是，不會的，最終的一致性不是靠前端來完成的。在讀的場景下，為了保證系統的整體效能，我們是可以允許一定的“髒資料”，這裡的不一致性的影響是很有限的，只會讓少量一些原本已經沒有庫存的下單請求誤認為還有庫存而已。在達到CAP的過程中，需要有所平衡和取捨，這裡就是通過一致性來換取高可用性做平衡，來解決這種高併發的資料讀取問題。
從這個問題，我們可以引申出一個我們秒殺系統中讀寫資料的原則
讀資料： 不做強一致性校驗，資料通過分層校驗來修正。
寫資料： 寫資料進行強一致性校驗，通過限流保護來保證寫資料的成功性。
根據這個原則，在秒殺功能中，我們會分層對資料流進行不同的處理方式：
1. 通過CDN，把大量靜態不需要檢驗的資料放在系統之外的地方；減少不必要的流量到伺服器端。
2. 預載入使用者靜態資訊，在前端讀系統中檢驗一些基本資訊，如使用者是否具有秒殺資格、商品狀態是否正常、秒殺是否已經結束等；過濾大量無效請求。
3. 在寫資料系統中再校驗一些如是否是非法請求，寫的資料一致性如檢查庫存是否充足等；
4. 最後在資料庫層保證資料最終準確性，避免超賣。
處理併發鎖的一個思路
昨天的文章其實已經提到了兩個解決的辦法，1. 應用層對資料提交排隊，走佇列，降低併發度。 2. 水平分庫，物理上進行分流。
今天再提供一個野路子：
1. 將秒殺產品資料記錄A，拆分為10條，A1, A2... A10。
2. 庫存數分擔到這10條記錄中。
3. 訂單服務有一個隨機函式Rom()，生成訂單記錄前，根據函式結果決定從某一條記錄中扣除庫存。
4. 秒殺結束後，通過程式，對訂單記錄進行一個批量處理，對訂單資料進行整合。
這個思路的出發點是以最小的代價降低單條行鎖的壓力，保證高壓下寫操作的成功率。當然，這背後是要建立一套產品和訂單的歸併對映邏輯。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
