業(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ù)庫(kù)

「查詢紅包記錄」

查詢 DB 即可

數(shù)據(jù)庫(kù)設(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層，就簡(jiǎn)單的一條sql語(yǔ)句，主要是提供思路，下面會(huì)附案例源碼，不要慌

?

搶紅包 API

搶紅包功能屬于原子減操作

當(dāng)大小小于 0 時(shí)原子減失敗

當(dāng)紅包個(gè)數(shù)為0時(shí)，后面進(jìn)來(lái)的用戶全部搶紅包失敗，并不會(huì)進(jìn)入拆紅包環(huán)節(jié)

搶紅包功能設(shè)計(jì)

將紅包ID的請(qǐng)求放入請(qǐng)求隊(duì)列中，如果發(fā)現(xiàn)超過(guò)紅包的個(gè)數(shù)，直接返回

注意事項(xiàng)

搶到紅包不一定能拆成功

搶紅包算法拆解

img

通過(guò)上圖算法得出，靠前面的人，手氣最佳幾率小，手氣最佳，往往在后面

發(fā) 100 元，共 10 個(gè)紅包，那么平均值是 10 元一個(gè)，那么發(fā)出來(lái)的紅包金額在 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。

布隆過(guò)濾器

介紹

布隆過(guò)濾器是1970年由布隆提出的。它實(shí)際上是一個(gè)很長(zhǎng)的二進(jìn)制向量和一系列隨機(jī)映射函數(shù)。布隆過(guò)濾器可以用于檢索一個(gè)元素是否在一個(gè)集合中。它的優(yōu)點(diǎn)是空間效率和查詢時(shí)間都遠(yuǎn)遠(yuǎn)超過(guò)一般的算法，缺點(diǎn)是有一定的誤識(shí)別率和刪除困難。

優(yōu)點(diǎn)

相比于其他的數(shù)據(jù)結(jié)構(gòu)，布隆過(guò)濾器在空間和時(shí)間方面都有巨大的優(yōu)勢(shì)。布隆過(guò)濾器存儲(chǔ)空間和插入/查詢時(shí)間都是常數(shù)。另外三列函數(shù)相互之間沒(méi)有關(guān)系，方便由硬件并行實(shí)現(xiàn)。布隆過(guò)濾器不需要存儲(chǔ)元素本身，在某些對(duì)保密要求非常嚴(yán)格的場(chǎng)合有優(yōu)勢(shì)。

缺點(diǎn)

但是布隆過(guò)濾器的缺點(diǎn)和有點(diǎn)一樣明顯。誤算率是其中之一。隨著存入的元素?cái)?shù)量增加，誤算率隨之增加。但是如果元素?cái)?shù)量太少，則使用散列表足矣。

布隆過(guò)濾器有什么用

黑客流量攻擊：故意訪問(wèn)不存在的數(shù)據(jù)，導(dǎo)致查程序不斷訪問(wèn)DB的數(shù)據(jù)

黑客安全阻截：當(dāng)黑客訪問(wèn)不存在的緩存時(shí)迅速返回避免緩存及DB掛掉

網(wǎng)頁(yè)爬蟲對(duì) URL 的去重，避免爬取相同的URL地址

反垃圾郵件，從數(shù)十億個(gè)垃圾郵件列表中判斷某郵件是否垃圾郵件(同理，垃圾短信)

緩存擊穿，將已存在的緩存放到布隆中，當(dāng)黑客訪問(wèn)不存在的緩存時(shí)迅速返回避免緩存及 DB 掛掉

布隆過(guò)濾器實(shí)現(xiàn)會(huì)員轉(zhuǎn)盤抽獎(jiǎng)

需求

一個(gè)抽獎(jiǎng)程序，只針對(duì)會(huì)員用戶有效

通過(guò)google布隆過(guò)濾器存儲(chǔ)會(huì)員數(shù)據(jù)

程序啟動(dòng)時(shí)將數(shù)據(jù)放入內(nèi)存中

google自動(dòng)創(chuàng)建布隆過(guò)濾器

用戶ID進(jìn)來(lái)之后判斷是否是會(huì)員

代碼實(shí)現(xiàn)

引入依賴

com.google.guava guava 29.0-jre

數(shù)據(jù)庫(kù)會(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;

初始化布隆過(guò)濾器

dao 層和 dao 映射文件，就單純的一個(gè) sql 查詢，看核心方法，下面會(huì)附源碼滴，不要慌好嘛

控制層

測(cè)試

缺點(diǎn)

內(nèi)存級(jí)別產(chǎn)部

重啟即失效

本地內(nèi)存無(wú)法用在分布式場(chǎng)景

不支持大數(shù)據(jù)量存儲(chǔ)

Redis布隆過(guò)濾器

優(yōu)點(diǎn)

可擴(kuò)展性 Bloom 過(guò)濾器

不存在重啟即失效或定時(shí)任務(wù)維護(hù)的成本

缺點(diǎn)

需要網(wǎng)絡(luò)IO，性能比基于內(nèi)存的過(guò)濾器低

布隆過(guò)濾器安裝

「下載」

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è)試布隆過(guò)濾器」

