QQ會(huì)員活動(dòng)運(yùn)營(yíng)平臺(tái)（AMS），是QQ會(huì)員增值運(yùn)營(yíng)業(yè)務(wù)的重要載體之一，承擔(dān)海量活動(dòng)運(yùn)營(yíng)的Web系統(tǒng)。在過(guò)去四年的時(shí)間里，AMS日請(qǐng)求量從200-500萬(wàn)的階段，一直增長(zhǎng)到日請(qǐng)求3-5億，最高CGI日請(qǐng)求達(dá)到8億。在這個(gè)過(guò)程中，AMS在架構(gòu)方面發(fā)生了大幅度的調(diào)整和變遷，我們走過(guò)了一段非常難忘的技術(shù)歷程。

本文將會(huì)分享QQ會(huì)員活動(dòng)運(yùn)營(yíng)平臺(tái)的架構(gòu)設(shè)計(jì)實(shí)踐，希望對(duì)做技術(shù)的同學(xué)有所幫助。

一、海量活動(dòng)運(yùn)營(yíng)的挑戰(zhàn)和我們的應(yīng)對(duì)思路

一個(gè)產(chǎn)品業(yè)務(wù)的發(fā)展總是離不開(kāi)運(yùn)營(yíng)二字，而運(yùn)營(yíng)的表現(xiàn)形式很多會(huì)體現(xiàn)到活動(dòng)需求上，越是重運(yùn)營(yíng)的產(chǎn)品業(yè)務(wù)，通常會(huì)產(chǎn)生越多的活動(dòng)運(yùn)營(yíng)開(kāi)發(fā)需求。

當(dāng)我們說(shuō)起“活動(dòng)”，很多人的第一反應(yīng)會(huì)覺(jué)得這是一個(gè)并不會(huì)有很多技術(shù)難度的一個(gè)東西。通常來(lái)說(shuō)，如果我們只做1-2個(gè)活動(dòng)，那的確是沒(méi)有太多技術(shù)難度的，但是，如果我們將這個(gè)量級(jí)提升到做1000個(gè)活動(dòng)，甚至更多的時(shí)候，這就成為一個(gè)的技術(shù)難題。

1. 活動(dòng)運(yùn)營(yíng)業(yè)務(wù)的挑戰(zhàn)和難題

（1）騰訊SNG增值業(yè)務(wù)面臨海量活動(dòng)運(yùn)營(yíng)開(kāi)發(fā)的挑戰(zhàn)

騰訊的增值產(chǎn)品部在QQ會(huì)員體系、游戲運(yùn)營(yíng)、個(gè)性化等各個(gè)業(yè)務(wù)上都需要持續(xù)高強(qiáng)度的運(yùn)營(yíng)性活動(dòng)來(lái)促進(jìn)用戶的拉新、活躍和留存，這里本身已經(jīng)產(chǎn)生了非常多的運(yùn)營(yíng)需求。而且，自2014年開(kāi)始，隨著移動(dòng)互聯(lián)網(wǎng)邁向成熟階段，手Q平臺(tái)上的手游運(yùn)營(yíng)需求大爆發(fā)，一個(gè)月需要上線的活動(dòng)出現(xiàn)數(shù)倍的增長(zhǎng)。

（2）活動(dòng)開(kāi)發(fā)的復(fù)雜性

開(kāi)發(fā)一個(gè)活動(dòng)本身需要一定的工作量。尤其是大型的推廣活動(dòng)，這類型的活動(dòng)對(duì)功能和性能的要求比較高。一個(gè)典型的大型活動(dòng)通常有數(shù)千萬(wàn)的用戶參與，因此，對(duì)性能要求比較高，如果再涉及到“秒殺”或者“搶購(gòu)”類型的高并發(fā)功能時(shí)，對(duì)于基礎(chǔ)支撐系統(tǒng)是一個(gè)強(qiáng)力的挑戰(zhàn)。

活動(dòng)功能眾多，包括禮包、抽獎(jiǎng)、分享、邀請(qǐng)、兌換、排行、支付等，這些不同的參與和表現(xiàn)形式，也會(huì)涉及更多的后端接口通信和聯(lián)調(diào)。例如，我們的游戲運(yùn)營(yíng)業(yè)務(wù)涉及上百款游戲，而不同的游戲?qū)?yīng)不同的服務(wù)接口，就游戲相關(guān)的通信接口，就涉及上千個(gè)。

