高并發系統中的常見問題
本文一共分析了三個案例，分別介紹并發系統中的共享資源并發訪問、計算型密集型任務緩存訪問 、單一熱點資源峰值流量問題和解決方案。</span>
Q1：訂票系統，某車次只有一張火車票，假定有1w個人同時打開12306網站來訂票，如何解決并發問題？
A1： 首先介紹數據庫層面的并發訪問，解決的辦法主要是樂觀鎖和悲觀鎖。
樂觀鎖
假設不會發生并發沖突，只在提交操作時檢查是否違反數據完整性。
樂觀鎖使用一個自增的字段表示數據的版本號（或者timestamp），更新的時候檢查版本號是否一致，比如數據庫中版本號為4，更新時版本號使用版本號version=5，與數據庫中的版本號version+1=（5）做比較，如果相等，則可以更新，如果不相等，其他程序已更新該記錄，返回錯誤。
悲觀鎖
假定會發生并發沖突，屏蔽一切可能違反數據完整行的操作。
一般需要使用數據庫的鎖機制，比如MysqlInnoDB引擎的行級鎖。
結論：在實際生產環境中，如果并發量不大且不允許臟讀（原始數據為5，AB兩個事務，B其他事務更新數據為2，事務未提交時，A讀取到的仍然為5），可以使用悲觀鎖。并發訪問量大時，使用悲觀鎖有非常大的性能問題，可以選擇樂觀鎖。
其次，介紹一下Memcached的CAS機制
CAS，又稱Compare-and-Swap，代表一種原子操作。
Memcached的CAS機制解決的問題及其原理：
1. 實現了Check-and-Set原子操作功能；
- </span>其使用方式為：首先使用gets指令一個key-value及key對應value的版本號；其次操作產生新的value值；最后使用cas指令重新提交key-value，并附帶剛剛獲得到的版本號；
- </span>當服務端判斷cas操作中的版本號不是最新的時，則認為改key的值已經被修改，本次cas操作失敗。程序設計人員通過CAS機制可實現自增和自減的原子操作；</span> </p>
可以看到MemCache的CAS機制和數據庫的樂觀鎖實現原理非常類似。
Q2：假設系統中圖片存儲在TFS（Taobao File System)中，接口提供縮略圖服務，首先在緩存中查找是否有縮略圖，如果沒有，則從TFS加載原圖片，然后請求縮略圖服務，縮略圖計算完成后，設置回緩存服務中。
遇到的問題：當一張圖片分享給100w個人以后，同一時間有1w個并發請求，由于縮略圖計算耗時較長（假設1s), 在這1s內，每個請求查詢緩存都沒有找到然后申請計算縮略圖，導致重復的縮略圖計算量和資源消耗。
A2： 對于縮略圖這種耗時的服務，非常適合使用緩存，不過在使用的時候，對于同一個圖片，原則上只需要計算一次縮略圖，在縮略圖未計算完成時，可以對每張圖片做 額外的標記表示其正在Processing，并發請求遇到縮略圖Processing時，可以等待縮略圖計算完成（這是建議的方式）后從緩存直接讀取，也 可以是直接返回錯誤，通過客戶端重試來解決。
本案例中，如果縮略圖請求在上傳圖片1分鐘后才發生，則可以在后臺預先計算縮略圖并存儲到緩存。另外就是在上傳圖片的時候計算縮略圖，不過會增加上傳圖片的時間。
Q3:單點峰值流量，在并發系統中，除了請求整體的并發量高，還常見單一熱點資源的并發請求量很高。例如，1萬個人每人分享了一張圖片，其中9999張圖片的縮略圖請求在10 QPS以內，剩下的一張圖片為新聞熱點圖片，峰值請求在10萬QPS左右， 系統會遇到的容量問題包括：1）接口前端機容量不夠；2）緩存資源單實例遇到瓶頸。
A3:針對單點峰值流量可能遇到的性能瓶頸，解決方案如下。
1）接口層容量不夠：這個問題比較簡單，只要接口層設計是無狀態的，當容量達到預警線，可以通過快速水平擴容解決。
2 ）緩存資源單實例遇到性能瓶頸：如果使用的是分布式緩存，當希望突破單一key的訪問瓶頸時（這個瓶頸既有可能是CPU資源緊張，也有可能是單機網絡帶寬跑滿，還有可能是磁盤IO吞吐不夠），一個辦法是分布式緩存做多副本（x3）冗余設計，這樣系統的吞吐量（x3）可以提高3倍，不過成本也提高3倍。另外一個辦法是針對極熱點數據，除了分布式緩存，同時在前端機上打開localCache，依靠數量眾多的前端機來抗極熱點請求。
</span>來自： http://weibo.com/p/1001603862417250608209