SpringBoot 整合 Redis 布隆過(guò)濾器

編寫兩個(gè)lua腳本

添加數(shù)據(jù)到指定名稱的布隆過(guò)濾器

從指定名稱的布隆過(guò)濾器獲取key是否存在的腳本

localbloomName=KEYS[1] localvalue=KEYS[2] --bloomFilter localresult_1=redis.call('BF.ADD',bloomName,value) returnresult_1

localbloomName=KEYS[1] localvalue=KEYS[2] --bloomFilter localresult_1=redis.call('BF.EXISTS',bloomName,value) returnresult_1

在 RedisService.java 中添加 2 個(gè)方法

驗(yàn)證

秒殺

秒殺業(yè)務(wù)流程圖

數(shù)據(jù)落地存儲(chǔ)方案

通過(guò)分布式redis減庫(kù)存

DB存最終訂單信息數(shù)據(jù)

API性能調(diào)優(yōu)

性能瓶頸在高并發(fā)秒殺

技術(shù)難題在于超賣問(wèn)題

實(shí)現(xiàn)步驟

提前將秒殺數(shù)據(jù)緩存到 redis

setskuId_start_10_1554045087--秒殺標(biāo)識(shí) setskuId_access_112000--允許搶購(gòu)數(shù) setskuId_count_10--搶購(gòu)計(jì)數(shù) setskuId_booked_10--真實(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(為啥接受搶購(gòu)數(shù)為1萬(wàn)2呢，看業(yè)務(wù)流程圖，涉及到“校驗(yàn)訂單信息”，一般設(shè)置的值要比總數(shù)多一點(diǎn)，多多少自己定)

利用 Redis 緩存加速增庫(kù)存數(shù)

"skuId_booked":10000//從0開始累加，秒殺的個(gè)數(shù)只能加到1萬(wàn)

將用戶訂單數(shù)據(jù)寫入 MQ(異步方式)。

另外一臺(tái)服務(wù)器監(jiān)聽(tīng) mq，將訂單信息寫入到 DB。

好了，以上就是完整的開發(fā)步驟，下面我們開始編寫代碼

代碼實(shí)戰(zhàn)

網(wǎng)關(guān)瀏覽攔截層

1、先判斷秒殺是否已經(jīng)開始

2、利用 Redis 緩存 incr 攔截流量

用 incr 方法原子加

通過(guò)原子加帕努單當(dāng)前 skuId_access 是否達(dá)到最大值

訂單信息校驗(yàn)層

1、校驗(yàn)當(dāng)前用戶是否已經(jīng)買過(guò)這個(gè)商品

需要存儲(chǔ)用戶的uid

存數(shù)據(jù)庫(kù)效率太低

存Redis value方式數(shù)據(jù)太大

存布隆過(guò)濾器性能高且數(shù)據(jù)量小(推薦)

2、校驗(yàn)通過(guò)直接返回?fù)屬?gòu)成功

開發(fā)lua腳本實(shí)現(xiàn)庫(kù)存扣除

1、庫(kù)存扣除成功，獲取當(dāng)前最新庫(kù)存

2、如果庫(kù)存大于0，即馬上進(jìn)行庫(kù)存扣除，并且訪問(wèn)搶購(gòu)成功給用戶

3、考慮原子性問(wèn)題

保證原子性的方式，采用 lua 腳本

采用lua腳本方式保證原子性帶來(lái)缺點(diǎn)，性能有所下降

不保證原子性缺點(diǎn)，放入請(qǐng)求量可能大于預(yù)期

當(dāng)前扣除庫(kù)存場(chǎng)景必須保證原子性，否則會(huì)導(dǎo)致超賣

4、返回?fù)屬?gòu)結(jié)果

搶購(gòu)成功

庫(kù)存沒(méi)了，搶購(gòu)失敗

控制層

Service 層

布隆過(guò)濾器

初始化redis緩存

setskuId_start_10_1554045087--秒殺標(biāo)識(shí) setskuId_access_112000--允許搶購(gòu)數(shù) setskuId_count_10--搶購(gòu)計(jì)數(shù) setskuId_booked_10--真實(shí)秒殺數(shù)

秒殺驗(yàn)證

jmeter 配置

壓測(cè)秒殺驗(yàn)證原子性

項(xiàng)目下載

鏈接:https://pan.baidu.com/s/1hZUPRAljkqO05fYluqJBhQ密碼:1iwr

尾聲

演示的時(shí)候，我使用的 Redis 單機(jī)的，吞吐量不是很大，感興趣的，可以自己搭建個(gè) Redis 主從復(fù)制+哨兵+集群，然后再測(cè)試。

最近比較忙，沒(méi)時(shí)間完善微信搶紅包秒殺的原子性。下面那個(gè)完整案例搶庫(kù)存的，親自使用 Jmeter 壓測(cè)幾次，是原子性的，可以拿來(lái)借鑒，感興趣的同學(xué)，可以借鑒下面搶庫(kù)存的代碼，把微信搶紅包的功能在完善下，我就不修改啦。

原文標(biāo)題：Redis 秒殺實(shí)戰(zhàn)

文章出處：【微信公眾號(hào)：數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。