還有一個(gè)非常重要的問(wèn)題，就是活動(dòng)運(yùn)營(yíng)的安全和可靠性。因?yàn)?，我們的活?dòng)，大多涉及較重要的實(shí)物獎(jiǎng)品發(fā)放，如iphone、ipad等高價(jià)值禮包，對(duì)安全要求很高。

（3）活動(dòng)運(yùn)營(yíng)開(kāi)發(fā)人力難題

傳統(tǒng)手工開(kāi)發(fā)模式，普通活動(dòng)也需要1周的開(kāi)發(fā)周期，而典型大型活動(dòng)更是需要1-2周開(kāi)發(fā)周期，開(kāi)發(fā)和測(cè)試工作量繁重。并且，很多活動(dòng)是在指定節(jié)假日推廣，通常有嚴(yán)格上線時(shí)間要求。在緊迫并且快速增長(zhǎng)的運(yùn)營(yíng)需求面前，人力非常有限。

目前，全年活動(dòng)上線超過(guò)4300個(gè)。

2. 活動(dòng)本質(zhì)和我們的方法論

通過(guò)對(duì)不同業(yè)務(wù)的活動(dòng)模式的分析和抽象，我們發(fā)現(xiàn)事實(shí)上絕大部分活動(dòng)都可以用一組“條件”和“動(dòng)作”的方式進(jìn)行抽象和封裝，進(jìn)而形成通用的“條件”（Rule）和“動(dòng)作”（Operation）活動(dòng)組件，不同條件和動(dòng)作的組合使用，變成活動(dòng)邏輯的實(shí)現(xiàn)。然后，我們希望通過(guò)平臺(tái)化和框架驅(qū)動(dòng)開(kāi)發(fā)的方式，將這些組件統(tǒng)一封裝。同時(shí)，在框架和平臺(tái)層面，為活動(dòng)組件的運(yùn)行提供高可靠、高性能、具備過(guò)載保護(hù)和水平擴(kuò)展能力的框架支撐環(huán)境。

活動(dòng)組件只需要封裝自身業(yè)務(wù)邏輯，核心功能框架自動(dòng)支持，從而實(shí)現(xiàn)活動(dòng)運(yùn)營(yíng)開(kāi)發(fā)的徹底自動(dòng)化。

AMS所需要承擔(dān)的任務(wù)，就是實(shí)現(xiàn)這個(gè)規(guī)劃。需要面臨的，主要是解決三個(gè)方面的問(wèn)題：

（1）建設(shè)高效活動(dòng)開(kāi)發(fā)模式（運(yùn)營(yíng)開(kāi)發(fā)自動(dòng)化）。

（2）搭建高可靠性和高可用性的運(yùn)營(yíng)支撐平臺(tái)。

（3）保證活動(dòng)運(yùn)營(yíng)業(yè)務(wù)的安全。

二、構(gòu)建高效活動(dòng)運(yùn)營(yíng)開(kāi)發(fā)模式

2012年初，也就是在AMS產(chǎn)生之前的活動(dòng)開(kāi)發(fā)模式，相對(duì)比較隨意，也并沒(méi)有一套嚴(yán)格和完整的框架支持，組件的復(fù)用程度不夠高。因此，我們開(kāi)發(fā)一個(gè)活動(dòng)，經(jīng)常需要耗時(shí)1周多。當(dāng)時(shí)，開(kāi)發(fā)活動(dòng)的其中一個(gè)特點(diǎn)就是“各自為政”，每個(gè)運(yùn)營(yíng)開(kāi)發(fā)同學(xué)，各自產(chǎn)生了一批前端和后端組件，CGI層也產(chǎn)生了很多不同規(guī)則的入口。這些各自實(shí)現(xiàn)的組件，結(jié)構(gòu)比較凌亂，不成體系，維護(hù)起來(lái)也比較困難。最重要的是，這樣的組件對(duì)于活動(dòng)開(kāi)發(fā)來(lái)說(shuō)，使用復(fù)雜，復(fù)用率低，以至于開(kāi)發(fā)效率也比較低。

在當(dāng)時(shí)，活動(dòng)運(yùn)營(yíng)需求也出現(xiàn)了一定程度上的堆積，很多需求沒(méi)有人力支持，產(chǎn)品同學(xué)也覺(jué)得我們上線活動(dòng)比較慢。

