本文一共分析了三個(gè)案例，分別介紹并發(fā)系統(tǒng)中的共享資源并發(fā)訪問、計(jì)算型密集型任務(wù)緩存訪問 、單一熱點(diǎn)資源峰值流量問題和解決方案。

Q1：訂票系統(tǒng)，某車次只有一張火車票，假定有1w個(gè)人同時(shí)打開12306網(wǎng)站來(lái)訂票，如何解決并發(fā)問題?

A1： 首先介紹數(shù)據(jù)庫(kù)層面的并發(fā)訪問，解決的辦法主要是樂觀鎖和悲觀鎖。

樂觀鎖

假設(shè)不會(huì)發(fā)生并發(fā)沖突，只在提交操作時(shí)檢查是否違反數(shù)據(jù)完整性。

樂觀鎖使用一個(gè)自增的字段表示數(shù)據(jù)的版本號(hào)(或者timestamp)，更新的時(shí)候檢查版本號(hào)是否一致，比如數(shù)據(jù)庫(kù)中版本號(hào)為4，更新時(shí)版本號(hào)使用版本號(hào)version=5，與數(shù)據(jù)庫(kù)中的版本號(hào)version+1=(5)做比較，如果相等，則可以更新，如果不相等，其他程序已更新該記錄，返回錯(cuò)誤。

[[247233]]

悲觀鎖

假定會(huì)發(fā)生并發(fā)沖突，屏蔽一切可能違反數(shù)據(jù)完整行的操作。

一般需要使用數(shù)據(jù)庫(kù)的鎖機(jī)制，比如MysqlInnoDB引擎的行級(jí)鎖。

結(jié)論：在實(shí)際生產(chǎn)環(huán)境中，如果并發(fā)量不大且不允許臟讀(原始數(shù)據(jù)為***B兩個(gè)事務(wù)，B其他事務(wù)更新數(shù)據(jù)為2，事務(wù)未提交時(shí)，A讀取到的仍然為5)，可以使用悲觀鎖。并發(fā)訪問量大時(shí)，使用悲觀鎖有非常大的性能問題，可以選擇樂觀鎖。

其次，介紹一下Memcached的CAS機(jī)制

CAS，又稱Compare-and-Swap，代表一種原子操作。

Memcached的CAS機(jī)制解決的問題及其原理：

1. 實(shí)現(xiàn)了Check-and-Set原子操作功能;

2. 其使用方式為：首先使用gets指令一個(gè)key-value及key對(duì)應(yīng)value的版本號(hào);其次操作產(chǎn)生新的value值;***使用cas指令重新提交key-value，并附帶剛剛獲得到的版本號(hào);

3. 當(dāng)服務(wù)端判斷cas操作中的版本號(hào)不是***的時(shí)，則認(rèn)為改key的值已經(jīng)被修改，本次cas操作失敗。程序設(shè)計(jì)人員通過CAS機(jī)制可實(shí)現(xiàn)自增和自減的原子操作;

可以看到MemCache的CAS機(jī)制和數(shù)據(jù)庫(kù)的樂觀鎖實(shí)現(xiàn)原理非常類似。

Q2：假設(shè)系統(tǒng)中圖片存儲(chǔ)在TFS(Taobao File System)中，接口提供縮略圖服務(wù)，首先在緩存中查找是否有縮略圖，如果沒有，則從TFS加載原圖片，然后請(qǐng)求縮略圖服務(wù)，縮略圖計(jì)算完成后，設(shè)置回緩存服務(wù)中。

遇到的問題：當(dāng)一張圖片分享給100w個(gè)人以后，同一時(shí)間有1w個(gè)并發(fā)請(qǐng)求，由于縮略圖計(jì)算耗時(shí)較長(zhǎng)(假設(shè)1s), 在這1s內(nèi)，每個(gè)請(qǐng)求查詢緩存都沒有找到然后申請(qǐng)計(jì)算縮略圖，導(dǎo)致重復(fù)的縮略圖計(jì)算量和資源消耗。

A2：對(duì)于縮略圖這種耗時(shí)的服務(wù)，非常適合使用緩存，不過在使用的時(shí)候，對(duì)于同一個(gè)圖片，原則上只需要計(jì)算一次縮略圖，在縮略圖未計(jì)算完成時(shí)，可以對(duì)每張圖片做額外的標(biāo)記表示其正在Processing，并發(fā)請(qǐng)求遇到縮略圖Processing時(shí)，可以等待縮略圖計(jì)算完成(這是建議的方式)后從緩存直接讀取，也可以是直接返回錯(cuò)誤，通過客戶端重試來(lái)解決。

本案例中，如果縮略圖請(qǐng)求在上傳圖片1分鐘后才發(fā)生，則可以在后臺(tái)預(yù)先計(jì)算縮略圖并存儲(chǔ)到緩存。另外就是在上傳圖片的時(shí)候計(jì)算縮略圖，不過會(huì)增加上傳圖片的時(shí)間。

Q3:單點(diǎn)峰值流量，在并發(fā)系統(tǒng)中，除了請(qǐng)求整體的并發(fā)量高，還常見單一熱點(diǎn)資源的并發(fā)請(qǐng)求量很高。例如，1萬(wàn)個(gè)人每人分享了一張圖片，其中9999張圖片的縮略圖請(qǐng)求在10 QPS以內(nèi)，剩下的一張圖片為新聞熱點(diǎn)圖片，峰值請(qǐng)求在10萬(wàn)QPS左右， 系統(tǒng)會(huì)遇到的容量問題包括：1)接口前端機(jī)容量不夠;2)緩存資源單實(shí)例遇到瓶頸。

A3:針對(duì)單點(diǎn)峰值流量可能遇到的性能瓶頸，解決方案如下。

1)接口層容量不夠：這個(gè)問題比較簡(jiǎn)單，只要接口層設(shè)計(jì)是無(wú)狀態(tài)的，當(dāng)容量達(dá)到預(yù)警線，可以通過快速水平擴(kuò)容解決。

2)緩存資源單實(shí)例遇到性能瓶頸：如果使用的是分布式緩存，當(dāng)希望突破單一key的訪問瓶頸時(shí)(這個(gè)瓶頸既有可能是CPU資源緊張，也有可能是單機(jī)網(wǎng)絡(luò)帶寬跑滿，還有可能是磁盤IO吞吐不夠)，一個(gè)辦法是分布式緩存做多副本(x3)冗余設(shè)計(jì)，這樣系統(tǒng)的吞吐量(x3)可以提高3倍，不過成本也提高3倍。另外一個(gè)辦法是針對(duì)極熱點(diǎn)數(shù)據(jù)，除了分布式緩存，同時(shí)在前端機(jī)上打開localCache，依靠數(shù)量眾多的前端機(jī)來(lái)抗極熱點(diǎn)請(qǐng)求。