高併發系統中的鎖策略，快取策略等解決思路
本文一共分析了三個案例，分別介紹併發系統中的共享資源併發訪問、計算型密集型任務快取訪問 、單一熱點資源峰值流量問題和解決方案。
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原子操作功能;
2. 其使用方式為：首先使用gets指令一個key-value及key對應value的版本號;其次操作產生新的value值;最後使用cas指令重新提交key-value，並附帶剛剛獲得到的版本號;
3. 當服務端判斷cas操作中的版本號不是最新的時，則認為改key的值已經被修改，本次cas操作失敗。程式設計人員通過CAS機制可實現自增和自減的原子操作;
可以看到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，依靠數量眾多的前端機來抗極熱點請求。