1. 系統(tǒng)架構(gòu)分層和統(tǒng)一

基于這個(gè)問(wèn)題，我們當(dāng)時(shí)想到的第一個(gè)解決方案，就是整合前端和后端組件，重新搭建一個(gè)結(jié)構(gòu)清晰和統(tǒng)一的系統(tǒng)。將這個(gè)系統(tǒng)的接口分層、復(fù)用、簡(jiǎn)化的原則，逐步構(gòu)建一個(gè)完整的體系。而且，從我們開(kāi)發(fā)的角度來(lái)說(shuō)，最重要的目的，是為減少活動(dòng)開(kāi)發(fā)的工作量，解放開(kāi)發(fā)人員，提升研發(fā)效率。

我們的前端組件通過(guò)一個(gè)叫Zero的框架統(tǒng)一整合，前端每一個(gè)功能以組件的形式出現(xiàn)，統(tǒng)一維護(hù)和復(fù)用。CGI層則進(jìn)行了代碼重構(gòu)，實(shí)行框架驅(qū)動(dòng)式開(kāi)發(fā)，將每一個(gè)業(yè)務(wù)邏輯功能，收歸到一個(gè)唯一的入口和統(tǒng)一的體系中。核心功能框架自動(dòng)支持，已有活動(dòng)功能組件可直接配置使用。如果沒(méi)有新的功能接入，運(yùn)營(yíng)開(kāi)發(fā)只需要配置一份簡(jiǎn)單的參數(shù)，就可以完成后端功能邏輯，不再需要寫(xiě)代碼。對(duì)于基礎(chǔ)支撐服務(wù)，則以平臺(tái)化的模式進(jìn)行管理，做統(tǒng)一接入和維護(hù)。

當(dāng)我們做完系統(tǒng)結(jié)構(gòu)的調(diào)整后，我們終于實(shí)現(xiàn)，通過(guò)一份活動(dòng)配置，來(lái)控制前端和后端的組件組合。每一個(gè)條件、發(fā)貨等動(dòng)作，都可以隨意動(dòng)態(tài)組合，參與條件通過(guò)“與”、“或”、“非”等組合方式，選擇對(duì)應(yīng)的動(dòng)作，實(shí)現(xiàn)活動(dòng)功能邏輯。

從那時(shí)開(kāi)始，活動(dòng)開(kāi)發(fā)變得簡(jiǎn)單了不少，需要寫(xiě)的代碼大幅度減少，基本變成“填寫(xiě)參數(shù)”的工作。一個(gè)活動(dòng)項(xiàng)目的代碼從之前的1000-2000行，變成了不到100行。

例如，如下圖中，本來(lái)需要寫(xiě)不少邏輯代碼的領(lǐng)取禮包，在前端只變成了一行參數(shù)。

清晰的結(jié)構(gòu)提升了系統(tǒng)可維護(hù)性，更為重要的是，活動(dòng)開(kāi)發(fā)效率也得到了極大的提升。

在開(kāi)發(fā)人力不變的情況下，我們活動(dòng)開(kāi)發(fā)的效率實(shí)現(xiàn)了大幅提升，產(chǎn)品的需求積壓的情況，得到有效的緩解。

2. 高可視化開(kāi)發(fā)模式（自動(dòng)化運(yùn)營(yíng)）

然而，到了2014年，隨著“移動(dòng)互聯(lián)網(wǎng)“的快速發(fā)展和逐步成熟，我們也迎來(lái)了”手游大爆發(fā)“時(shí)代。因?yàn)槭钟蔚拈_(kāi)發(fā)周期更快，幾乎每個(gè)月都有很多款新的手游上線，很快手游活動(dòng)運(yùn)營(yíng)的需求出現(xiàn)了爆發(fā)式的增長(zhǎng)。AMS承擔(dān)的活動(dòng)需求，迅速?gòu)拿總€(gè)月上線60多個(gè)上升到200個(gè)的量級(jí)，在此背景下，開(kāi)發(fā)人力再次捉襟見(jiàn)肘，需求的積壓?jiǎn)栴}進(jìn)一步加劇。

