這幾年工作中做過不少營銷活動，這裡以抽獎活動為例，讨論一下如何設計出一個高可用、高并發的營銷系統。
高可用、高并發架構的核心是分流和限流。系統架構時，應根據每一種營銷活動的場景與特性，制定不同的分流、限流方案。
一 業務
在開始進行架構讨論前，我們的簡單描述一下業務，以友善我們有針對性的進行讨論。
1. 業務需求
公司希望拉更多的新使用者來注冊我們的app，是以想通過一個抽獎活動，用一些獎勵和刺激的手段來促使使用者使用我們的app，并通過獎勵手段讓使用者幫我們一起推廣宣傳。業務主要訴求如下：
使用者需要在app中或者活動頁面（H5）中進行某些操作，以擷取抽獎機會；例如分享給好友以後獎勵一次抽獎機會。
每天每人最多擁有N次抽獎機會。
活動結束後給中獎使用者發獎品。
每個人隻能中一次獎。
……
2. 抽獎主流程
這是系統的核心流程，也是後面進行性能優化的核心内容。
3. 分析
對活動而言，最重要的是曝光量，隻有更多的分享與傳播，才能讓更多的人參與進來，活動效果才越好，對技術上的要求就是能夠提供盡可能好的使用者體驗。
抽獎活動的頁面中，大部分内容都是靜态的，隻有抽獎按鈕需要與服務端互動；對此可以通過用戶端、CDN緩存等提升使用者體驗。
營銷活動是拿真金白銀來推廣，是以需要有效的機制能防止被人惡意攻擊，将全部獎品刷走。
如果活動中獎品價值都較高，此種情況下，通常獎品數量有限，中獎機率不高，是以即便是抽獎的并發量較大，實際寫DB的壓力也并不大，即在扣減獎品庫存、向DB中插入中獎記錄等環節的寫壓力并不會大。
如果活動發放類似于優惠券的虛拟獎品，數量可能很大，中獎機率非常高，那麼當抽獎并發量大時，寫DB的壓力會很大。
二 核心名額
1. 高并發
營銷活動對系統性能的要求，一般來說比正常業務高出很多；如果推廣的效果比較好，流量可能會遠超初始預期。基于此，系統應該能夠支援較高的并發，并且在流量快速上升并超過容量規劃時，能夠及時、友善擴容。
2. 高可用
核心是提供盡可能好的性能支援，讓更多人能夠使用我們的産品。具體見高性能優化部分内容
3. 隔離性
營銷活動不能影響正常業務；因為營銷活動變動頻繁，修改時應盡可能的避免影響到其他業務；前一次活動應該能夠沉澱出一些内容，降低下一次類似的活動的實作成本。
4. 低耦合
根據上面的需求我們可以看到，營銷活動旺旺與主業務有交集。營銷活動的特點是變化頻繁，定制化需求多，應盡量降低營銷活動與正常業務的耦合性。
可以考慮通過旁支流程來解決此問題。例如，使用者在app上操作以後獎勵抽獎機會這個業務，将使用者的行為作為事件，通過MQ消息向外廣播，營銷活動監聽相關的MQ消息，根據MQ消息給使用者獎勵抽獎機會。
5. 防刷
在營銷活動利益的驅動下，常常會有人找系統漏洞，鑽系統空子，通過一些手段來刷系統獎品，影響營銷效果。一般而言，有以下正常問題需要防範：
防惡意注冊使用者
防惡意調用接口
防獎品被少部分人擷取
防使用者誤操作
三 架構
高并發的核心思路是逐級分流，逐漸分散流量。
高可用的核心思路是通過備份、限流、降級、熔斷等手段提升可用性。
1. 整體思路
充分分流，通過緩存、隊列、消息等手段将大流量逐漸分散。
以空間換時間，通過緩存來提升每個請求的處理速度，提升系統并發量。
異步處理，分析并識别出可以異步處理的邏輯，将他們異步化。
分層逐級攔截非法請求，僅讓有效的請求到達底層系統；盡可能讓每一次寫操作都能成功。
根據每個系統的服務能力，設定流量極限，流量超過極限值後進行限流。
2. 分階段優化模型
為了達到最高的并發性能，需要對整個環節的各個環節進行優化。現實中往往通過如下的倒三角形模型來逐層優化。
注意：這裡不過多講述概念性的内容，而是根據抽獎的需求講述一些正常的方案；更多内容見部落格《高并發技術》
用戶端優化方案有：用戶端（app、浏覽器）緩存。
網絡優化方案有：動靜分離、靜态化
服務端優化包括：緩存（硬碟、堆、分布式）、通信模型優化、異步化技術、線程池、DB存儲優化。
響應優化包括：傳回結果壓縮。
3. 緩存政策
通過分層緩存政策，對每一個環節進行有優化，提升性能。
用戶端（或浏覽器）緩存：減少使用者請求數量，降低系統壓力，提升使用者體驗。
CDN緩存：合理地利用CDN，内容緩存放置在離使用者最近的地方，加快響應的速度。
Web伺服器緩存：減小後端應用伺服器壓力，抵擋瞬間峰值和/或針對少量定點内容的攻擊。
應用層緩存：減小後端應用伺服器壓力，加快響應速度。
4. 分流模型
從圖中可以看到，經過前面的逐層分流，最終隻有少部分請求會進行DB操作。當絕大部分的流量都被通過種種手段分擔，系統自然就可以輕松處理剩餘的少量流量，這也就意味着系統可以具有非常高的性能。
四 高并發優化
1. 逐級分流
1) 用戶端緩存
我們的營銷活動都是通過H5來承接的，app通過webview來加載或者直接通過浏覽器加載資料時，可以利用浏覽器緩存或者手機SD卡，将資料緩存在用戶端，例如圖檔、CSS、JS檔案等。
越多的内容從本地緩存讀取，響應速度會越快；不過需要注意緩存資料的更新問題，以及記憶體占用問題。
2) 動靜分離
一個抽獎活動頁面，絕大多數樹内容都是靜态的圖檔、css、js等，極端情況下可能隻有一個抽獎按鈕需要與服務端互動。通過将圖檔、css、js等内容存儲在CDN節點中，使用者浏覽活動頁面時，直接從距離使用者最近的CDN節點擷取靜态資源，不用和服務端互動。優化模型如下：
在營銷活動的場景中，使用此種方案時，至少可以讓90%-95%的流量不用與服務端互動，可以節省大量帶寬，對性能提升非常明顯。
3) 防誤操作
使用者點選抽獎按鈕，調用服務端接口時，當請求的響應速度比較慢時，如果用戶端不做處理，使用者會感覺到卡頓；此種情況下使用者和可能會反複點選抽獎按鈕，這無疑會進一步加大服務端的通路量，服務端的響應速度可能進一步降低；另外因為每點選一次都需要消耗一次抽獎機會，因一次卡頓導緻使用者耗費多次抽獎機會也是不合适的。
這種問題的處理方式比較多，例如：可以通過在H5端通過js控制，點選抽獎按鈕以後，在請求傳回之前将按鈕置灰，禁止使用者再次點選或者彈出一個loading動畫來解決此問題。
這種方案在伺服器壓力大，響應慢時效果比較明顯；另外，可以明顯的提升使用者體驗。
4) 防代碼請求
如果活動的獎勵足夠吸引人，就可能有第三方通過代碼直接調用抽獎接口。因為代碼的執行速度遠快于手的點選動作，這可能給營銷活動帶來非常大的危害，同時也會給系統帶來非常大的并發壓力。因為風控的性能損耗較大，是以在營銷活動中一般不能通過風控系統來解決此問題。
一般而言，每一家公司都會有自己的安全政策，保證請求的安全可靠，應盡可能讓第三方僞造此流程的難度加大；除此之外，營運活動中要能夠識别出異常流量，做好應對措施，盡可能的降低危害。
a) 僞造一個使用者
多個線程中都使用相同的使用者進行請求。這種場景比較好解決，通過userId加一個分布式鎖即可解決。
b) 僞造多個使用者
每個線程使用不同的使用者進行請求。這種比較麻煩，常見處理手段有：
在使用者注冊時加限制，盡可能杜絕通過代碼自動注冊的行為，讓每一個注冊的使用者盡量可靠。
和業務溝通，限制每個使用者每天擷取抽獎機會的次數，限制每人中獎次數。
抽獎機會通過使用者的行為産生。例如：到社群對文章評論以後才給一次機會，這将增大使用者僞造請求的難度。
如果發現一定時間内某個ip下的流量明顯異常，可以對此ip進行限流。例如：一個ip的請求量超過1000/min時，拒絕此ip的請求。注意，此方案可能有誤判，因為當多人使用同一個區域網路時，此時服務端收到的ip可能是相同的。
添加小黑屋功能，發現惡意使用者、ip，将他們拉入小黑屋，一段時間内禁止他們後續的通路。
5) 業務規則攔截
根據前文中的需求我們可以得出：同一個使用者隻允許中一次獎；每天最多抽獎三次。當收到抽獎請求時，我們可以判斷是否符合這這些規則：
可以将中獎使用者放在緩存中，收到抽獎請求或抽中時，通過緩存校驗此使用者之前是否已中獎。
可以将抽獎次數放在緩存中，通過計數器自減的方式扣減抽獎機會。
2. 緩存
大量的運算将消耗大量伺服器資源，頻繁的DB操作也會給DB帶來較大的壓力，在高并發場景中，常常通過緩存運算結果或者DB記錄，以降低資源消耗，提升請求的響應速度。
1) 緩存不常變動的資料
緩存非常适合存儲不經常變動的資料，通過緩存他們可以極大的提升性能。
如，活動中獎品一般不會頻繁改變，頁面中需要展示獎品資訊時，我們可以将獎品資訊加載到緩存中，每次請求時直接讀取緩存。
2) 緩存實時性要求不高的資料
業務上如果對某些資料的實時性要求并不高，那麼也可以通過緩存降低系統的性能損耗，提升請求速度。
如：活動中需要播報中獎資訊，業務上并不要求實時展示最新中獎的幾人，是以可以通過啟動一個線程，将最近一段時間内需要播報的名單加載到緩存中，播報時從緩存中直接傳回資料。
3) 頻繁變動的内容走緩存
頻繁變動且持久化意義不大的資料非常适合走緩存。
如，使用者完成一些任務以後，獎勵一些抽獎機會，獎勵的抽獎機會就很适合存儲在緩存。使用redis或者tair的原子性加、減操作，每獎勵一次抽獎機會，自增1，每抽獎一次，自減1。
4) 從緩存減庫存
抽中獎品時，需要将此獎品總數減1，這其實就是一種減庫存操作。并發情況下從DB中減庫存，一來性能比較差，二來為了避免髒寫可能導緻DB更新失敗機率大增。此時改為從緩存中減庫存。
a) 減庫存
活動開始前，将獎品庫存加載到緩存。
抽獎時直接從緩存中扣除；如果扣除庫存以後，剩餘獎品數量>=0，表示扣減庫存成功，然後發送MQ消息；如果庫存扣除後，剩餘獎品數量<0，表示扣減庫存失敗。
收到MQ消息後扣減DB中庫存，插入中獎記錄。（扣減商品庫存不是一個必須的操作）。
此種方案的缺點是：活動期間如果需要修改庫存資訊，則需要特别注意資料一緻性，避免出現獎品超發問題。
b) 緩存更新模型
使用此方案時，如果活動期間營運希望增加/減少獎品庫存，需要先暫停活動，更新庫存并重新整理到緩存，然後取消暫停，讓使用者繼續抽獎。暫停操作是為了防止因為異步扣減獎品庫存而導緻獎品超發。模型如下：
5) 選擇合适的資料結構
緩存中間件，例如Redis提供了多種資料結構，分别适合不同場景的需求。使用時根據具體場景，選擇最合适的資料結構，盡量選擇時間複雜度底的資料結構，盡可能減少與緩存的互動次數。如：抽獎時需要扣減抽獎次數，有兩種方式從緩存中扣減使用者剩餘抽獎次數：
方式一：先從查詢目前剩餘緩存；記憶體中扣減次數，最後将結果剩餘次數重新放回緩存。
方式二：直接通過自減指令進行扣減操作，如果結果大于0，那麼允許抽獎。
兩種方式雖然都能滿足需求（這裡暫不考慮并發情況下更新緩存時的失敗問題），但是第二種方式可以減少一次與緩存的互動。伺服器與緩存伺服器交換一次資料的時間約為1ms-3ms，即便一次請求隻節省一次互動，當請求量達到1000w次，可為伺服器累計節省2.7-8.3h；當并發量非常高時，這種性能損耗也是不能忽略的。
6) 使用堆緩存
使用分布式緩存時，因為每次與緩存互動都要消耗1ms-3ms時間（如果傳回資料量較大時，由于IO瓶頸的存在，耗時可能進一步增加）。一個抽獎請求需要與緩存進行多次互動，當高并發時，累計出來的性能的損耗會非常明顯，此時可以考慮将資料緩存在堆記憶體中。
例如：抽獎活動的各個頁面中需要檢視獎品資訊，抽獎過程也需要根據獎品機率進行計算是否中獎，等等。如果每次都從緩存中取，性能損耗不可接受，那麼可以将獎品資訊放到記憶體中，徹底省略掉這部分與緩存互動的時間。
此方案的缺點是：伺服器重新開機時記憶體中資料會丢失；DB資料變更以後，需要確定每台伺服器都更新到最新的資料。
7) 緩存失效
使用緩存時，需要小心應對緩存擊穿問題。在高并發場景中一般采用異步将資料重新整理到緩存；請求過程中即便發現緩存中資料不存，也不會從DB中讀取。有幾種種常見的做法應該盡量避免：
緩存沒有資料時，從db中擷取，然後放到緩存中。此方式無法防止緩存擊穿時，将流量全部傾瀉到底層服務或DB上，而引起的雪崩。
通過鎖讓一個線程從DB中擷取資料，然後存到緩存中，其他線程等待。這種做法一來程式設計麻煩，二來等待的線程較多時占用的記憶體也會比較大，伺服器相應速度明顯降低。
3. 異步發放獎品
一般而言，在高并發場景中，對性能影響最大的就是DB性能，如果通過同步方式寫DB，那麼DB的瓶頸将直接決定并發量（DB也存在多種優化政策）。
1) 異步方案分析
因為使用異步方式常常會帶來優秀的性能，是以隻要業務沒有明确要求獎品需實時發放，都可和業務方溝通，考慮是否可以通過異步發放獎品。在我們的場景中，我們和業務方溝通，如果使用者中獎，我們保證3分鐘内會讓使用者在自己的賬戶中看到中獎紀錄。而實際上99%以上的場景中，我們的異步化方案會在毫秒級别就可以将中獎紀錄插入DB中。
一般來說每個獎品都是有數量的，每被人抽中一個，那麼庫存應該減一。如果多人同時抽中一個獎品，那麼就存在并發寫的問題。并發寫是很容易失敗的，失敗以後重試也會損耗性能；另外應該保證獎品不會多發放。
a) MQ消息方案
中獎時發送一條MQ消息，收到MQ消息以後，将中獎資訊入庫。我們使用的是RocketMQ作為消息伺服器，因為RocketMQ優秀的性能表現，隻要我們消費過程不出現阻塞，消息可以在毫秒級别到達消費端；而當消費端阻塞時，可以通過增加伺服器來水準擴充。目前有多中成熟的MQ伺服器可供選擇，可以根據公司的實際情況進行選擇。
b) 日志方案
将中獎紀錄寫在伺服器所在的磁盤檔案中，另外啟動線程從磁盤檔案中讀取中獎紀錄然後入庫。使用此種方案時需要注意，讀檔案和寫檔案的并發性問題。
c) 分布式隊列方案
使用分布式隊列，如Redis的隊列，中獎時通過LPUSH指令向隊列中加入中獎記錄資料，每個伺服器啟動一個線程通過RPOP指令從隊列中擷取中獎記錄資料，然後入庫。因為Redis的性能很好，是以往Redis隊列中寫記錄的速度非常快，抽獎過程的性能損耗非常小，性能自然也就提上來了。
以上是常見的幾種處理手段，其實所有分布式隊列、消息隊列都可以作為設計時的考慮對象，我們在選用的是使用RocketMQ來異步化
2) 抽獎流程改進
通過緩存控制庫存扣減，減庫存成功，則通過MQ消息将中獎事件發送出去；傳回使用者中獎資訊；異步收MQ消息，然後對DB中的記錄進行減庫存操作。
因為進行了異步化操作，是以不會因為寫DB的性能影響抽獎流程的并發量。
4. 流程優化
1) 流程順序調整
現實中，為了追求更高的性能，可能會對流程進行定制優化。例如：如果整個活動中獎機率比較低，那麼可以考慮将部分驗證邏輯向後移，以減少每個請求的耗時，如下圖所示：
和前面的流程圖相比，唯一的差别是将活動資訊檢查放在了機率計算之後。
伺服器與緩存互動一次的時間大概是1ms-3ms，假設活動資訊放在緩存中，中獎機率為5%。先檢查活動資訊和後檢查活動資訊兩種方案，當後檢查活動資訊在請求量達到1000w時，可以總共節省約8.3h-25h，節省出來的時間是不是很驚人！！！
2) 放棄重試
失敗重試會影響系統性能，重試次數越多，對系統性能的影響越大。
抽獎過程中，從抽獎資訊驗證到扣庫存、中獎資訊入庫的整個過程中，任何一個環節異常或失敗，我們都不會進行重試，全部當做未中獎處理，這是由抽獎的業務場景決定的，即：抽獎本身是随機的，不需要保證100%中獎。如果業務上要求100%中獎，可以在流程最後添加一個“補償獎品環節”，即：傳回失敗資訊之前，在給使用者發一個獎品，不修改前面的整個流程。
面對不同業務場景是，要仔細分析每種業務場景的特性，分别采用不同的政策。
5. 部署優化方案
為了支撐更高的并發，追求更好的性能，可以對伺服器的部署模型進行優化，這裡給出一種方案。
如果走完整的流程，性能損耗無法接受時，可以通過增加A叢集的機器，當負載均衡到達A伺服器的請求直接扣減抽獎機會，整個流程得到極大簡化，性能成倍提高。
此種方式的缺點是：部署複雜，開發時需要維護兩套邏輯。
五 高可用優化
高可用涉及的技術比較多，具體可以參考部落格：《高可用技術》，這裡從活動中使用到的幾個手段進行讨論。
1. 多執行個體部署
多執行個體部署；營銷系統内部無狀态，并可以通過水準擴充，提升系統性能。
2. 隔離技術
隔離技術的核心是防止壓力、異常等互相傳導，導緻服務不穩定甚至不可用。
在我們的抽獎活動中，我們使用到的隔離技術有：系統隔離、資料隔離、動靜分離、故障隔離。如：營銷活動的系統獨立于負責正常業務的系統，以避免互相幹擾；DB、RocketMQ使用獨立的叢集，防止影響其他核心業務；通過動靜分離技術，降低帶寬占用；隔離各個系統的異常。
3. 限流技術
業務上主要通過計數器的方式進行防刷性限流，例如：單個ip的流量超過300/min，一段時間内不再接收此ip的其他請求；通過使用者id限制抽獎次數、中獎次數；等等。
通過設定tomcat Connector、db連接配接池、緩存連接配接池等限制上遊流量和對下遊的壓力。
六 重要問題
除了需要支援高并發，保證高可用外，還有幾個重要的問題需要注意，他們在項目中中也非常重要。
1. 防止獎品超發
防止獎品超發，其實就是在并發場景中，對同一條記錄修改時，如何防止不會出現髒寫問題。一般而言有以下幾種解決方案：
1) 鎖
a) 樂觀鎖
樂觀鎖通過版本号實作，寫資料之前從DB中讀出記錄目前資訊，更新時where條件中通過版本号對比。典型的sql為：
update prize set stock = stock -1, version =
version +1 where id = #{prizeId} and version = #{version}
優點：性能損耗較低；缺點：并發情況下寫操作容易失敗。
b) 悲觀鎖
悲觀鎖是從db中查詢記錄時通過鎖來限制其他線程通路。典型的sql為：
select * from prize where id = #{prizeId}
for update
優點：可以解決髒寫問題；缺點：性能差。
c) 分布式鎖
寫DB之前，通過分布式鎖保證同時隻有一個線程對同一條記錄進行修改。
優點：解決髒寫問題，性能損耗低；缺點：同一時間隻有一個線程可以寫成功，其他線程全部失敗。
2) 同步隊列
同步隊列的解決方案是将所有對同一條記錄的修改操作收集起來，放在一個隊列中串行執行，以降低規避并發寫時的髒寫問題，以及使用樂觀鎖時的寫失敗問題。常見的方式有兩種：
請求到來以後，将寫操作放到分布式隊列中，另外啟動線程從隊列中不斷讀取資料，然後進行寫操作。因為寫操作放在一個線程中，對于單條記錄來說不會出現并發問題。缺點是：編碼複雜；性能優化較複雜；有多線程方案，但是容易出現資源配置設定不均的問題，難以充分利用系統的資源。
通過資料庫中間件，所有伺服器的寫操作彙聚到資料庫中間件，由中間件維護隊列，這樣同樣可以實作順序寫操作。缺點是：中間件實作難度大；編碼複雜。
3) 緩存+異步
見“異步化發放獎品”流程。現實中我們選用的是緩存+異步的方案。
2. 資源回收問題
現實的業務場景中，我們曾遇到這種問題：活動開始前，計劃活動隻進行1個月；活動中發現效果較好，希望延長活動時間。
在上面讨論流程已經多次提到，我們将很多資訊都放在緩存中，并且了有效期，如果我們設定有效期為1個月，那營運需要延長活動時間時，我們就需要手動延長緩存中的這些資料的有效期。
實際項目中，緩存資料有效期一般不會和業務需求中完全比對，例如業務提需求的時候要求儲存一個月即可，我們會按照約2-3倍的時間進行設定，以防止出現類似的需求變更。
3. 域名問題
活動如果做得好，分享一定少不了。
在現實中，朋友圈最常見的導流管道，但遺憾的是一旦微信發現H5頁面有誘導分享的風險，可能直接将域名封掉。
為了不影響其他業務在朋友圈中的可用性，最好為每個活動申請一個子域名，即便是被封了，也不影響其他業務的使用。
七 量化的性能名額
面對高并發、高可用場景，上面讨論了多種處理對策，每種方案都有其優缺點，實作的難度與成本不同，現實設計、編碼中應該根據活動的并發量預估，進行适當優化。以下是我們評估流量的一些正常做法。
1. 系統服務能力評估
根據營運投入，提前預估活動流量；根據業務特點，分析流量高峰和低谷的規律，通常晚上0點到早上8點的流量為低谷期，剩下的16個小時承擔絕大多數流量。例如：預計活動每天的抽獎次數為1kw左右，可以計算出系統的平均QPS= 1000w/(16*60*60) = 173次/s
根據營運投入與業務特點，評估高峰時流量是平均流量的幾倍，假設是10倍（一般5-8倍就足以滿足需要），那麼系統應該保證在1800次/s的并發量下沒有壓力。
考慮到流量預估可能不準，活動效果好時流量會遠超超過1kw，是以系統設計應該要有足夠的buffer以應此問題。我們一般會預留1-2倍的流量，那麼開發時按照2kw-3kw/天的流量進行系統設計；是以系統應該支援的并發量在3600-5400次/s。
按照這個值進行性能測試，線上機器數量按照性能測試時需要的伺服器進行部署。
2. 資源申請
根據服務能力的預估資料，再加上每次抽獎中與緩存、DB、MQ伺服器等互動的次數，預估需要申請的緩存空間、DB、MQ伺服器資源。
1) 伺服器
根據上面流量評估以及性能測試的結果，預估需要的伺服器數目，線上按照此數目進行部署。
2) 緩存空間評估
根據緩存key-value的大小，計算每個key-value占用的緩存空間，通過每個緩存的空間*預計數量得出緩存占用量。使用相同的方式計算所有緩存占用量；然後彙總得出緩存的總需求量；最後預留1-2倍的緩存空間作為buffer。
3) MQ伺服器資源
根據并發流量計算出發送MQ流量。假設活動中有50%的流量需要發MQ消息，根據上面計算的最大QPS（3600-5400次/s），可以得出寫MQ的流量為1800-2700次/s。
對于RocketMQ這種伺服器來說，這個流量其實不大。但一般而言一個RocketMQ叢集會同時為多個業務提供服務，是以應該和運維確定不會對其他業務産生影響。
使用類似于RabbitMQ伺服器的時候，需要注意消息堆積問題，RabbitMQ消息堆積時，性能會大幅度降低。
4) DB資源
對于Mysql資料庫而言，如果預計單表記錄将超過1000w，應該考慮分表；如果預計單庫資料會達到5-10GB（這個數字是之前DBA建議的數值），應該考慮分庫；預計DB讀寫非常頻繁，單庫壓力大可以考慮讀寫分離。