Redis實(shí)現(xiàn)商品秒殺功能頁面流程
全局唯一ID
業(yè)務(wù)邏輯分析
全局唯一ID是針對(duì)銷量比較大的一些商品而言的,這類商品的成交量比較多,用戶購買成功就會(huì)生成對(duì)應(yīng)訂單信息并保存到一張表中,而訂單表的id如果使用數(shù)據(jù)庫自增ID就存在一些問題,比如說id的規(guī)律性太強(qiáng)導(dǎo)致安全性極低,還有如果訂單數(shù)量太多一張表存不下分成多張表存儲(chǔ)的話就會(huì)出現(xiàn)ID沖突問題,于是我們需要一個(gè)全局ID生成器,保證ID在全局中都是唯一的
使用Redis即可完成這種全局ID生成器的功能,具體實(shí)現(xiàn)就是一種類雪花算法,也就是符號(hào)位、時(shí)間戳、序列號(hào)三部分拼接形成一個(gè)ID,邏輯就是符號(hào)位0代表整數(shù),時(shí)間戳確定具體到下訂單的時(shí)候是哪一秒,至于序列號(hào)就是用于區(qū)分這一秒的訂單,序列號(hào)使用redis的值自增來保證所有序列號(hào)不一致,原則上一秒中最多可以有232個(gè)不同的ID