既然說(shuō)到開(kāi)發(fā)人力，就必須介紹一下我們當(dāng)前的活動(dòng)項(xiàng)目模式。我們騰訊是一家成熟的互聯(lián)網(wǎng)公司，研發(fā)流程的每一個(gè)環(huán)節(jié)（設(shè)計(jì)、重構(gòu)、開(kāi)發(fā)、體驗(yàn)/測(cè)試、發(fā)布），都由不同獨(dú)立角色完成。一個(gè)普通的移動(dòng)端活動(dòng)項(xiàng)目耗時(shí)，按照最最快速、最理想的模式計(jì)算：設(shè)計(jì)1天，重構(gòu)1天，開(kāi)發(fā)2天，體驗(yàn)/測(cè)試1天，也至少需要5天工作日 ，也就是研發(fā)周期至少1周時(shí)間。理想是美好的，現(xiàn)實(shí)總是殘酷的。在實(shí)際項(xiàng)目實(shí)施過(guò)程中，因?yàn)楦鞣N資源協(xié)調(diào)和外部因素影響，通常無(wú)法達(dá)到如此完美的配合，因此，一個(gè)普通活動(dòng)的研發(fā)周期，往往都超過(guò)1周。

忽然新增100多個(gè)需求，無(wú)論對(duì)于任何團(tuán)隊(duì)來(lái)說(shuō)，都是一個(gè)巨大的壓力。

于是，我們不得不采用另外一種思路，來(lái)看待活動(dòng)運(yùn)營(yíng)，是否可以嘗試不投入開(kāi)發(fā)人力？我們稱之為“自動(dòng)化運(yùn)營(yíng)“， 自動(dòng)化的本質(zhì)，就是構(gòu)建足夠強(qiáng)大的平臺(tái)和工具支撐，讓運(yùn)營(yíng)同學(xué)自己完成活動(dòng)開(kāi)發(fā)。

前面，我們提到，開(kāi)發(fā)普通活動(dòng)時(shí)，每一個(gè)功能點(diǎn)已經(jīng)變成了一份簡(jiǎn)單的配置，而活動(dòng)開(kāi)發(fā)的工作，就是將這個(gè)配置的活動(dòng)參數(shù)填入到頁(yè)面按鈕上。如果，我們實(shí)現(xiàn)一個(gè)可視化工具，將這個(gè)填寫(xiě)配置的工作，變成拖拽按鈕的功能，這樣就可以徹底告別“寫(xiě)代碼“的工作。

最終的結(jié)果，是我們做一個(gè)可視化拖拽的活動(dòng)模板系統(tǒng)。運(yùn)營(yíng)同學(xué)只需要經(jīng)過(guò)適當(dāng)?shù)呐嘤?xùn)，就能學(xué)會(huì)如何使用。首先，運(yùn)營(yíng)同學(xué)將活動(dòng)設(shè)計(jì)圖上傳，模板系統(tǒng)自動(dòng)切圖（完成重構(gòu)工作），然后，配置活動(dòng)功能，通過(guò)拖拽按鈕功能組件（本質(zhì)上是一個(gè)div透明蒙層），插入到頁(yè)面中。然后點(diǎn)擊體驗(yàn)和發(fā)布，最終完成活動(dòng)上線。因?yàn)槲覀兊墓δ芙M件是早就經(jīng)過(guò)嚴(yán)格測(cè)試，才提供給運(yùn)營(yíng)同學(xué)使用，通常不需要技術(shù)測(cè)試同學(xué)來(lái)做測(cè)試。

因?yàn)閺哪菚r(shí)開(kāi)始，運(yùn)營(yíng)同學(xué)開(kāi)始大規(guī)模替代開(kāi)發(fā)、重構(gòu)、測(cè)試的工作，然而，她們是一群不了解技術(shù)細(xì)節(jié)的人，這里也無(wú)形增加了活動(dòng)的上線風(fēng)險(xiǎn)。因此，除了這個(gè)活動(dòng)模板的實(shí)現(xiàn)之外，我們還根據(jù)AMS平臺(tái)的特性，搭建了一系列的支撐平臺(tái)和工具。

簡(jiǎn)而言之，就是為了避免“人為的失誤“，人的失誤不能靠人本身來(lái)避免，而要靠平臺(tái)和程序來(lái)保證和檢測(cè)。因此，我們建設(shè)了強(qiáng)大而且智能的配置檢查系統(tǒng)和活動(dòng)數(shù)據(jù)監(jiān)控。舉個(gè)例子，本來(lái)資源池里有100個(gè)禮券，但是，運(yùn)營(yíng)同學(xué)誤配置為200個(gè)，這個(gè)時(shí)候平臺(tái)就會(huì)檢測(cè)并且提示運(yùn)營(yíng)同學(xué)，這里配置不正確。

