搶購與秒殺場景的解決思路

原貼：http://www.csdn.net/article/2014-11-28/2822858

搶購實現的主體思路：異步解耦

徐漢彬的解決思路：
## HTML靜態頁面 經過CDN解決
## 後臺接口：建議異步
### 高併發，服務器壓力極大，不建議MySql
MySQL數據庫自帶的鎖機制很好的解決問題，可是，在大規模併發的場景中，不推薦使用MySQL

### 秒殺搶購中的存在的做弊及對應的解決方案
1. 同一帳號一次發送多個請求（針對帳號作一個攔截）
2. 多個帳號一次發送多個請求（針對ip進行攔截）
3. 多個帳號經過不一樣ip發請求（採用數據挖掘）
4. 12306寫一箇中轉軟件，經過人來識別驗證碼（數據挖掘，分析）

### 高併發的數據安全
1. 超發緣由：
100個商品只剩一個，結果進來100個請求所有讀到1，悲劇了

2. 悲觀鎖思路：
悲觀鎖，也就是在修改數據的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。
  可是高併發場景可能致使有些線程永遠也沒有辦法獲得鎖，會死在那裏

3. FIFO思路
高併發的場景下，由於請求不少，極可能一瞬間將隊列內存「撐爆」，而後系統又陷入到了異常狀態。或者設計一個極大的內存隊列，也是一種方案，可是，系統處理完一個隊列內請求的速度根本沒法和瘋狂涌入隊列中的數目相比。

4. 樂觀鎖
樂觀鎖，是相對於「悲觀鎖」採用更爲寬鬆的加鎖機制，大都是採用帶版本號（Version）更新。實現就是，這個數據全部請求都有資格去修改，但會得到一個該數據的版本號，只有版本號符合的才能更新成功，其餘的返回搶購失敗。