Redis秒殺實戰-微信搶紅包-秒殺庫存，附案例原始碼（Jmeter壓測）

陳彥斌發表於2020-08-31
Redis原始碼JMeter

導讀

　　前二天我寫了一篇，Redis高階專案實戰(點我直達)，SpringBoot整合Redis附原始碼(點我直達)，今天我們來做一下Redis秒殺系統的設計。當然啦，Redis基礎知識還不過關的，先去加強下自身內功，然後在回來看這篇，Redis基礎知識(點我直達)。為啥寫這個微信搶紅包專案呢，公司0202年08月22日，公司週年慶，搶了100多紅包?，O(∩_∩)O哈哈~

微信搶紅包實現原理

業務流程分析 

功能拆解

新建紅包

　　在DB、Redis分別新增一條記錄

搶紅包(併發)

　　請求Redis，紅包剩餘個數，大於0才可以拆，等會0時，提示使用者，紅包已搶完

拆紅包(併發)

用到技術

　　Redis中資料型別的String特性的原子遞減（DECR key）和減少指定值（DECRBY key decrement）

業務

  1. 請求Redis，當剩餘紅包個數大於0，紅包個數原子遞減，隨機獲取紅包
  2. 計算金額，當最後一個紅包時，最後一個紅包金額=總金額-總已搶紅包金額
  3. 更新資料庫

檢視紅包記錄

　　查詢DB即可

資料庫表設計

紅包流水錶

