大戰618，決勝雙十一 高併發秒殺系統解密—後端java程序員力薦

寫在前面

2011年618京東事件能夠看出來，高併發對服務器壓力仍是很是大的，京東去年618最後仍是經過延長事件來解決，可是這次蘇寧策劃好像並不是借鑑這次事故的經驗，發生了同樣的問題，記得不錯的話，taobao也發生過同樣的事情、12306購票也被罵死，，因此在策劃方案中要充分考慮此種特殊狀況下該怎麼辦預案...

秒殺業務分析

那些場景屬於秒殺業務？

1. 商品搶購
2. 羣紅包
3. 優惠卷領取
4. 搶火車票
5. 在線預定
6. ……

小蝌蚪跑步比賽 起點線的故事

關於鎖的那些事

悲觀鎖解析

對於悲觀鎖的概念解釋主要有兩種，但本質上悲觀鎖主要用於數據庫訪問的併發控制上。

• 解釋一

悲觀鎖是指對數據被外界（包括本系統當前的其餘事務，以及來自外部系統的事務處理）修改持保守態度，所以，在整個數據處理過程當中，將數據處於鎖定狀態，在悲觀鎖的狀況下，爲了保證事務的隔離性，就須要一致性鎖定讀。讀取數據時給加鎖，其它事務沒法修改這些數據。修改刪除數據時也要加鎖，其它事務沒法讀取這些數據。

• 解釋二

在關係數據庫管理系統裏，悲觀併發控制（又名「悲觀鎖」，Pessimistic Concurrency Control，縮寫「PCC」）是一種併發控制的方法。它能夠阻止一個事務以影響其餘用戶的方式來修改數據。若是一個事務執行的操做都某行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。

悲觀鎖處理流程

1. 在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）
2. 若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常
3. 若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會解鎖了
4. 其間若是有其餘對該記錄作修改或加排他鎖的操做，都會等待咱們解鎖或直接拋出異常

悲觀鎖優勢

• 悲觀併發控制其實是「先取鎖再訪問」的保守策略，爲數據處理的安全提供了保證。
• 悲觀鎖基於DB層面實現，對業務代碼無入侵，使用方便

悲觀鎖缺點

• 悲觀鎖適用於可靠的持續性鏈接，諸如C/S應用。 對於Web應用的HTTP鏈接，先天不適用
• 鎖的使用意味着性能的損耗，在高併發、鎖定持續時間長的狀況下，尤爲嚴重。 Web應用的性能瓶頸多在數據庫處，使用悲觀鎖，進一步收緊了瓶頸
• 非正常停止狀況下的解鎖機制，設計和實現起來很麻煩，成本還很高
• 不夠嚴謹的設計下，可能產生莫名其妙的，不易被發現的死鎖問題
• 悲觀的缺陷是不管是頁鎖仍是行鎖，加鎖的時間可能會很長，這樣可能會長時間的限制其餘用戶的訪問，也就是說悲觀鎖的併發訪問性很差

樂觀鎖解析

在關係數據庫管理系統裏，樂觀併發控制（又名「樂觀鎖」，Optimistic Concurrency Control，縮寫「OCC」）是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務可以在不產生鎖的狀況下處理各自影響的那部分數據。在提交數據更新以前，每一個事務會先檢查在該事務讀取數據後，有沒有其餘事務又修改了該數據。若是其餘事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最先是由孔祥重（H.T.Kung）教授提出。

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。通常的實現樂觀鎖的方式就是記錄數據版本

優勢與不足

樂觀併發控制相信事務之間的數據競爭(data race)的機率是比較小的，所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。但若是直接簡單這麼作，仍是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，通過修改之後寫回數據庫，這時就遇到了問題。

樂觀鎖實現流程

保證三步操做原子性

秒殺核心 服務實戰

手把手實現核心服務

• 基於mysql經過版本號實現；
• 基於mysql經過狀態實現；
• 基於memcached的cas機制實現；

緩存實現樂觀鎖方案

進一步的思考

1. CAS機制就能完全解決秒殺的問題？
2. 架構師眼中，秒殺系統的全貌？

本文到此結束！喜歡的朋友能夠轉發文章和關注一下！感謝！