我這邊是在京東某部門負(fù)責(zé)營(yíng)銷活動(dòng)的開發(fā)，大家所知道的秒殺其實(shí)就是活動(dòng)的一種,這些活動(dòng)有個(gè)共同點(diǎn),就是流量極大.首先每個(gè)商品你都要知道他是不是活動(dòng)商品厨钻？屬于什么活動(dòng)商品垮庐？我有沒有購(gòu)買資格？活動(dòng)的開團(tuán)時(shí)間是什么礼饱？活動(dòng)有哪些商品，每個(gè)商品的活動(dòng)疊加結(jié)果是什么？還有許多活動(dòng)有庫(kù)存的概念,比如秒殺或者限量購(gòu)镊绪，邏輯很復(fù)雜匀伏，這里里面有太多太多的細(xì)節(jié)，很多細(xì)節(jié)可能沒法一一說(shuō)清楚蝴韭，這里總結(jié)些重要的秒殺的問題以及解決方案給大家,不扯虛的够颠，全部是線上沉淀下來(lái)的純干貨；

這里我以我做的一個(gè)最有意思的營(yíng)銷活動(dòng)榄鉴，先給大家介紹一下履磨，不涉及技術(shù),只是后面出案例會(huì)以此為案例而已，看技術(shù)可以跳過(guò)