自動(dòng)化運(yùn)營(yíng)給我們帶來(lái)了研發(fā)流程級(jí)別的優(yōu)化，在活動(dòng)研發(fā)流程中，我減少了重構(gòu)、開(kāi)發(fā)和測(cè)試的流程，使得活動(dòng)項(xiàng)目研發(fā)周期大幅度縮短，活動(dòng)項(xiàng)目研發(fā)效率出現(xiàn)質(zhì)的飛躍。手游運(yùn)營(yíng)需求的積壓?jiǎn)栴}，得到根本和徹底的解決。

我們的高效活動(dòng)開(kāi)發(fā)模式的構(gòu)建完成，也促使我們的AMS平臺(tái)業(yè)務(wù)規(guī)模快速的增長(zhǎng)。我們一個(gè)月上線的活動(dòng)項(xiàng)目數(shù)，在2015年10月時(shí)，上線活動(dòng)超過(guò)400個(gè)，而其中有80%以上屬于運(yùn)營(yíng)同學(xué)“開(kāi)發(fā)“的模板活動(dòng)。

三、可靠性與性能支撐建設(shè)

我們通過(guò)構(gòu)建高效的活動(dòng)開(kāi)發(fā)模式，促使我們AMS運(yùn)營(yíng)平臺(tái)的業(yè)務(wù)規(guī)模和流量規(guī)模，都在過(guò)去的三年多時(shí)間里，出現(xiàn)了100倍的增長(zhǎng)，同時(shí)在線的活動(dòng)超過(guò)1000個(gè)。與此同時(shí)，AMS平臺(tái)的可靠性和穩(wěn)定性，也成為至關(guān)重要的指標(biāo)之一，平臺(tái)如果出問(wèn)題，影響面變得很廣。

AMS平臺(tái)的架構(gòu)分為四個(gè)層級(jí)，分別為：入口層、業(yè)務(wù)邏輯層、服務(wù)層、存儲(chǔ)層（CKV的NoSQL存儲(chǔ)），還有一個(gè)離線服務(wù)和監(jiān)控系統(tǒng)。

1. 可靠性

活動(dòng)運(yùn)營(yíng)業(yè)務(wù)，對(duì)平臺(tái)的可靠性非常敏感，因?yàn)檫@里涉及到很多高價(jià)值禮包的發(fā)放，部分還涉及支付環(huán)節(jié)，穩(wěn)定壓倒一切。

在保證可用性方面，我們做幾個(gè)方面的工作：

• 所有服務(wù)與存儲(chǔ)，無(wú)狀態(tài)路由（L5）。這樣做的目的，主要是為了避免單點(diǎn)風(fēng)險(xiǎn)，就是避免某個(gè)服務(wù)節(jié)點(diǎn)掛了，整個(gè)服務(wù)就癱瘓了。實(shí)際上，即使像一些具有主備性質(zhì)（主機(jī)器掛了，支持切換到備份機(jī)器）的接入服務(wù)，也是不夠可靠的，畢竟只有2臺(tái)，它們都掛了的情況，還是可能發(fā)生的。我們后端的服務(wù)，通常都以一組機(jī)器的形式提供服務(wù)，彼此之間沒(méi)有狀態(tài)關(guān)系，支撐隨機(jī)分配請(qǐng)求。

• 支持平行擴(kuò)容。遇到大流量場(chǎng)景，支持加機(jī)器擴(kuò)容。

• 自動(dòng)剔除異常機(jī)器。在我們的路由服務(wù)，發(fā)現(xiàn)某個(gè)服務(wù)的機(jī)器異常的時(shí)候，支持自動(dòng)剔除，等它恢復(fù)之后，再重新加回來(lái)。

• 監(jiān)控告警。實(shí)時(shí)統(tǒng)計(jì)成功率，成功率低于某個(gè)閥值，告警通知服務(wù)負(fù)責(zé)人。

在告警監(jiān)控方面，AMS平臺(tái)的建設(shè)更為嚴(yán)格，我們力求多渠道告警（rtx、微信、郵件、短信），多維度監(jiān)控（L5、模塊間調(diào)用、自動(dòng)化測(cè)試用例、AMS業(yè)務(wù)監(jiān)控維度等）。即使某些監(jiān)控維度失效，我們同樣可以第一時(shí)間發(fā)現(xiàn)問(wèn)題。當(dāng)然，我們也會(huì)控制告警的周期和算法，做到盡量減少騷擾，同時(shí)，又能真正發(fā)現(xiàn)系統(tǒng)問(wèn)題。

