1 互聯網架構越來越復雜？

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

• 流量少，無需考慮并發(fā)問題

• 數據少，不用考慮什么索引優(yōu)化、分庫分表

• 訪問不集中，不用考慮緩存、過載保護

• 如果數據不重要，不用考慮安全策略，甚至不用考慮容災備份

• 可重復提交，所以不用關系冪等性

• 允許短暫宕機和定期關停維護，所以不用考慮多活架構

但是隨著互聯網的普及和用戶的激增，為了應對流量增量帶來的各種問題，我們的架構體系衍生出很多強大的技術方案。

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

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

2.1 普通的業(yè)務

1. 微信的個人信息：個人的注冊信息，公眾號、視頻號的基礎信息，微信好友列表，微信群列表。這種是 1：1 的，一般也不會被別人看到。

2. 微信朋友圈：你盆友圈公開的內容是可以被多個好友看到的，你也可以對應看到你多個好友的盆友圈。這種是 1：n 的，多讀的一種場景。

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

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

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

1. 春運前的火車票開售那一刻，可能瞬間有千萬級請求涌入

2. 將來某個遙遙領先開售，可能是一秒售罄

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

1. 瞬時流量特別大，你的接入層、應用層、數據層等能否扛得住

2. 大量流量涌入 對一個數據進行操作，怎么保證數據原子增減、順序公平性，怎么保證數據不超賣

3. 如何 保證數據安全，如防攻擊、防刷數、保持冪等

4. 如果使用 并發(fā)控制，如何保證不產生死鎖

所以，一個優(yōu)秀的秒殺業(yè)務架構，在現在的互聯網業(yè)務中，是一個永不過時的話題

3 如何優(yōu)化

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

3.1 清除無效請求

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

• 未登錄攔截

• 重復提交攔截（未響應則按鈕置灰，直至響應或者5S超時才恢復，冪等保證）

• 頻繁提交攔截（單用戶一分鐘不超過100次，避免AI刷機）

• 驗證碼攔截（避免AI刷數據、黑客攻擊等）

• 參與條件攔截（可提前加載名單）：如用戶等級不夠、注冊未滿3個月、用戶進入黑名單等

3.2 服務端+緩存層做高效原子操作

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

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

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


# 獲取當前售賣數量
> GET cullinan_counter
> 1000


# 超過1000，返回秒殺失敗

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

XADD mystream * field1 value1 field2 value2

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

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

3.3 數據層做終兜底

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

3.4 全球式業(yè)務，單元化處理

有些人可能會說，我的商品全球售賣，那我的緩存中心、數據中心放哪里，如果放中國，那跨地域跨機房訪問，在0.1微妙都能決定我是不是買得到，歐洲的客戶鐵定搶不到庫里南了。
現在的做法一般是單元化隔離，比如：

A/B中心都有這樣的緩存或者數據結構，配置中心統(tǒng)一下發(fā)配置。然后在各自的單元里面玩耍，互不干預。 秒殺業(yè)務千萬不要想著跨地域+跨機房，用戶存在不公平性。

4 寫在最后

1. 無效請求攔截，盡量在前端完成，避免走入后端，造成服務端壓力

2. 緩存支持高性能檢索、原子計算和有序隊列

3. 數據層做存儲兜底

4. 分治原理：單元化隔離，避免集中處理