我這個(gè)活動(dòng)叫做《周期循環(huán)購(gòu)》庆尘，這個(gè)活動(dòng)可以選擇參與的商品剃诅，活動(dòng)支持設(shè)置活動(dòng)總的有效時(shí)間(比如2022-02-02 12:21~2033-12-02 13:22`)，另外我們還支持讓你選擇周一到周日哪幾天是開團(tuán)日（比如周三驶忌，周五）矛辕，每個(gè)開團(tuán)日再進(jìn)行設(shè)置哪幾個(gè)時(shí)間段為開團(tuán)時(shí)段（比如00：00~01:00，12:00:02:00）付魔，然后還支持設(shè)置商品在每個(gè)時(shí)段的庫(kù)存是多少那么其實(shí)在這里看聊品，團(tuán)購(gòu)的商品對(duì)于我來(lái)說(shuō)就是一個(gè)產(chǎn)品的概念（SPU），而我的營(yíng)銷活動(dòng)限制的庫(kù)存才是真正的庫(kù)存（SKU）,另外這個(gè)又涉及到周期性庫(kù)存的概念,每天每個(gè)時(shí)間段都有一個(gè)自己的獨(dú)立庫(kù)存,這比單一的商品庫(kù)存要復(fù)雜許多許多几苍。

正文：

一.明確團(tuán)購(gòu)秒殺為什么不好做翻屈？

不好做，說(shuō)道理是由于團(tuán)購(gòu)屬于折扣商品妻坝，通常價(jià)格比較低妖胀，流量真的極大，并發(fā)訪問下容易造成各種并發(fā)癥惠勒，舉幾個(gè)例子如下：

• 服務(wù)器流量赚抡，負(fù)載極高，萬(wàn)一掛了就玩球了纠屋，這里可以指業(yè)務(wù)涂臣、中間件、數(shù)據(jù)庫(kù)等服務(wù)器售担，比如數(shù)據(jù)庫(kù)我們都知道抗壓能力不咋地赁遗；
• 流量不均勻，有些時(shí)候會(huì)有部分熱門商品（比如首發(fā)的iphone）特別高頻訪問族铆，把服務(wù)器資源全給占用了其他商品就被擱置排隊(duì)了岩四；
• 邏輯復(fù)雜，下單和回滾或者取消訂單要保證冪等哥攘，防止數(shù)據(jù)不一致以及超買超賣的可能剖煌，萬(wàn)一造成資損材鹦，大家都知道這個(gè)的嚴(yán)重性；

二.如何解決秒殺可能帶來(lái)的問題呢耕姊？我這里提出一些我在項(xiàng)目里使用的經(jīng)驗(yàn)和技巧

2.1.解決高流量問題

首先流量過(guò)高桶唐，處理速度慢是根本原因，因此我們最先解決這部分問題茉兰；

秀一下隨便一周時(shí)間里我的服務(wù)tp指標(biāo)尤泽，高峰期tp99也就18毫秒

2.1.1 訪問類請(qǐng)求；

• 隔離動(dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)规脸，靜態(tài)數(shù)據(jù)可以前置到用戶端或者CDN里坯约，比如商品圖片這玩意,這樣非必要的請(qǐng)求就可以攔截一部分了；
• 后端數(shù)據(jù)加緩存莫鸭，讓高性能的玩意直面高并發(fā)鬼店，比如我上面提到的營(yíng)銷活動(dòng)，目前基本上做到了查詢?nèi)烤彺婊胁樵內(nèi)孔逺edis緩存，大家都知道Redis的性能吧睁壁；
• 限頻寒屯，比如限制用戶對(duì)于同一商品詳情頁(yè)的刷新次數(shù)，大家是不是經(jīng)常會(huì)在活動(dòng)開始的時(shí)候瘋狂刷新....到刷新頻次的時(shí)候可以顯示的提示惑畴，也可以默默的請(qǐng)求無(wú)效化蛋欣，另外這種限制盡量前置化，
• 層層過(guò)濾如贷，另外涉及到數(shù)據(jù)校驗(yàn)的陷虎，如果大家的系統(tǒng)有多個(gè)層次（比如前端->api站點(diǎn)等->server），最好做好層層過(guò)濾杠袱，每個(gè)層次都將一部分?jǐn)?shù)據(jù)攔截了尚猿，比如前端可以做限頻，api站點(diǎn)層做風(fēng)控楣富，數(shù)據(jù)校驗(yàn)等等凿掂，這樣最后有效請(qǐng)求就少了許多了；
• 任務(wù)拆分纹蝴，尤其IO型庄萎，很多時(shí)候我們有些調(diào)用是不需要嚴(yán)格保障串行化的，比如獲取商品詳情接口塘安，可能里面需要展示優(yōu)惠券信息糠涛，以及該用戶購(gòu)買該商品的價(jià)格，庫(kù)存余量兼犯，那么我們這里可能需要調(diào)用券服務(wù)A忍捡，計(jì)價(jià)服務(wù)B集漾，庫(kù)存服務(wù)C三個(gè)服務(wù)的接口，這三接口就沒有先后順序锉罐，并且都是比較耗時(shí)的服務(wù)帆竹，串行調(diào)用耗時(shí)A+B+C，比如0.4+0.5+0.5=1.4秒脓规，那么我們多線程分發(fā)任務(wù)去調(diào)用的話栽连，總耗時(shí)就是最長(zhǎng)的服務(wù)時(shí)間即0.5秒。

2.2.2 下單類請(qǐng)求（很多和上面一樣的就不說(shuō)了侨舆，比如層層過(guò)濾）

• 削峰秒紧，如果我們的流量極大，我們可以進(jìn)行削峰限流挨下，推薦大家采用異步下單的方式熔恢，安全可靠，所謂削峰限流我的理解是可以看做銀行柜體臭笆，就算流量再大叙淌，你都要排隊(duì)，能處理多少看銀行的能力愁铺，我有一個(gè)銀行就處理慢點(diǎn)鹰霍，有十個(gè)銀行就處理快點(diǎn)，沒啥問題茵乱，大不了你就辦不成功唄茂洒，當(dāng)然這里注意防止丟單，可以采用分布式事務(wù)瓶竭；

• 延緩請(qǐng)求我們可以訂閱系統(tǒng)負(fù)載督勺，或者一些監(jiān)控服務(wù)，在系統(tǒng)流量極大的時(shí)候斤贰，觸發(fā)答題系統(tǒng)智哀，在大家進(jìn)行下單的時(shí)候進(jìn)行答題，那么有的人答題快有的人答題慢荧恍，大家拼的就不全是手速了盏触，還有腦速，哈哈块饺，最主要的是把開團(tuán)那一瞬間的流量均勻到答題的時(shí)間了赞辩，這點(diǎn)效果顯著；

• 精準(zhǔn)限流授艰，比如我們可以采用付定金預(yù)購(gòu)的方式先把購(gòu)買人群鎖死辨嗽，有幾個(gè)好處：

  • 第一看的人少了，你沒付定金到時(shí)候你看他干啥淮腾？
  • 第二 買的時(shí)候嘗試下單的人少了糟需，只有付了定金的允許下單
  • 第三呢由于定金的存在大家買的時(shí)候會(huì)慎重一些減輕了退貨啥的造成無(wú)用訂單以及商家賣不出去情況屉佳；

• 庫(kù)存緩存化，我們可以把庫(kù)存做到redis里洲押，我們先采用lua(預(yù)查redis庫(kù)存->再預(yù)扣redis的方式)->樂觀鎖扣除mysql庫(kù)存

  • 為什么這里不直接decr預(yù)扣redis要用lua先查redis再預(yù)扣武花？主要是考慮到由于秒殺團(tuán)購(gòu)等屬于賠錢引流的生意,所以大部分請(qǐng)求都是遠(yuǎn)遠(yuǎn)大于庫(kù)存的，因此極有可能買不到杈帐，如果我們直接扣redis体箕，那扣失敗了，咱們不還是要還庫(kù)存加回去嗎
  • 另外呢挑童，要注意由于庫(kù)存的特殊性累铅，我們要保證redis里的數(shù)據(jù)和mysql 的數(shù)據(jù)的一致性，因此我們要使用一些事務(wù)來(lái)保證站叼，比如TCC或者M(jìn)Q事務(wù)實(shí)現(xiàn)娃兽；
  • 這里咱們將mysql庫(kù)存扣減放到了最后一步也減少了mysql鎖競(jìng)爭(zhēng)的過(guò)程了，這性能飛升熬⌒ā投储；

2.2.3 一些別的優(yōu)化以及線上環(huán)境積累的服務(wù)高可靠經(jīng)驗(yàn)

• 引入熱點(diǎn)發(fā)現(xiàn)，數(shù)據(jù)隔離阔馋，精準(zhǔn)路由機(jī)制玛荞，正如我前面所說(shuō)某些商品確實(shí)牛逼，流量極大垦缅，雖然這部分?jǐn)?shù)據(jù)極少，但是卻有可能會(huì)擠壓正常服務(wù)驹碍；

  • 熱點(diǎn)發(fā)現(xiàn)又分為靜態(tài)發(fā)現(xiàn)和動(dòng)態(tài)發(fā)現(xiàn)壁涎，所謂靜態(tài)發(fā)現(xiàn)呢就是在商品還沒賣，我們就知道這個(gè)是不是熱點(diǎn)志秃，比如京東這邊呢就有根據(jù)店鋪流量怔球，過(guò)往同類商品售賣情況啥啥的智能打標(biāo)簽服務(wù)，有個(gè)預(yù)判浮还，一下就知道你是不是熱點(diǎn)了竟坛，動(dòng)態(tài)發(fā)現(xiàn)是某些商品咱們不知道他這么牛逼，然后賣的時(shí)候一下就火爆了（商家都驚喜的笑醒了）钧舌；
  • 數(shù)據(jù)隔離担汤、精準(zhǔn)路由 ，數(shù)據(jù)隔離洼冻，這部分極其熱點(diǎn)的數(shù)據(jù)呢可以把他預(yù)熱到指定的熱點(diǎn)緩存和熱點(diǎn)數(shù)據(jù)庫(kù)避免影響普通商品崭歧，另外為了避免影響呢，我們還要將這部分商品路由到指定服務(wù)器進(jìn)行操作撞牢，路由到指定服務(wù)器還不夠率碾，甚至我們還要加隊(duì)列進(jìn)行排隊(duì),引入極熱點(diǎn)數(shù)據(jù)的異步下單過(guò)程叔营，另外優(yōu)化的點(diǎn)就是如果前面已經(jīng)賣完了就不要傻傻的再一個(gè)個(gè)排隊(duì)嘗試了，直接提前結(jié)束所宰，提前通知绒尊；

• 多級(jí)緩存機(jī)制，雖然說(shuō)Redis單機(jī)就十來(lái)萬(wàn)的并發(fā)就比較牛逼了仔粥，但終歸還是個(gè)第三方服務(wù)的網(wǎng)絡(luò)查詢婴谱，有的時(shí)候redis使用率過(guò)高也可能造成瓶頸，如果我們可以將部分不會(huì)變的數(shù)據(jù)進(jìn)行本地化件炉，進(jìn)行本地緩存勘究，那這樣是效率最高的，用啥都沒這個(gè)好使斟冕，另外也分擔(dān)了redis的壓力口糕。啥是不會(huì)變的呢？比如活動(dòng)信息磕蛇，很多參與618景描，1111的秒殺大促活動(dòng)是不允許隨便變更數(shù)據(jù)的；

• 降級(jí)次要請(qǐng)求秀撇，在下單等重要服務(wù)壓力極大的情況下超棺，我們可以降級(jí)次要請(qǐng)求，將服務(wù)器性能給重要請(qǐng)求用呵燕，比如說(shuō)降級(jí)評(píng)論查詢棠绘，只允許查幾頁(yè)，只允許查一層再扭。另外像雙十一這樣的超級(jí)活動(dòng)日氧苍，可能會(huì)降級(jí)很多服務(wù)，比如不允許活動(dòng)日退貨啊啥的泛范；

• 限流 比如某接口服務(wù)壓測(cè)的極限值是5W qps让虐，我們就設(shè)置為4.5W為限流值，防止服務(wù)突破系統(tǒng)瓶頸罢荡，并做到既可以人工執(zhí)行開關(guān)赡突，也支持自動(dòng)化保護(hù)的措施。這個(gè)一般公司的網(wǎng)關(guān)服務(wù)或者混沌工程里都會(huì)提供該服務(wù)区赵；有一點(diǎn)需要注意的是惭缰，這里的限流其實(shí)也不只是保護(hù)自己的服務(wù)，其他作為被調(diào)用測(cè)的下游小伙伴的服務(wù)這里也起到的保護(hù)作用笼才。

• 兜底 拒絕服務(wù),根據(jù)系統(tǒng)資源的情況从媚，為了防止系統(tǒng)產(chǎn)生不可控的情況，要做到考慮最壞的情況患整，那么最后一招就是直接拒絕服務(wù)了拜效。
  當(dāng)系統(tǒng)負(fù)載達(dá)到一定閾值時(shí)喷众，例如 CPU 使用率達(dá)到 90% 或者系統(tǒng) load 值達(dá)到 2*CPU 核數(shù)時(shí)，系統(tǒng)直接拒絕所有請(qǐng)求紧憾，這種方式是最暴力但也最有效的系統(tǒng)保護(hù)方式到千。例如秒殺系統(tǒng)，我們?cè)谌缦聨讉€(gè)環(huán)節(jié)設(shè)計(jì)過(guò)載保護(hù)：機(jī)會(huì)檢查赴穗，庫(kù)存檢查憔四，下單
  在最前端的 網(wǎng)關(guān) 上設(shè)置過(guò)載保護(hù)，當(dāng)機(jī)器負(fù)載達(dá)到某個(gè)值時(shí)直接拒絕 HTTP 請(qǐng)求并返回 503 錯(cuò)誤碼般眉，在 Java 層同樣也可以設(shè)計(jì)過(guò)載保護(hù)了赵。
  拒絕服務(wù)可以說(shuō)是一種不得已的兜底方案，用以防止最壞情況發(fā)生甸赃，防止因把服務(wù)器壓跨而長(zhǎng)時(shí)間徹底無(wú)法提供服務(wù)柿汛。像這種系統(tǒng)過(guò)載保護(hù)雖然在過(guò)載時(shí)無(wú)法提供服務(wù)，但是系統(tǒng)仍然可以運(yùn)作埠对，當(dāng)負(fù)載下降時(shí)又很容易恢復(fù)络断，所以每個(gè)系統(tǒng)和每個(gè)環(huán)節(jié)都應(yīng)該設(shè)置這個(gè)兜底方案，對(duì)系統(tǒng)做最壞情況下的保護(hù)项玛。

• 依賴隔離-熔斷
  熔斷器與保險(xiǎn)絲有些類似貌笨，當(dāng)電流過(guò)大時(shí)，保險(xiǎn)絲自動(dòng)熔斷以保護(hù)我們的電器襟沮。這里的熔斷也是一樣锥惋，當(dāng)?shù)谌椒?wù)長(zhǎng)期不可用，我們要制定快速失敗策略开伏，防止影響或者拖垮我方服務(wù). 這也是一個(gè)十分重要的點(diǎn)膀跌！
  假設(shè)在沒有熔斷機(jī)制保護(hù)下，我們可能會(huì)無(wú)數(shù)次的重試或慢請(qǐng)求硅则，勢(shì)必持續(xù)加大服務(wù)端壓力或系統(tǒng)耗盡業(yè)務(wù)線程淹父，造成惡性循環(huán)株婴；如果直接關(guān)閉重試功能怎虫，當(dāng)服務(wù)端又可用的時(shí)候，我們?nèi)绾位謴?fù)困介？
  當(dāng)請(qǐng)求失敗比率（失敗/總數(shù)）達(dá)到一定閾值后大审，熔斷器開啟，并休眠一段時(shí)間座哩，這段休眠期過(guò)后熔斷器將處與半開狀態(tài)（half-open）徒扶，在此狀態(tài)下將試探性的放過(guò)一部分流量（Hystrix只支持single request），如果這部分流量調(diào)用成功后根穷，再次將熔斷器閉合姜骡，否則熔斷器繼續(xù)保持開啟并進(jìn)入下一輪休眠周期导坟。
  建議使用場(chǎng)景：Client端直接調(diào)用遠(yuǎn)程的Server端（server端由于某種原因不可用，從client端發(fā)出請(qǐng)求到server端超時(shí)響應(yīng)之間占用了系統(tǒng)資源圈澈，如內(nèi)存惫周，數(shù)據(jù)庫(kù)連接等）或共享資源。

• 異常報(bào)警康栈，異常告警一定要有递递，這個(gè)屬于危機(jī)處理，有哪些方面需要關(guān)注的呢啥么？

  • 服務(wù)器資源告警登舞，涉及CPU、內(nèi)存悬荣、帶寬菠秒、線程、磁盤空間等
  • 服務(wù)質(zhì)量告警隅熙，涉及tp99閾值稽煤、FullGC、異常code囚戚、超時(shí)時(shí)間酵熙、qps閾值等等
  • 中間件質(zhì)量告警，使用了啥一般都需要添加告警規(guī)則驰坊，我這里說(shuō)一些常見的
    • Redis（內(nèi)存使用率（尤其設(shè)置了拒絕淘汰一定要關(guān)注）匾二，tps，相應(yīng)時(shí)間拳芙，bigkey察藐，流入流出流量，hotkey訂閱和告警）
    • MQ（主要關(guān)注擠壓消息量舟扎，內(nèi)存分飞，CPU，消費(fèi)者數(shù)量異常變動(dòng)告警）
    • Mysql（內(nèi)存睹限，CPU譬猫，磁盤空間，連接數(shù)羡疗，阻塞線程染服，等待線程，超時(shí)線程等等）
    • 分布式任務(wù)調(diào)度平臺(tái)（時(shí)間叨恨，積壓數(shù)據(jù)柳刮，超時(shí)等）
    • ES，銀河，混沌秉颗，鷹眼等等等其他平臺(tái)類的或者不常用的這里不說(shuō)了痢毒，自己衡量吧.........

三、應(yīng)急處理原則

• 1蚕甥、保證自己能存活闸准，死道友不死貧道（我們也只能做到自己的可用問題）
• 2、若已雪崩梢灭，快速止損夷家，恢復(fù)可用服務(wù)
• 3、若自己屬于下游敏释，接近瓶頸库快，聯(lián)系調(diào)用方，協(xié)商限流钥顽。

題外話：真正優(yōu)化的地方還有很多很多很多义屏，服務(wù)架構(gòu)也是非常復(fù)雜的，我做項(xiàng)目請(qǐng)教了下這邊做商品服務(wù)的架構(gòu)師蜂大，據(jù)他給我說(shuō)的雙十一商品詳情頁(yè)服務(wù)闽铐，光CPU就用了幾萬(wàn)核。奶浦。兄墅。讓我當(dāng)場(chǎng)就震驚了。澳叉。隙咸。也給我看了下架構(gòu)和服務(wù)的圖，確實(shí)非常非常牛逼成洗！目前京東這邊在備戰(zhàn)春晚紅包五督，流量按照雙十一的十倍以上去備戰(zhàn)，真心期待后面有關(guān)于這次備戰(zhàn)的分享~~

今天關(guān)于應(yīng)對(duì)高流量瓶殃，我就說(shuō)到這了充包，后面有時(shí)間還會(huì)補(bǔ)點(diǎn)細(xì)節(jié)

關(guān)于下單,回滾訂單,定時(shí)取消訂單等可以看我后面寫的這個(gè)http://www.reibang.com/p/a844a1592902

關(guān)于有效訂單的高并發(fā)問題可以看http://www.reibang.com/p/552c4093832e （需要先看上面再看這個(gè)）