Redis 牛X！竟然能實(shí)現(xiàn)搶紅包功能！

原文鏈接：https://www.cnblogs.com/chenyanbin/p/13587508.html

為啥寫這個(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ù)」

1. 請(qǐng)求 Redis ，當(dāng)剩余紅包個(gè)數(shù)大于 0，紅包個(gè)數(shù)原子遞減，隨機(jī)獲取紅包
2. 計(jì)算金額，當(dāng)最后一個(gè)紅包時(shí)，最后一個(gè)紅包金額=總金額-總已搶紅包金額
3. 更新數(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)
• 搶到紅包不一定能拆成功

搶紅包算法拆解

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

1. 發(fā) 100 元，共 10 個(gè)紅包，那么平均值是 10 元一個(gè)，那么發(fā)出來的紅包金額在 0.01~20 元之間波動(dòng)
2. 當(dāng)前面 4 個(gè)紅包總共被領(lǐng)了 30 元時(shí)，剩下 70 元，總共 6 個(gè)紅包，那么這 6 個(gè)紅包的金額在 0.01~23.3 元之間波動(dòng)

搶紅包接口開發(fā)

「測試」

「發(fā)紅包」

模擬高并發(fā)搶紅包(Jmeter壓測工具)

因?yàn)槲野l(fā)了 10 個(gè)紅包，金額是 20000，使用壓測工具，模擬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)勢。布隆過濾器存儲(chǔ)空間和插入/查詢時(shí)間都是常數(shù)。另外三列函數(shù)相互之間沒有關(guān)系，方便由硬件并行實(shí)現(xiàn)。布隆過濾器不需要存儲(chǔ)元素本身，在某些對(duì)保密要求非常嚴(yán)格的場合有優(yōu)勢。

缺點(diǎn)

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

布隆過濾器有什么用

1. 黑客流量攻擊：故意訪問不存在的數(shù)據(jù)，導(dǎo)致查程序不斷訪問DB的數(shù)據(jù)
2. 黑客安全阻截：當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及DB掛掉
3. 網(wǎng)頁爬蟲對(duì) URL 的去重，避免爬取相同的URL地址
4. 反垃圾郵件，從數(shù)十億個(gè)垃圾郵件列表中判斷某郵件是否垃圾郵件(同理，垃圾短信)
5. 緩存擊穿，將已存在的緩存放到布隆中，當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及 DB 掛掉

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

需求

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

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

1. 程序啟動(dòng)時(shí)將數(shù)據(jù)放入內(nèi)存中
2. google自動(dòng)創(chuàng)建布隆過濾器
3. 用戶ID進(jìn)來之后判斷是否是會(huì)員

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

引入依賴

??com.google.guava
??guava
??29.0-jre

數(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ì)附源碼滴，不要慌好嘛

控制層

測試

缺點(diǎn)

1. 內(nèi)存級(jí)別產(chǎn)部
2. 重啟即失效
3. 本地內(nèi)存無法用在分布式場景
4. 不支持大數(shù)據(jù)量存儲(chǔ)

Redis布隆過濾器

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

1. 可擴(kuò)展性 Bloom 過濾器
2. 不存在重啟即失效或定時(shí)任務(wù)維護(hù)的成本

缺點(diǎn)

1. 需要網(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

「測試布隆過濾器」

SpringBoot 整合 Redis 布隆過濾器

編寫兩個(gè)lua腳本

1. 添加數(shù)據(jù)到指定名稱的布隆過濾器
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 個(gè)方法

驗(yàn)證

秒殺

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

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

1. 通過分布式redis減庫存
2. DB存最終訂單信息數(shù)據(jù)

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

1. 性能瓶頸在高并發(fā)秒殺
2. 技術(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ù)

1. 秒殺開始前，skuId_start為0，代表活動(dòng)未開始
2. 當(dāng)skuId_start改為1時(shí)，活動(dòng)開始，開始秒殺叭
3. 當(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)前扣除庫存場景必須保證原子性，否則會(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 配置

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

項(xiàng)目下載

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

尾聲

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

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

喜歡我可以給我設(shè)為星標(biāo)哦

好文章，我“在看”