代碼實(shí)現(xiàn)
@Component
public class RedisIdGenerator {
/**
* 構(gòu)造方法注入stringRedisTemplate對(duì)象
*/
private StringRedisTemplate stringRedisTemplate;
public RedisIdGenerator(StringRedisTemplate stringRedisTemplate) {
this.stringRedisTemplate = stringRedisTemplate;
}
// 定義序列號(hào)的位數(shù)
private static final int COUNT_BITS = 30;
public long nextId(String keyPrefix) {
// 生成從指定時(shí)間到現(xiàn)在的時(shí)間戳
LocalDateTime beginTime = LocalDateTime.of(2022, 1, 1, 0, 0, 0);
long beginTimeStamp = beginTime.toEpochSecond(ZoneOffset.UTC);
long endTimeStamp = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);
long timeStamp = endTimeStamp - beginTimeStamp;
/**
* 生成序列號(hào) 使用redis的incr方法 K值為"icr:" + keyPrefix + ":" + date
* 也就是按照日期作為K 每下一次單V就自增1作為序列號(hào)添加到后面
* 這樣的話既避免了K固定帶來的V超過最大閾值(redis中的V最大為2^64)
* 而且還方便了統(tǒng)計(jì)一天、一個(gè)月、一年的訂單量,在這段時(shí)間內(nèi)最大的序列號(hào)就是它的最多訂單數(shù)
*/
String date = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
Long sequenceId = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);
// 拼接生成全局唯一ID并返回 兩個(gè)二進(jìn)制的拼接可以使用前一個(gè)數(shù)左移一定位數(shù) 后一個(gè)數(shù)與位移后的進(jìn)行或運(yùn)算
return timeStamp << COUNT_BITS | sequenceId;
}
}優(yōu)惠券秒殺
業(yè)務(wù)邏輯分析
用戶對(duì)秒殺商品下單的時(shí)候,后臺(tái)業(yè)務(wù)需要先完成對(duì)商品時(shí)間的判斷,判斷該商品的秒殺活動(dòng)是否開始或者有沒有結(jié)束,但凡還未開始或者已經(jīng)結(jié)束都無法下單;時(shí)間信息正確的話就判斷該商品的活動(dòng)庫存還有沒有剩余,如果已經(jīng)賣完的話也無法下單。時(shí)間和庫存的判斷都是通過前端傳過來的優(yōu)惠券id,查出來該優(yōu)惠券的時(shí)間和庫存信息,如果條件都滿足的話,將該商品券的庫存扣除,然后創(chuàng)建訂單返回訂單id
代碼實(shí)現(xiàn)
controller層主要就是調(diào)用service接口里的secKillVoucher方法,所以整個(gè)業(yè)務(wù)邏輯代碼全部都在接口的實(shí)現(xiàn)類中完成
@Resource
private ISeckillVoucherService seckillVoucherService;
@Resource
private RedisIdGenerator generator;
@Override
@Transactional
public Result secKillVoucher(Long voucherId) {
// 查詢優(yōu)惠券
SeckillVoucher seckillVoucher = seckillVoucherService.getById(voucherId);
// 獲取時(shí)間 判斷秒殺活動(dòng)是否開始或者結(jié)束
if (seckillVoucher.getBeginTime().isAfter(LocalDateTime.now())) {
return Result.fail("活動(dòng)暫未開始");
} else if (seckillVoucher.getEndTime().isBefore(LocalDateTime.now())) {
return Result.fail("活動(dòng)已經(jīng)結(jié)束");
}
// 判斷庫存是否充足
if (seckillVoucher.getStock() < 1) {
return Result.fail("庫存不足,活動(dòng)結(jié)束");
}
// 扣減庫存
seckillVoucherService.update()
.setSql("stock = stock - 1")
.eq("voucher_id", voucherId).update();
// 創(chuàng)建訂單 并返回id
VoucherOrder order = new VoucherOrder();
// 訂單id(redis全局唯一id) 下單用戶id(攔截器中做登錄驗(yàn)證的用戶id) 優(yōu)惠券id(直接傳過來的id)
long orderId = generator.nextId("order");
order.setId(orderId);
order.setUserId(UserHolder.getUser().getId());
order.setVoucherId(voucherId);
save(order);
return Result.ok(orderId);
}
定量商品多賣問題
業(yè)務(wù)邏輯分析
像上面的優(yōu)惠券秒殺的業(yè)務(wù),優(yōu)惠券或者商品的數(shù)量一般都是固定的,如果把這些數(shù)量都賣完之后應(yīng)該就結(jié)束這個(gè)活動(dòng)。但是現(xiàn)實(shí)中的秒殺業(yè)務(wù)都是多線程的,很多的用戶同時(shí)等著活動(dòng)開啟一起點(diǎn)擊下單,這樣的話就極有可能出現(xiàn)線程安全問題也就是說最終成交的數(shù)量要多于活動(dòng)商品的數(shù)量
上述問題出現(xiàn)的原因就是多線程之間的執(zhí)行順序所引起,我們的秒殺業(yè)務(wù)里面是先查詢庫存數(shù)量大于1就產(chǎn)生訂單,但是多線程之間的執(zhí)行不會(huì)嚴(yán)格的按照這個(gè)順序執(zhí)行,而是交叉執(zhí)行,如果最后只剩一張票的時(shí)候進(jìn)來了兩個(gè)線程AB,A查完B查AB查詢結(jié)果都可以下單,A產(chǎn)生訂單B再產(chǎn)生訂單,此時(shí)就已經(jīng)產(chǎn)生超賣
樂觀鎖與悲觀鎖
解決線程問題的最好方法就是加鎖,但是鎖也分為悲觀鎖和樂觀鎖,悲觀鎖認(rèn)為線程安全問題一定會(huì)發(fā)生,因此在操作數(shù)據(jù)之前先獲取鎖,確保線程串行執(zhí)行,例如Synchronized、Lock等。樂觀鎖認(rèn)為線程安全問題不一定會(huì)發(fā)生,因此不加鎖,只是在更新數(shù)據(jù)時(shí)去判斷有沒有其它線程對(duì)數(shù)據(jù)做了修改,如果沒有修改則更新數(shù)據(jù),修改說明發(fā)生了安全問題
很顯然樂觀鎖的性能要顯著高于悲觀鎖,因此采用樂觀鎖保證線程的原子性。樂觀鎖又有兩種解決方案:版本號(hào)是指對(duì)修改的數(shù)據(jù)附帶一個(gè)version字段值,每次更新的時(shí)候判斷修改時(shí)的version與查詢的時(shí)候是否一致,一致則修改。CAS機(jī)制全稱為Compare And Swap譯為先比較再交換,也就是將修改的數(shù)據(jù)本身作為版本號(hào),每次更新的時(shí)候判斷修改時(shí)的數(shù)據(jù)值與查詢時(shí)的值是否相同,相同則修改,不同就說明發(fā)生了線程安全問題,在我們的這個(gè)售賣業(yè)務(wù)中,可以設(shè)置成只要庫存大于0就可以執(zhí)行成功
樂觀鎖代碼實(shí)現(xiàn)
樂觀鎖的核心就是,在更新數(shù)據(jù)的時(shí)候(也就是減少庫存),判斷一下庫存是否大于0,如果判斷失敗的話也應(yīng)該使該線程任務(wù)失敗
// 扣減庫存
boolean update = seckillVoucherService.update()
.setSql("stock = stock - 1")
.eq("voucher_id", voucherId)
.gt("stock", 0)
.update();
// 更新失敗說明在扣除庫存的時(shí)候 庫存小于等于0
if (!update) {
return Result.fail("庫存不足!");
}
一個(gè)用戶限買一單
業(yè)務(wù)邏輯分析
按照正常的業(yè)務(wù)邏輯,秒殺應(yīng)該限制一個(gè)用戶只能購買一次該商品,最簡單的方法就是對(duì)user_id使用唯一索引,如果user_id重復(fù)就會(huì)拋出相關(guān)異常,但是這需要修改表結(jié)構(gòu)。如果不修改標(biāo)結(jié)果的話就需要扣除庫存之前根據(jù)voucher_id和user_id查詢訂單表,如果存在的話就返回錯(cuò)誤,否則說明該用戶還未購買
代碼實(shí)現(xiàn)
單機(jī)(服務(wù)部署在一臺(tái)tomcat服務(wù)器)的情況下,加synchronized 鎖即可解決(查詢判斷用戶是否下單和創(chuàng)建訂單)業(yè)務(wù)的線程安全問題,但是這種情況就只能
// 單用戶id(攔截器中做登錄驗(yàn)證的用戶id)
Long userId = UserHolder.getUser().getId();
// 根據(jù)user_id加鎖 intern方法是去字符常量池中查找值相同的,不加的話字符串值一樣的地址不一樣也會(huì)加上鎖
synchronized (userId.toString().intern()) {
// 查詢優(yōu)惠券
// 判斷庫存是否充足
// user_id和voucher_id聯(lián)合查詢訂單數(shù)
Integer count = query().eq("user_id", userId)
.eq("voucher_id", voucherId)
.count();
// 訂單數(shù)為1 就說明已經(jīng)下過單了
if (count.equals(1)) {
return Result.fail("您已經(jīng)購買過該商品了");
}
// 扣減庫存 創(chuàng)建訂單
return Result.ok(orderId);
}
以上加synchronized 鎖的解決方案只適用于單機(jī)模式下,此時(shí)所有的請(qǐng)求過來都會(huì)按照userId去常量池中查找是否一致,一致的話就鎖在一起防止一個(gè)用戶購買多單。但是集群模式下所有的請(qǐng)求會(huì)經(jīng)過Nginx的負(fù)載均衡輪詢發(fā)送到集群上的所有服務(wù)器,如果一個(gè)用戶的多個(gè)請(qǐng)求被分配到不同的服務(wù)器上的話,不同服務(wù)器中的JVM虛擬機(jī)里的靜態(tài)常量池中的內(nèi)容是不同步的,這樣的話就會(huì)導(dǎo)致雖然userId一致但是各自所在的靜態(tài)常量池中都沒有,于是這個(gè)用戶就可以在不同的服務(wù)器分別下單了。如果有用戶使用腳本同時(shí)發(fā)送很多的下單請(qǐng)求,那么就會(huì)有極大的可能在每一個(gè)服務(wù)器中都下一單,那么如何解決這個(gè)問題呢?那就要學(xué)習(xí)分布式鎖的內(nèi)容了
到此這篇關(guān)于Redis實(shí)現(xiàn)商品秒殺功能頁面流程的文章就介紹到這了,更多相關(guān)Redis商品秒殺內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
SpringBoot如何返回Json數(shù)據(jù)格式
這篇文章主要介紹了SpringBoot如何返回Json數(shù)據(jù)格式問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-03-03
深度解析SpringBoot中@Async引起的循環(huán)依賴
本文主要介紹了深度解析SpringBoot中@Async引起的循環(huán)依賴,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-02-02
SpringBoot+MyBatis-Plus實(shí)現(xiàn)分頁示例
本文介紹了SpringBoot+MyBatis-Plus實(shí)現(xiàn)分頁示例,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-12-12
java源碼解析之String類的compareTo(String otherString)方法
這篇文章主要給大家介紹了關(guān)于java源碼解析之String類的compareTo(String otherString)方法的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),需要的朋友可以參考借鑒,下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2018-09-09
使用Java代碼將IP地址轉(zhuǎn)換為int類型的方法
這篇文章主要介紹了使用Java代碼將IP地址轉(zhuǎn)換為int類型的方法,這也是各大計(jì)算機(jī)考試和ACM以及面試的常見基礎(chǔ)問題,需要的朋友可以參考下2015-08-08
基于Java的Spring框架來操作FreeMarker模板的示例
這篇文章主要介紹了基于Java的Spring框架來操作FreeMarker模板的示例,講到了用于進(jìn)行web模板文件的插值操作等例子,需要的朋友可以參考下2016-03-03

