1 互聯(lián)網(wǎng)架構(gòu)越來越復(fù)雜？

為啥感覺互聯(lián)網(wǎng)架構(gòu)越來越復(fù)雜了，早期我們的系統(tǒng)，可能也就那么少部分人使用，大都是一些后臺(tái)管理系統(tǒng)。
所以不用考慮很多東西，比如：

流量少，無需考慮并發(fā)問題
數(shù)據(jù)少，不用考慮什么索引優(yōu)化、分庫(kù)分表
訪問不集中，不用考慮緩存、過載保護(hù)
如果數(shù)據(jù)不重要，不用考慮安全策略，甚至不用考慮容災(zāi)備份
可重復(fù)提交，所以不用關(guān)系冪等性
允許短暫宕機(jī)和定期關(guān)停維護(hù)，所以不用考慮多活架構(gòu)

但是隨著互聯(lián)網(wǎng)的普及和用戶的激增，為了應(yīng)對(duì)流量增量帶來的各種問題，我們的架構(gòu)體系衍生出很多強(qiáng)大的技術(shù)方案。

2 什么是秒殺/競(jìng)拍業(yè)務(wù)

秒殺業(yè)務(wù)也是隨著互聯(lián)網(wǎng)電商的發(fā)展而不斷普及的，我們來看看普通業(yè)務(wù)和秒殺業(yè)務(wù)的區(qū)別

2.1 普通的業(yè)務(wù)

微信的個(gè)人信息：個(gè)人的注冊(cè)信息，公眾號(hào)、視頻號(hào)的基礎(chǔ)信息，微信好友列表，微信群列表。這種是 1：1 的，一般也不會(huì)被別人看到。
微信朋友圈：你盆友圈公開的內(nèi)容是可以被多個(gè)好友看到的，你也可以對(duì)應(yīng)看到你多個(gè)好友的盆友圈。這種是 1：n 的，多讀的一種場(chǎng)景。

2.2 秒殺/競(jìng)拍業(yè)務(wù)

只有少量的數(shù)據(jù)，卻會(huì)在集中的時(shí)間段被一批人看到和搶購(gòu)，集中式的高頻讀寫。
業(yè)內(nèi)也稱為 群蜂請(qǐng)求 ，你可以想象下你捅了馬蜂窩的場(chǎng)景。哈哈哈

典型秒殺/競(jìng)拍業(yè)務(wù)案例：

春運(yùn)前的火車票開售那一刻，可能瞬間有千萬級(jí)請(qǐng)求涌入
將來某個(gè)遙遙領(lǐng)先開售，可能是一秒售罄

這些業(yè)務(wù)場(chǎng)景有如下技術(shù)難點(diǎn)：

瞬時(shí)流量特別大，你的接入層、應(yīng)用層、數(shù)據(jù)層等能否扛得住
大量流量涌入對(duì)一個(gè)數(shù)據(jù)進(jìn)行操作，怎么保證數(shù)據(jù)原子增減、順序公平性，怎么保證數(shù)據(jù)不超賣
如何保證數(shù)據(jù)安全，如防攻擊、防刷數(shù)、保持冪等
如果使用并發(fā)控制，如何保證不產(chǎn)生死鎖

所以，一個(gè)優(yōu)秀的秒殺業(yè)務(wù)架構(gòu)，在現(xiàn)在的互聯(lián)網(wǎng)業(yè)務(wù)中，是一個(gè)永不過時(shí)的話題

3 如何優(yōu)化

這邊只針對(duì)幾個(gè)對(duì)秒殺業(yè)務(wù)有效改進(jìn)的點(diǎn)做展開，什么集群動(dòng)態(tài)擴(kuò)容、流量控制、彈性伸縮、智能限流啊，可以參考我的這篇文章《千萬級(jí)流量沖擊下，如何保證極致性能》。

3.1 清除無效請(qǐng)求

盡量在前面就把一些無效請(qǐng)求給清理掉，所以這些操作Web前端或者 App Client端做就行了，越前端越好，盡量不要傷害到服務(wù)端，比如：

未登錄攔截
重復(fù)提交攔截（未響應(yīng)則按鈕置灰，直至響應(yīng)或者5S超時(shí)才恢復(fù)，冪等保證）
頻繁提交攔截（單用戶一分鐘不超過100次，避免AI刷機(jī)）
驗(yàn)證碼攔截（避免AI刷數(shù)據(jù)、黑客攻擊等）
參與條件攔截（可提前加載名單）：如用戶等級(jí)不夠、注冊(cè)未滿3個(gè)月、用戶進(jìn)入黑名單等

3.2 服務(wù)端+緩存層做高效原子操作

公共數(shù)據(jù)做緩存
緩存是提升系統(tǒng)性能的重要手段。通過緩存熱點(diǎn)數(shù)據(jù)，緩存還可以提高數(shù)據(jù)的訪問速度，見很少對(duì)數(shù)據(jù)庫(kù)的訪問速度，提升用戶體驗(yàn)。Redis單機(jī)每秒10w沒什么問題，再加上多集群多副本模式。

原子操作保證秒殺的計(jì)數(shù)
在Redis中，高效地進(jìn)行原子計(jì)數(shù)通常使用INCR、INCRBY、DECR、DECRBY等命令。這些命令都是原子操作，意味著在執(zhí)行時(shí)不會(huì)被其他Redis命令打斷，從而保證了計(jì)數(shù)的準(zhǔn)確性和一致性。

# 計(jì)算已售賣1000臺(tái)庫(kù)里南
> INCRBY cullinan_counter 1000


# 獲取當(dāng)前售賣數(shù)量
> GET cullinan_counter
> 1000


# 超過1000，返回秒殺失敗

隊(duì)列保證請(qǐng)求有序進(jìn)入
使用Redis的 Stream 隊(duì)列功能。Stream 實(shí)際上是一個(gè) key，你可以使用 XADD 命令向其中添加消息。

XADD mystream * field1 value1 field2 value2

這里 mystream 是 Stream 的名稱，* 表示讓 Redis 自動(dòng)生成一個(gè)唯一的消息 ID。field1 value1 和 field2 value2 是消息的內(nèi)容，你可以根據(jù)需要添加任意數(shù)量的字段。
如果你只有1000臺(tái)庫(kù)里南供搶購(gòu)，那么第1001就不要進(jìn)入隊(duì)列了。

擴(kuò)展閱讀
緩存可以擴(kuò)展閱讀作者的這個(gè)系列的文章：★ Redis24篇集合

3.3 數(shù)據(jù)層做終兜底

經(jīng)過上面的保證之后，到數(shù)據(jù)層的量就很少了，大概率就是你定額的商品數(shù)量同等的數(shù)量。
比如1000，數(shù)據(jù)庫(kù)絕對(duì)的扛得住的。
唯一可以做的就是檢查數(shù)量是否符合預(yù)期，這個(gè)可以創(chuàng)建約束或者觸發(fā)器來實(shí)現(xiàn)。