CREATE TABLE `red_packet_info` (
 `id` int(11) NOT NULL AUTO_INCREMENT, 
 `red_packet_id` bigint(11) NOT NULL DEFAULT 0 COMMENT '紅包id，採⽤
timestamp+5位隨機數', 
 `total_amount` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總⾦額，單位分',
 `total_packet` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總個數',
 `remaining_amount` int(11) NOT NULL DEFAULT 0 COMMENT '剩餘紅包⾦額，單位
分',
 `remaining_packet` int(11) NOT NULL DEFAULT 0 COMMENT '剩餘紅包個數',
 `uid` int(20) NOT NULL DEFAULT 0 COMMENT '新建紅包⽤戶的⽤戶標識',
 `create_time` timestamp COMMENT '建立時間',
 `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP COMMENT '更新時間',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='紅包資訊
表，新建⼀個紅包插⼊⼀條記錄';

紅包記錄表

CREATE TABLE `red_packet_record` (
 `id` int(11) NOT NULL AUTO_INCREMENT, 
 `amount` int(11) NOT NULL DEFAULT '0' COMMENT '搶到紅包的⾦額',
 `nick_name` varchar(32) NOT NULL DEFAULT '0' COMMENT '搶到紅包的⽤戶的⽤戶
名',
 `img_url` varchar(255) NOT NULL DEFAULT '0' COMMENT '搶到紅包的⽤戶的頭像',
 `uid` int(20) NOT NULL DEFAULT '0' COMMENT '搶到紅包⽤戶的⽤戶標識',
 `red_packet_id` bigint(11) NOT NULL DEFAULT '0' COMMENT '紅包id，採⽤
timestamp+5位隨機數', 
 `create_time` timestamp COMMENT '建立時間',
 `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP COMMENT '更新時間',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='搶紅包記
錄表，搶⼀個紅包插⼊⼀條記錄';

發紅包API

發紅包介面開發

  • 新增一條紅包記錄
  • 往mysql裡面添加一條紅包記錄
  • 往redis裡面添加一條紅包數量記錄
  • 往redis裡面添加一條紅包金額記錄

　　注意，往db中就單純存入一條記錄，Service層和Mapper層，就簡單的一條sql語句，主要是提供思路，下面會附案例原始碼，不要慌

搶紅包API

  • 搶紅包功能屬於原子減操作
  • 當大小小於0時原子減失敗
  • 當紅包個數為0時，後面進來的使用者全部搶紅包失敗，並不會進入拆紅包環節
  • 搶紅包功能設計
    • 將紅包ID的請求放入請求佇列中，如果發現超過紅包的個數，直接返回
  • 注意事項
    • 搶到紅包不一定能拆成功

 搶紅包演算法拆解

　　通過上圖演算法得出，靠前面的人，手氣最佳機率小，手氣最佳，往往在後面

  1. 發100元，共10個紅包，那麼平均值是10元一個，那麼發出來的紅包金額在0.01~20元之間波動
  2. 當前面4個紅包總共被領了30元時，剩下70元，總共6個紅包，那麼這6個紅包的金額在0.01~23.3元之間波動

搶紅包介面開發

測試

發紅包

模擬高併發搶紅包(Jmeter壓測工具)

　　因為我發了10個紅包，金額是20000，使用壓測工具，模擬50個請求，只允許前10個請求能搶到紅包，並且金額等於20000。

布隆過濾器(重要)

介紹

　　布隆過濾器是1970年由布隆提出的。它實際上是一個很長的二進位制向量和一系列隨機對映函式。布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都遠遠超過一般的演算法，缺點是有一定的誤識別率和刪除困難。

優點

　　相比於其他的資料結構，布隆過濾器在空間和時間方面都有巨大的優勢。布隆過濾器儲存空間和插入/查詢時間都是常數。另外三列函式相互之間沒有關係，方便由硬體並行實現。布隆過濾器不需要儲存元素本身，在某些對保密要求非常嚴格的場合有優勢。

缺點

　　但是布隆過濾器的缺點和有點一樣明顯。誤算率是其中之一。隨著存入的元素數量增加，誤算率隨之增加。但是如果元素數量太少，則使用雜湊表足矣。

布隆過濾器有什麼用？

  1. 黑客流量攻擊：故意訪問不存在的資料，導致查程式不斷訪問DB的資料
  2. 黑客安全阻截：當黑客訪問不存在的快取時迅速返回避免快取及DB掛掉
  3. 網頁爬蟲對URL的去重，避免爬取相同的URL地址
  4. 反垃圾郵件，從數十億個垃圾郵件列表中判斷某郵件是否垃圾郵件(同理，垃圾簡訊)
  5. 快取擊穿，將已存在的快取放到布隆中，當黑客訪問不存在的快取時迅速返回避免快取及DB掛掉

布隆過濾器實現會員轉盤抽獎

需求

　　一個抽獎程式，只針對會員使用者有效

 

通過google布隆過濾器儲存會員資料

  1. 程式啟動時將資料放入記憶體中
  2. google自動建立布隆過濾器
  3. 使用者ID進來之後判斷是否是會員

程式碼實現

引入依賴

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>29.0-jre</version>
        </dependency>

資料庫會員表

CREATE TABLE `sys_user` (
 `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
 `user_name` varchar(11) CHARACTER SET utf8mb4 DEFAULT NULL COMMENT '⽤戶名',
 `image` varchar(11) CHARACTER SET utf8mb4 DEFAULT NULL COMMENT '⽤戶頭像',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;

初始化布隆過濾器

　　dao層和dao對映檔案，就單純的一個sql查詢，看核心方法，下面會附原始碼滴，不要慌好嘛

控制層

測試 

缺點

  1. 記憶體級別產部
  2. 重啟即失效
  3. 本地記憶體無法用在分散式場景
  4. 不支援大資料量儲存

Redis布隆過濾器

優點

  1. 可擴充套件性Bloom過濾器
  2. 不存在重啟即失效或定時任務維護的成本

缺點

  1. 需要網路IO，效能比基於記憶體的過濾器低

布隆過濾器安裝

下載

github：https://github.com/RedisBloom/RedisBloom

連結: https://pan.baidu.com/s/16DlKLm8WGFzGkoPpy8y4Aw  密碼: 25w1

編譯

make

將Rebloom載入到Redis中

　　先把Redis給停掉！！！在redis.conf裡面新增一行命令->載入模組

loadmodule /usr/soft/RedisBloom-2.2.4/redisbloom.so

測試布隆過濾器

SpringBoot整合Redis布隆過濾器(重點)

編寫兩個lua指令碼

  1. 新增資料到指定名稱的布隆過濾器
  2. 從指定名稱的布隆過濾器獲取key是否存在的指令碼

local bloomName = KEYS[1]
local value = KEYS[2]
--bloomFilter
local result_1 = redis.call('BF.ADD',bloomName,value)
return result_1

local bloomName = KEYS[1]
local value = KEYS[2]
--bloomFilter
local result_1 = redis.call('BF.EXISTS',bloomName,value)
return result_1

在RedisService.java中新增2個方法

驗證

秒殺系統設計

秒殺業務流程圖

資料落地儲存方案

  1. 通過分散式redis減庫存
  2. DB存最終訂單資訊資料

API效能調優

  1. 效能瓶頸在高併發秒殺
  2. 技術難題在於超賣問題

實現步驟

1、提前將秒殺資料快取到redis

set skuId_start_1 0_1554045087 --秒殺標識
set skuId_access_1 12000 --允許搶購數
set skuId_count_1 0 --搶購計數
set skuId_booked_1 0 --真實秒殺數
  1. 秒殺開始前，skuId_start為0，代表活動未開始
  2. 當skuId_start改為1時，活動開始，開始秒殺叭
  3. 當接受下單數達到sku_count*1.2後，繼續攔截所有請求，商品剩餘數量為0(為啥接受搶購數為1萬2呢，看業務流程圖，涉及到“校驗訂單資訊”，一般設定的值要比總數多一點，多多少自己定)

2、利用Redis快取加速增庫存數

"skuId_booked":10000 //從0開始累加，秒殺的個數只能加到1萬

3、將使用者訂單資料寫入MQ(非同步方式)，可以看我另外一篇部落格：點我直達

4、另外一臺伺服器監聽mq，將訂單資訊寫入到DB

好了，以上就是完整的開發步驟，下面我們開始編寫程式碼

程式碼實戰

閘道器瀏覽攔截層

1、先判斷秒殺是否已經開始

2、利用Redis快取incr攔截流量

  • 用incr方法原子加
  • 通過原子加帕努單當前skuId_access是否達到最大值

訂單資訊校驗層

1、校驗當前使用者是否已經買過這個商品

  • 需要儲存使用者的uid
  • 存資料庫效率太低
  • 存Redis value方式資料太大
  • 存布隆過濾器效能高且資料量小(推薦)

2、校驗通過直接返回搶購成功

開發lua指令碼實現庫存扣除

1、庫存扣除成功，獲取當前最新庫存

2、如果庫存大於0，即馬上進行庫存扣除，並且訪問搶購成功給使用者

3、考慮原子性問題

  • 保證原子性的方式，採用lua指令碼
  • 採用lua指令碼方式保證原子性帶來缺點，效能有所下降
  • 不保證原子性缺點，放入請求量可能大於預期
  • 當前扣除庫存場景必須保證原子性，否則會導致超賣

4、返回搶購結果

  • 搶購成功
  • 庫存沒了，搶購失敗

控制層

 

Service層

布隆過濾器

初始化redis快取

set skuId_start_1 0_1554045087 --秒殺標識
set skuId_access_1 12000 --允許搶購數
set skuId_count_1 0 --搶購計數
set skuId_booked_1 0 --真實秒殺數

秒殺驗證

jmeter配置

壓測秒殺驗證原子性

專案下載

連結: https://pan.baidu.com/s/1hZUPRAljkqO05fYluqJBhQ  密碼: 1iwr

尾聲

　　演示的時候，我使用的Redis單機的，吞吐量不是很大，感興趣的，可以自己搭建個Redis主從複製+哨兵+叢集，然後再測試。

　　最近比較忙，沒時間完善微信搶紅包秒殺的原子性。下面那個完整案例搶庫存的，親自使用Jmeter壓測幾次，是原子性的，可以拿來借鑑，感興趣的同學，可以借鑑下面搶庫存的程式碼，把微信搶紅包的功能在完善下，我就不修改啦，今天先到這，有不懂的歡迎下面留言。

相關文章