Redis 秒殺實(shí)戰(zhàn)
為啥寫這個(gè)微信搶紅包項(xiàng)目呢，公司 0202 年 08 月 22 日，公司周年慶，搶了100多紅包🧧，O(∩_∩)O哈哈~
業(yè)務(wù)流程分析
功能拆解
新建紅包
在 DB、Redis 分別新增一條記錄
搶紅包(并發(fā))
「使用技術(shù)」
Redis 中數(shù)據(jù)類型的 String 特性的原子遞減(DECR key)和減少指定值(DECRBY key decrement)
「業(yè)務(wù)」
- 請(qǐng)求 Redis ，當(dāng)剩余紅包個(gè)數(shù)大于 0，紅包個(gè)數(shù)原子遞減，隨機(jī)獲取紅包
- 計(jì)算金額，當(dāng)最后一個(gè)紅包時(shí)，最后一個(gè)紅包金額=總金額-總已搶紅包金額
- 更新數(shù)據(jù)庫
「查詢紅包記錄」
查詢 DB 即可
數(shù)據(jù)庫設(shè)計(jì)
紅包流水表
- 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位隨機(jī)數(shù)',
- `total_amount` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總⾦額，單位分',
- `total_packet` int(11) NOT NULL DEFAULT 0 COMMENT '紅包總個(gè)數(shù)',
- `remaining_amount` int(11) NOT NULL DEFAULT 0 COMMENT '剩余紅包⾦額，單位
- 分',
- `remaining_packet` int(11) NOT NULL DEFAULT 0 COMMENT '剩余紅包個(gè)數(shù)',
- `uid` int(20) NOT NULL DEFAULT 0 COMMENT '新建紅包⽤戶的⽤戶標(biāo)識(shí)',
- `create_time` timestamp COMMENT '創(chuàng)建時(shí)間',
- `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
- CURRENT_TIMESTAMP COMMENT '更新時(shí)間',
- PRIMARY KEY (`id`)
- ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='紅包信息
- 表，新建⼀個(gè)紅包插⼊⼀條記錄';
紅包記錄表
- 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 '搶到紅包⽤戶的⽤戶標(biāo)識(shí)',
- `red_packet_id` bigint(11) NOT NULL DEFAULT '0' COMMENT '紅包id，采⽤
- timestamp+5位隨機(jī)數(shù)',
- `create_time` timestamp COMMENT '創(chuàng)建時(shí)間',
- `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
- CURRENT_TIMESTAMP COMMENT '更新時(shí)間',
- PRIMARY KEY (`id`)
- ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='搶紅包記
- 錄表，搶⼀個(gè)紅包插⼊⼀條記錄';
發(fā)紅包 API
發(fā)紅包接口開發(fā)
- 新增一條紅包記錄
- 往 mysql 里面添加一條紅包記錄
- 往 redis 里面添加一條紅包數(shù)量記錄
- 往redis里面添加一條紅包金額記錄
❝往db中就單純存入一條記錄，Service層和Mapper層，就簡單的一條sql語句，主要是提供思路，下面會(huì)附案例源碼，不要慌❞
搶紅包 API
- 搶紅包功能屬于原子減操作
- 當(dāng)大小小于 0 時(shí)原子減失敗
- 當(dāng)紅包個(gè)數(shù)為0時(shí)，后面進(jìn)來的用戶全部搶紅包失敗，并不會(huì)進(jìn)入拆紅包環(huán)節(jié)
- 搶紅包功能設(shè)計(jì)
- 將紅包ID的請(qǐng)求放入請(qǐng)求隊(duì)列中，如果發(fā)現(xiàn)超過紅包的個(gè)數(shù)，直接返回
- 注意事項(xiàng)
- 搶到紅包不一定能拆成功
搶紅包算法拆解
img
通過上圖算法得出，靠前面的人，手氣最佳幾率小，手氣最佳，往往在后面
- 發(fā) 100 元，共 10 個(gè)紅包，那么平均值是 10 元一個(gè)，那么發(fā)出來的紅包金額在 0.01~20 元之間波動(dòng)
- 當(dāng)前面 4 個(gè)紅包總共被領(lǐng)了 30 元時(shí)，剩下 70 元，總共 6 個(gè)紅包，那么這 6 個(gè)紅包的金額在 0.01~23.3 元之間波動(dòng)
搶紅包接口開發(fā)
「測(cè)試」
「發(fā)紅包」
模擬高并發(fā)搶紅包(Jmeter壓測(cè)工具)
因?yàn)槲野l(fā)了 10 個(gè)紅包，金額是 20000，使用壓測(cè)工具，模擬50個(gè)請(qǐng)求，只允許前10個(gè)請(qǐng)求能搶到紅包，并且金額等于20000。
布隆過濾器
介紹
布隆過濾器是1970年由布隆提出的。它實(shí)際上是一個(gè)很長的二進(jìn)制向量和一系列隨機(jī)映射函數(shù)。布隆過濾器可以用于檢索一個(gè)元素是否在一個(gè)集合中。它的優(yōu)點(diǎn)是空間效率和查詢時(shí)間都遠(yuǎn)遠(yuǎn)超過一般的算法，缺點(diǎn)是有一定的誤識(shí)別率和刪除困難。
優(yōu)點(diǎn)
相比于其他的數(shù)據(jù)結(jié)構(gòu)，布隆過濾器在空間和時(shí)間方面都有巨大的優(yōu)勢(shì)。布隆過濾器存儲(chǔ)空間和插入/查詢時(shí)間都是常數(shù)。另外三列函數(shù)相互之間沒有關(guān)系，方便由硬件并行實(shí)現(xiàn)。布隆過濾器不需要存儲(chǔ)元素本身，在某些對(duì)保密要求非常嚴(yán)格的場(chǎng)合有優(yōu)勢(shì)。
缺點(diǎn)
但是布隆過濾器的缺點(diǎn)和有點(diǎn)一樣明顯。誤算率是其中之一。隨著存入的元素?cái)?shù)量增加，誤算率隨之增加。但是如果元素?cái)?shù)量太少，則使用散列表足矣。
布隆過濾器有什么用
- 黑客流量攻擊：故意訪問不存在的數(shù)據(jù)，導(dǎo)致查程序不斷訪問DB的數(shù)據(jù)
- 黑客安全阻截：當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及DB掛掉
- 網(wǎng)頁爬蟲對(duì) URL 的去重，避免爬取相同的URL地址
- 反垃圾郵件，從數(shù)十億個(gè)垃圾郵件列表中判斷某郵件是否垃圾郵件(同理，垃圾短信)
- 緩存擊穿，將已存在的緩存放到布隆中，當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及 DB 掛掉
布隆過濾器實(shí)現(xiàn)會(huì)員轉(zhuǎn)盤抽獎(jiǎng)
需求
一個(gè)抽獎(jiǎng)程序，只針對(duì)會(huì)員用戶有效
通過google布隆過濾器存儲(chǔ)會(huì)員數(shù)據(jù)
- 程序啟動(dòng)時(shí)將數(shù)據(jù)放入內(nèi)存中
- google自動(dòng)創(chuàng)建布隆過濾器
- 用戶ID進(jìn)來之后判斷是否是會(huì)員
代碼實(shí)現(xiàn)
引入依賴
- <dependency>
- <groupId>com.google.guava</groupId>
- <artifactId>guava</artifactId>
- <version>29.0-jre</version>
- </dependency>
數(shù)據(jù)庫會(huì)員表
- 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 映射文件，就單純的一個(gè) sql 查詢，看核心方法，下面會(huì)附源碼滴，不要慌好嘛
控制層
測(cè)試
缺點(diǎn)
- 內(nèi)存級(jí)別產(chǎn)部
- 重啟即失效
- 本地內(nèi)存無法用在分布式場(chǎng)景
- 不支持大數(shù)據(jù)量存儲(chǔ)
Redis布隆過濾器
優(yōu)點(diǎn)
- 可擴(kuò)展性 Bloom 過濾器
- 不存在重啟即失效或定時(shí)任務(wù)維護(hù)的成本
缺點(diǎn)
需要網(wǎng)絡(luò)IO，性能比基于內(nèi)存的過濾器低
布隆過濾器安裝
「下載」
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
「測(cè)試布隆過濾器」
SpringBoot 整合 Redis 布隆過濾器
編寫兩個(gè)lua腳本
- 添加數(shù)據(jù)到指定名稱的布隆過濾器
- 從指定名稱的布隆過濾器獲取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 個(gè)方法
驗(yàn)證
秒殺
秒殺業(yè)務(wù)流程圖
數(shù)據(jù)落地存儲(chǔ)方案
- 通過分布式redis減庫存
- DB存最終訂單信息數(shù)據(jù)
API性能調(diào)優(yōu)
- 性能瓶頸在高并發(fā)秒殺
- 技術(shù)難題在于超賣問題
實(shí)現(xiàn)步驟
提前將秒殺數(shù)據(jù)緩存到 redis
- set skuId_start_1 0_1554045087 --秒殺標(biāo)識(shí)
- set skuId_access_1 12000 --允許搶購數(shù)
- set skuId_count_1 0 --搶購計(jì)數(shù)
- set skuId_booked_1 0 --真實(shí)秒殺數(shù)
- 秒殺開始前，skuId_start為0，代表活動(dòng)未開始
- 當(dāng)skuId_start改為1時(shí)，活動(dòng)開始，開始秒殺叭
- 當(dāng)接受下單數(shù)達(dá)到sku_count*1.2后，繼續(xù)攔截所有請(qǐng)求，商品剩余數(shù)量為0(為啥接受搶購數(shù)為1萬2呢，看業(yè)務(wù)流程圖，涉及到“校驗(yàn)訂單信息”，一般設(shè)置的值要比總數(shù)多一點(diǎn)，多多少自己定)
利用 Redis 緩存加速增庫存數(shù)
- "skuId_booked":10000 //從0開始累加，秒殺的個(gè)數(shù)只能加到1萬
將用戶訂單數(shù)據(jù)寫入 MQ(異步方式)。
另外一臺(tái)服務(wù)器監(jiān)聽 mq，將訂單信息寫入到 DB。
好了，以上就是完整的開發(fā)步驟，下面我們開始編寫代碼
代碼實(shí)戰(zhàn)
網(wǎng)關(guān)瀏覽攔截層
1、先判斷秒殺是否已經(jīng)開始
2、利用 Redis 緩存 incr 攔截流量
- 用 incr 方法原子加
- 通過原子加帕努單當(dāng)前 skuId_access 是否達(dá)到最大值
訂單信息校驗(yàn)層
1、校驗(yàn)當(dāng)前用戶是否已經(jīng)買過這個(gè)商品
- 需要存儲(chǔ)用戶的uid
- 存數(shù)據(jù)庫效率太低
- 存Redis value方式數(shù)據(jù)太大
- 存布隆過濾器性能高且數(shù)據(jù)量小(推薦)
2、校驗(yàn)通過直接返回?fù)屬彸晒?/p>
開發(fā)lua腳本實(shí)現(xiàn)庫存扣除
1、庫存扣除成功，獲取當(dāng)前最新庫存
2、如果庫存大于0，即馬上進(jìn)行庫存扣除，并且訪問搶購成功給用戶
3、考慮原子性問題
- 保證原子性的方式，采用 lua 腳本
- 采用lua腳本方式保證原子性帶來缺點(diǎn)，性能有所下降
- 不保證原子性缺點(diǎn)，放入請(qǐng)求量可能大于預(yù)期
- 當(dāng)前扣除庫存場(chǎng)景必須保證原子性，否則會(huì)導(dǎo)致超賣
4、返回?fù)屬徑Y(jié)果
搶購成功
庫存沒了，搶購失敗
控制層
Service 層
布隆過濾器
初始化redis緩存
- set skuId_start_1 0_1554045087 --秒殺標(biāo)識(shí)
- set skuId_access_1 12000 --允許搶購數(shù)
- set skuId_count_1 0 --搶購計(jì)數(shù)
- set skuId_booked_1 0 --真實(shí)秒殺數(shù)
秒殺驗(yàn)證
jmeter 配置
壓測(cè)秒殺驗(yàn)證原子性
項(xiàng)目下載
- 鏈接: https://pan.baidu.com/s/1hZUPRAljkqO05fYluqJBhQ 密碼: 1iwr
尾聲
演示的時(shí)候，我使用的 Redis 單機(jī)的，吞吐量不是很大，感興趣的，可以自己搭建個(gè) Redis 主從復(fù)制+哨兵+集群，然后再測(cè)試。
最近比較忙，沒時(shí)間完善微信搶紅包秒殺的原子性。下面那個(gè)完整案例搶庫存的，親自使用 Jmeter 壓測(cè)幾次，是原子性的，可以拿來借鑒，感興趣的同學(xué)，可以借鑒下面搶庫存的代碼，把微信搶紅包的功能在完善下，我就不修改啦。
本文轉(zhuǎn)載自微信公眾號(hào)「Java建設(shè)者」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java建設(shè)者公眾號(hào)。