可靠性另外的一個(gè)挑戰(zhàn)，就是過(guò)載保護(hù)。不管我們系統(tǒng)擁有多少機(jī)器，在某些特殊場(chǎng)景下，終究有過(guò)載的風(fēng)險(xiǎn)，例如“秒殺“和”定時(shí)開(kāi)啟“之類的推廣面前。AMS當(dāng)前同時(shí)在線的活動(dòng)超過(guò)1000，已經(jīng)太多了，這些活動(dòng)中，偶爾總會(huì)有大流量推廣，并且業(yè)務(wù)方甚至根本沒(méi)有周知到我們。無(wú)論在何種場(chǎng)景下，我們必須做到AMS平臺(tái)本身不能”雪崩“，如果集群掛掉，就影響全量用戶，而做過(guò)載保護(hù)只是拋棄掉了部分用戶請(qǐng)求，大部分用戶還是能夠獲得正常的服務(wù)。

在過(guò)載保護(hù)方面，我們采取了一些并不復(fù)雜的措施：

• 平臺(tái)入口的過(guò)載保護(hù)。經(jīng)過(guò)業(yè)務(wù)特性和機(jī)器運(yùn)營(yíng)經(jīng)驗(yàn)，設(shè)置Apache最大服務(wù)進(jìn)程/線程數(shù)，確保在這一個(gè)數(shù)目下，機(jī)器不會(huì)出現(xiàn)宕機(jī)或者服務(wù)掛掉。

• 后端眾多發(fā)貨接口的保護(hù)。AMS平臺(tái)的背后涉及數(shù)以百計(jì)的后端服務(wù)接口，他們性能參差不齊。通過(guò)AMS平臺(tái)內(nèi)部限流，保護(hù)弱小的后臺(tái)接口。因?yàn)?，如果將它們壓垮了，就?huì)造成某類型的接口完成不可用。

• 服務(wù)降級(jí)。旁路掉非關(guān)鍵路徑，例如數(shù)據(jù)上報(bào)服務(wù)。

• 核心服務(wù)獨(dú)立部署，物理隔離。雞蛋不能放在同一個(gè)籃子里，物理隔離的目的，就是避免業(yè)務(wù)之間相互影響，保護(hù)其他服務(wù)正常工作。

2. 秒殺場(chǎng)景的業(yè)務(wù)保護(hù)

秒殺在活動(dòng)運(yùn)營(yíng)中，是比較常見(jiàn)的一種參與形式，它帶來(lái)的挑戰(zhàn)除了流量沖擊的問(wèn)題，還會(huì)帶來(lái)高并發(fā)下的業(yè)務(wù)邏輯安全問(wèn)題。這個(gè)時(shí)候，我們必須引入適當(dāng)?shù)逆i機(jī)制，來(lái)規(guī)避這些問(wèn)題。它和線程安全是同一類型的問(wèn)題。

首先是用戶的session鎖，也就是說(shuō)，同一個(gè)子活動(dòng)功能中，同一個(gè)用戶，在前一次發(fā)貨請(qǐng)求結(jié)束之前，禁止第二個(gè)請(qǐng)求。之所以要這樣做，是因?yàn)?，如果同一個(gè)用戶發(fā)起兩個(gè)并發(fā)請(qǐng)求，在一個(gè)臨界時(shí)間內(nèi)，可能導(dǎo)致禮包多發(fā)。

例如下圖中的A用戶，在第一個(gè)請(qǐng)求成功寫(xiě)入?yún)⑴c成功標(biāo)志位之前，第二請(qǐng)求是可以通過(guò)“條件判斷“，仍然可以進(jìn)入發(fā)貨環(huán)節(jié)，這樣的話，就可能會(huì)讓A用戶獲得2個(gè)禮包。

還有一個(gè)鎖是基于多個(gè)用戶的秒殺保護(hù)鎖，場(chǎng)景是類似的，Session鎖，只是變?yōu)槎鄠€(gè)并發(fā)用戶，請(qǐng)求同一個(gè)禮包，同樣在判斷禮包余量數(shù)目的臨界時(shí)間里，有可能產(chǎn)生“超發(fā)“（禮包多發(fā)了）。

