本文一共分析了三個案例，分別介紹併發系統中的共享資源併發訪問、計算型密集型任務快取訪問 、單一熱點資源峰值流量問題和解決方案。
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，依靠數量眾多的前端機來抗極熱點請求。
高併發場景下快取的常見問題
1快取一致性問題 當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。2快取併發問題 快取過期後將嘗試從後端資料庫獲取資料...
高併發下快取常見問題及處理
在日常開發過程中，為了提高查詢速度，我們通常會用到本地快取或分布式快取。特別是在高併發場景下使用分布式快取會遇到很多問題。主要可以歸為如下幾種 接下來就看一看如何處理這些常見問題。快取通常對資料庫資料快取。而分布式快取，還會存在主從結點。從結點會再同步主結點資料。因此在這種情況下訪問快取就可能導致快...
快取在高併發場景下的常見問題
當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。快取過期後將嘗試從後端資料庫獲取資料，這是乙個看似合理的流程。但是，在...