亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

Redis實(shí)現(xiàn)商品秒殺功能頁面流程

 更新時間:2022年09月15日 11:51:53   作者:扎哇太棗糕  
這篇文章主要介紹了Redis實(shí)現(xiàn)商品秒殺功能的方法,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

全局唯一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)解析

    這篇文章主要介紹了Apache?SkyWalking?監(jiān)控?MySQL?Server?實(shí)戰(zhàn)解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2022-09-09
  • java三個環(huán)境變量配置簡單教程

    java三個環(huán)境變量配置簡單教程

    這篇文章主要為大家詳細(xì)介紹了java三個環(huán)境變量配置簡單教程,配置path變量、配置classpath變量、最后是配置JAVA_HOME變量,感興趣的小伙伴們可以參考一下
    2016-07-07
  • 前端如何傳遞Array、Map類型數(shù)據(jù)到Java后端

    前端如何傳遞Array、Map類型數(shù)據(jù)到Java后端

    這篇文章主要給大家介紹了關(guān)于前端如何傳遞Array、Map類型數(shù)據(jù)到Java后端的相關(guān)資料,文中通過圖文介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2024-01-01
  • 淺談java的守護(hù)線程與非守護(hù)線程

    淺談java的守護(hù)線程與非守護(hù)線程

    這篇文章主要介紹了淺談java的守護(hù)線程與非守護(hù)線程,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2017-10-10
  • 淺談Java中向上造型向下造型和接口回調(diào)中的問題

    淺談Java中向上造型向下造型和接口回調(diào)中的問題

    這篇文章主要介紹了淺談Java中向上造型向下造型和接口回調(diào)中的問題,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2020-08-08
  • 分享Java常用幾種加密算法(四種)

    分享Java常用幾種加密算法(四種)

    Base64是網(wǎng)絡(luò)上最常見的用于傳輸8Bit字節(jié)代碼的編碼方式之一,大家可以查看RFC2045~RFC2049,上面有MIME的詳細(xì)規(guī)范。本文給大家分享java常用的幾種加密算法,需要的朋友可以參考下
    2015-10-10
  • SpringBoot集成WebSocket實(shí)現(xiàn)后臺向前端推送信息

    SpringBoot集成WebSocket實(shí)現(xiàn)后臺向前端推送信息

    在一次項目開發(fā)中,使用到了Netty網(wǎng)絡(luò)應(yīng)用框架,以及MQTT進(jìn)行消息數(shù)據(jù)的收發(fā),這其中需要后臺來將獲取到的消息主動推送給前端,所以本文記錄了SpringBoot集成WebSocket實(shí)現(xiàn)后臺向前端推送信息的操作,需要的朋友可以參考下
    2024-02-02
  • Java如何使用poi導(dǎo)入導(dǎo)出excel工具類

    Java如何使用poi導(dǎo)入導(dǎo)出excel工具類

    這篇文章主要介紹了Java如何使用poi導(dǎo)入導(dǎo)出excel工具類問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教
    2024-06-06
  • SpringCloud配置服務(wù)端的ConfigServer設(shè)置安全認(rèn)證

    SpringCloud配置服務(wù)端的ConfigServer設(shè)置安全認(rèn)證

    這篇文章主要為大家介紹了SpringCloud配置服務(wù)端的ConfigServer設(shè)置安全認(rèn)證,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-08-08
  • 簡單了解redis常見客戶端及Sharding機(jī)制原理

    簡單了解redis常見客戶端及Sharding機(jī)制原理

    這篇文章主要介紹了簡單了解redis常見客戶端及Sharding機(jī)制原理,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下
    2020-09-09

最新評論