Redis實(shí)現(xiàn)商品秒殺功能頁面流程
全局唯一ID
業(yè)務(wù)邏輯分析
全局唯一ID是針對銷量比較大的一些商品而言的,這類商品的成交量比較多,用戶購買成功就會生成對應(yīng)訂單信息并保存到一張表中,而訂單表的id如果使用數(shù)據(jù)庫自增ID就存在一些問題,比如說id的規(guī)律性太強(qiáng)導(dǎo)致安全性極低,還有如果訂單數(shù)量太多一張表存不下分成多張表存儲的話就會出現(xiàn)ID沖突問題,于是我們需要一個全局ID生成器,保證ID在全局中都是唯一的
使用Redis即可完成這種全局ID生成器的功能,具體實(shí)現(xiàn)就是一種類雪花算法,也就是符號位、時間戳、序列號三部分拼接形成一個ID,邏輯就是符號位0代表整數(shù),時間戳確定具體到下訂單的時候是哪一秒,至于序列號就是用于區(qū)分這一秒的訂單,序列號使用redis的值自增來保證所有序列號不一致,原則上一秒中最多可以有232個不同的ID
代碼實(shí)現(xiàn)
@Component public class RedisIdGenerator { /** * 構(gòu)造方法注入stringRedisTemplate對象 */ private StringRedisTemplate stringRedisTemplate; public RedisIdGenerator(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } // 定義序列號的位數(shù) private static final int COUNT_BITS = 30; public long nextId(String keyPrefix) { // 生成從指定時間到現(xiàn)在的時間戳 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; /** * 生成序列號 使用redis的incr方法 K值為"icr:" + keyPrefix + ":" + date * 也就是按照日期作為K 每下一次單V就自增1作為序列號添加到后面 * 這樣的話既避免了K固定帶來的V超過最大閾值(redis中的V最大為2^64) * 而且還方便了統(tǒng)計一天、一個月、一年的訂單量,在這段時間內(nèi)最大的序列號就是它的最多訂單數(shù) */ String date = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy:MM:dd")); Long sequenceId = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date); // 拼接生成全局唯一ID并返回 兩個二進(jìn)制的拼接可以使用前一個數(shù)左移一定位數(shù) 后一個數(shù)與位移后的進(jìn)行或運(yùn)算 return timeStamp << COUNT_BITS | sequenceId; } }
優(yōu)惠券秒殺
業(yè)務(wù)邏輯分析
用戶對秒殺商品下單的時候,后臺業(yè)務(wù)需要先完成對商品時間的判斷,判斷該商品的秒殺活動是否開始或者有沒有結(jié)束,但凡還未開始或者已經(jīng)結(jié)束都無法下單;時間信息正確的話就判斷該商品的活動庫存還有沒有剩余,如果已經(jīng)賣完的話也無法下單。時間和庫存的判斷都是通過前端傳過來的優(yōu)惠券id,查出來該優(yōu)惠券的時間和庫存信息,如果條件都滿足的話,將該商品券的庫存扣除,然后創(chuàng)建訂單返回訂單id
代碼實(shí)現(xiàn)
controller層主要就是調(diào)用service接口里的secKillVoucher方法,所以整個業(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); // 獲取時間 判斷秒殺活動是否開始或者結(jié)束 if (seckillVoucher.getBeginTime().isAfter(LocalDateTime.now())) { return Result.fail("活動暫未開始"); } else if (seckillVoucher.getEndTime().isBefore(LocalDateTime.now())) { return Result.fail("活動已經(jīng)結(jié)束"); } // 判斷庫存是否充足 if (seckillVoucher.getStock() < 1) { return Result.fail("庫存不足,活動結(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é)束這個活動。但是現(xiàn)實(shí)中的秒殺業(yè)務(wù)都是多線程的,很多的用戶同時等著活動開啟一起點(diǎn)擊下單,這樣的話就極有可能出現(xiàn)線程安全問題也就是說最終成交的數(shù)量要多于活動商品的數(shù)量
上述問題出現(xiàn)的原因就是多線程之間的執(zhí)行順序所引起,我們的秒殺業(yè)務(wù)里面是先查詢庫存數(shù)量大于1就產(chǎn)生訂單,但是多線程之間的執(zhí)行不會嚴(yán)格的按照這個順序執(zhí)行,而是交叉執(zhí)行,如果最后只剩一張票的時候進(jìn)來了兩個線程AB,A查完B查AB查詢結(jié)果都可以下單,A產(chǎn)生訂單B再產(chǎn)生訂單,此時就已經(jīng)產(chǎn)生超賣
樂觀鎖與悲觀鎖
解決線程問題的最好方法就是加鎖,但是鎖也分為悲觀鎖和樂觀鎖,悲觀鎖認(rèn)為線程安全問題一定會發(fā)生,因此在操作數(shù)據(jù)之前先獲取鎖,確保線程串行執(zhí)行,例如Synchronized、Lock等。樂觀鎖認(rèn)為線程安全問題不一定會發(fā)生,因此不加鎖,只是在更新數(shù)據(jù)時去判斷有沒有其它線程對數(shù)據(jù)做了修改,如果沒有修改則更新數(shù)據(jù),修改說明發(fā)生了安全問題
很顯然樂觀鎖的性能要顯著高于悲觀鎖,因此采用樂觀鎖保證線程的原子性。樂觀鎖又有兩種解決方案:版本號是指對修改的數(shù)據(jù)附帶一個version字段值,每次更新的時候判斷修改時的version與查詢的時候是否一致,一致則修改。CAS機(jī)制全稱為Compare And Swap譯為先比較再交換,也就是將修改的數(shù)據(jù)本身作為版本號,每次更新的時候判斷修改時的數(shù)據(jù)值與查詢時的值是否相同,相同則修改,不同就說明發(fā)生了線程安全問題,在我們的這個售賣業(yè)務(wù)中,可以設(shè)置成只要庫存大于0就可以執(zhí)行成功
樂觀鎖代碼實(shí)現(xiàn)
樂觀鎖的核心就是,在更新數(shù)據(jù)的時候(也就是減少庫存),判斷一下庫存是否大于0,如果判斷失敗的話也應(yīng)該使該線程任務(wù)失敗
// 扣減庫存 boolean update = seckillVoucherService.update() .setSql("stock = stock - 1") .eq("voucher_id", voucherId) .gt("stock", 0) .update(); // 更新失敗說明在扣除庫存的時候 庫存小于等于0 if (!update) { return Result.fail("庫存不足!"); }
一個用戶限買一單
業(yè)務(wù)邏輯分析
按照正常的業(yè)務(wù)邏輯,秒殺應(yīng)該限制一個用戶只能購買一次該商品,最簡單的方法就是對user_id使用唯一索引,如果user_id重復(fù)就會拋出相關(guān)異常,但是這需要修改表結(jié)構(gòu)。如果不修改標(biāo)結(jié)果的話就需要扣除庫存之前根據(jù)voucher_id和user_id查詢訂單表,如果存在的話就返回錯誤,否則說明該用戶還未購買
代碼實(shí)現(xiàn)
單機(jī)(服務(wù)部署在一臺tomcat服務(wù)器)的情況下,加synchronized 鎖即可解決(查詢判斷用戶是否下單和創(chuàng)建訂單)業(yè)務(wù)的線程安全問題,但是這種情況就只能
// 單用戶id(攔截器中做登錄驗(yàn)證的用戶id) Long userId = UserHolder.getUser().getId(); // 根據(jù)user_id加鎖 intern方法是去字符常量池中查找值相同的,不加的話字符串值一樣的地址不一樣也會加上鎖 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ī)模式下,此時所有的請求過來都會按照userId去常量池中查找是否一致,一致的話就鎖在一起防止一個用戶購買多單。但是集群模式下所有的請求會經(jīng)過Nginx的負(fù)載均衡輪詢發(fā)送到集群上的所有服務(wù)器,如果一個用戶的多個請求被分配到不同的服務(wù)器上的話,不同服務(wù)器中的JVM虛擬機(jī)里的靜態(tài)常量池中的內(nèi)容是不同步的,這樣的話就會導(dǎo)致雖然userId一致但是各自所在的靜態(tài)常量池中都沒有,于是這個用戶就可以在不同的服務(wù)器分別下單了。如果有用戶使用腳本同時發(fā)送很多的下單請求,那么就會有極大的可能在每一個服務(wù)器中都下一單,那么如何解決這個問題呢?那就要學(xué)習(xí)分布式鎖的內(nèi)容了
到此這篇關(guān)于Redis實(shí)現(xiàn)商品秒殺功能頁面流程的文章就介紹到這了,更多相關(guān)Redis商品秒殺內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Apache?SkyWalking?監(jiān)控?MySQL?Server?實(shí)戰(zhàn)解析
這篇文章主要介紹了Apache?SkyWalking?監(jiān)控?MySQL?Server?實(shí)戰(zhàn)解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-09-09前端如何傳遞Array、Map類型數(shù)據(jù)到Java后端
這篇文章主要給大家介紹了關(guān)于前端如何傳遞Array、Map類型數(shù)據(jù)到Java后端的相關(guān)資料,文中通過圖文介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考借鑒價值,需要的朋友可以參考下2024-01-01淺談Java中向上造型向下造型和接口回調(diào)中的問題
這篇文章主要介紹了淺談Java中向上造型向下造型和接口回調(diào)中的問題,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-08-08SpringBoot集成WebSocket實(shí)現(xiàn)后臺向前端推送信息
在一次項目開發(fā)中,使用到了Netty網(wǎng)絡(luò)應(yīng)用框架,以及MQTT進(jìn)行消息數(shù)據(jù)的收發(fā),這其中需要后臺來將獲取到的消息主動推送給前端,所以本文記錄了SpringBoot集成WebSocket實(shí)現(xiàn)后臺向前端推送信息的操作,需要的朋友可以參考下2024-02-02Java如何使用poi導(dǎo)入導(dǎo)出excel工具類
這篇文章主要介紹了Java如何使用poi導(dǎo)入導(dǎo)出excel工具類問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-06-06SpringCloud配置服務(wù)端的ConfigServer設(shè)置安全認(rèn)證
這篇文章主要為大家介紹了SpringCloud配置服務(wù)端的ConfigServer設(shè)置安全認(rèn)證,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-08-08簡單了解redis常見客戶端及Sharding機(jī)制原理
這篇文章主要介紹了簡單了解redis常見客戶端及Sharding機(jī)制原理,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2020-09-09