問(wèn)題很明顯，采用鎖當(dāng)然就可以解決，但是，采用何種的鎖機(jī)制，又是一個(gè)值得思考的問(wèn)題。因?yàn)椋瑯I(yè)務(wù)場(chǎng)景不同，選擇的解決方案自然不同。我們從三個(gè)不同的思路，來(lái)討論秒殺的實(shí)現(xiàn)機(jī)制。

• 隊(duì)列服務(wù)。這是相對(duì)比較簡(jiǎn)單的一種實(shí)現(xiàn)思路，我們直接將秒殺的請(qǐng)求放入隊(duì)列中的，逐個(gè)執(zhí)行隊(duì)列里的請(qǐng)求，就像強(qiáng)行將多線程變成單線程。然而，在高并發(fā)的場(chǎng)景下，請(qǐng)求非常多，很可能一瞬間將隊(duì)列內(nèi)存“撐爆”，然后系統(tǒng)又陷入到了異常狀態(tài)?；蛘咴O(shè)計(jì)一個(gè)極大的內(nèi)存隊(duì)列，也是一種方案，但是，系統(tǒng)處理完一個(gè)隊(duì)列內(nèi)請(qǐng)求的速度，通常無(wú)法和瘋狂涌入隊(duì)列中的請(qǐng)求數(shù)相比。也就是說(shuō)，隊(duì)列內(nèi)的請(qǐng)求會(huì)越積累越多，并且排在隊(duì)列后面的用戶請(qǐng)求，要等很久才能獲得“響應(yīng)“，無(wú)法做到實(shí)時(shí)反饋用戶請(qǐng)求。

• 悲觀鎖思路。悲觀鎖具有強(qiáng)烈的獨(dú)占和排他特性，用戶請(qǐng)求進(jìn)來(lái)以后，需要嘗試去獲取一個(gè)鎖資源，獲得鎖資源的請(qǐng)求可執(zhí)行發(fā)貨，獲取失敗的則嘗試等待下一次搶奪。但是，在高并發(fā)場(chǎng)景下，這樣的搶奪請(qǐng)求非常多，并且不斷增加，導(dǎo)致這種請(qǐng)求積壓在服務(wù)器。絕大部分請(qǐng)求一直無(wú)法搶奪成功，一直在等待（類似線程里的“餓死“）。用戶也同樣無(wú)法獲得實(shí)時(shí)響應(yīng)和反饋。

• 樂(lè)觀鎖思路。相對(duì)于“悲觀鎖”采用更為寬松的加鎖機(jī)制，采用帶版本號(hào) （Version）更新。實(shí)現(xiàn)就是，這個(gè)數(shù)據(jù)所有請(qǐng)求都有資格去修改（執(zhí)行發(fā)貨流程），但會(huì)獲得一個(gè)該數(shù)據(jù)的版本號(hào)，只有版本號(hào)符合的才能更新成功（版本不相符，也就是意味著已經(jīng)被某個(gè)請(qǐng)求修改成功了），其他用戶請(qǐng)求立刻返回?fù)屬?gòu)失敗，用戶也能獲得實(shí)時(shí)反饋。這樣的好處，是既可以實(shí)現(xiàn)鎖的機(jī)制，又不會(huì)導(dǎo)致用戶請(qǐng)求積壓。
  
  

我們業(yè)務(wù)鎖采用的是樂(lè)觀鎖的實(shí)現(xiàn)方式，因?yàn)槲覀兊囊粋€(gè)發(fā)貨流程通常耗時(shí)超過(guò)100ms，在高并發(fā)下，都容易產(chǎn)生請(qǐng)求積壓，導(dǎo)致我們無(wú)法做到實(shí)時(shí)反饋。我們的實(shí)現(xiàn)，確保不管用戶是否請(qǐng)求秒殺成功，都能在500ms內(nèi)獲得實(shí)時(shí)反饋。并且，我們將這個(gè)實(shí)現(xiàn)廣泛使用到各個(gè)秒殺和搶購(gòu)活動(dòng)中，曾經(jīng)支撐過(guò)5w/s的秒殺活動(dòng)，表現(xiàn)非常平穩(wěn)和安全。

四、業(yè)務(wù)安全體系建設(shè)

