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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 如何優(yōu)化

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

3.1 清除無效請求

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

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

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

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

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

# 計算已售賣1000臺庫里南
> INCRBY cullinan_counter 1000


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


# 超過1000，返回秒殺失敗

隊列保證請求有序進入
使用Redis的 Stream 隊列功能。Stream 實際上是一個 key，你可以使用 XADD 命令向其中添加消息。

XADD mystream * field1 value1 field2 value2

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

擴展閱讀
緩存可以擴展閱讀作者的這個系列的文章：★ Redis24篇集合

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

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