隨著業(yè)務(wù)規(guī)模的增長(zhǎng)，AMS平臺(tái)每天發(fā)出去的發(fā)貨操作也越來(lái)越多。在非節(jié)假日每天發(fā)貨5000多萬(wàn)，在高峰的時(shí)候，發(fā)貨超過(guò)2億。同時(shí)，這里活動(dòng)中含有很多高價(jià)值的東西，例如ipad、iphone、高價(jià)值虛擬道具，甚至還有一些活動(dòng)推廣使用現(xiàn)金禮包（財(cái)付通到賬）。

如此，我們的業(yè)務(wù)安全比普通的互聯(lián)網(wǎng)產(chǎn)品的要求更高，更嚴(yán)格。

1. 傳統(tǒng)安全打擊維度和惡意用戶

成熟的互聯(lián)網(wǎng)公司通常都會(huì)有自己的安全團(tuán)隊(duì)，一般通過(guò)數(shù)據(jù)建模的方式，搭建出一個(gè)惡意用戶黑名單的數(shù)據(jù)庫(kù)，然后持續(xù)維護(hù)這些惡意賬號(hào)和IP等信息，更新數(shù)據(jù)。然后，我們這個(gè)服務(wù)接入到里面去。惡意工作室手持大量的賬號(hào)和IP，而我們通過(guò)這個(gè)惡意數(shù)據(jù)庫(kù)，將它們攔截掉。

但是，數(shù)據(jù)建模的算法不管如何精細(xì)，為了防止誤殺真實(shí)用戶，總會(huì)存在打擊率的問(wèn)題，它們通常無(wú)法攔截下全部惡意請(qǐng)求，總會(huì)有少數(shù)的漏網(wǎng)之魚(yú)。

而我們所思考的，就是在這個(gè)基礎(chǔ)上，結(jié)合業(yè)務(wù)，增加新的安全保護(hù)策略?？赡軙?huì)有很多人會(huì)想，追加參與門(mén)檻是否可以取得進(jìn)一步的保護(hù)效果呢？例如，在傳統(tǒng)安全打擊策略的基礎(chǔ)上，再加上業(yè)務(wù)限制，例如將活動(dòng)參與條件設(shè)置為超級(jí)會(huì)員（20元一個(gè)月的付費(fèi)會(huì)員），這樣的話，我們以更高的門(mén)檻來(lái)攔截惡意請(qǐng)求。

在以前很長(zhǎng)一段時(shí)間里，我都認(rèn)為這種方法應(yīng)該是靠譜的，因?yàn)樘岣吡藚⑴c的門(mén)檻。直到有一次，我們捕獲到一批好幾萬(wàn)的惡意QQ號(hào)碼（都是一些號(hào)碼很長(zhǎng)的垃圾號(hào)碼），它們竟然全部都是超級(jí)會(huì)員，惡意工作室竟然花費(fèi)了不少錢(qián)給它們開(kāi)通20塊錢(qián)一個(gè)月的超級(jí)會(huì)員。從那個(gè)時(shí)候開(kāi)始，我開(kāi)始明白，付費(fèi)會(huì)員身份限制，也是不可靠的。

超級(jí)會(huì)員的身份帶給這些惡意號(hào)碼更多的便利，反而可以給它們獲取更多高價(jià)值禮包的機(jī)會(huì)，將獲得東西兌現(xiàn)成金錢(qián)，然后覆蓋掉惡意工作室的“投資成本”。

2. 業(yè)務(wù)安全支撐體系建設(shè)

AMS建設(shè)多個(gè)維度，全方面的安全支撐能力。我們將這些安全建設(shè)，又分為四個(gè)維度：

• 入口安全：和用戶對(duì)接的CGI入口，過(guò)濾惡意和攻擊請(qǐng)求，保護(hù)業(yè)務(wù)邏輯安全等。

• 人的失誤：開(kāi)發(fā)和運(yùn)營(yíng)同學(xué)在管理端的誤操作或者配置錯(cuò)誤，人的失誤不能靠人去保證，而應(yīng)該建設(shè)平臺(tái)級(jí)別的權(quán)限管理和智能檢測(cè)，讓人不容易“失誤”。

• 運(yùn)營(yíng)監(jiān)控：多維度建設(shè)對(duì)業(yè)務(wù)狀態(tài)的監(jiān)控，確?？焖侔l(fā)現(xiàn)問(wèn)題。

• 審計(jì)安全：將敏感的權(quán)限充分收歸、管理、監(jiān)控，確保可控可追溯。