黑馬點評筆記 redis實現優惠卷秒殺

文章目錄

難題
全局唯一ID
- Redis實現全局唯一Id
超賣問題
- 問題
- 解決方案
- - 樂觀鎖
  - - 問題
一人一單

難題

要解決優惠卷秒殺的問題我們要考慮到三個個問題，全局唯一ID，超賣問題，一人一單。

全局唯一ID

用戶搶購時，就會生成訂單并保存到同一張表中，而訂單表如果使用數據庫自增ID就存在一些問題：

id的規律性太明顯
受單表數據量的限制

場景分析：如果我們的id具有太明顯的規則，用戶或者說商業對手很容易猜測出來我們的一些敏感信息，比如商城在一天時間內，賣出了多少單，這明顯不合適。

場景分析：隨著我們商城規模越來越大，mysql的單表的容量不宜超過500W，數據量過大之后，我們要進行拆庫拆表，但拆分表了之后，他們從邏輯上講他們是同一張表，所以他們的id是不能一樣的，于是乎我們需要保證id的唯一性。

全局ID生成器，是一種在分布式系統下用來生成全局唯一ID的工具，一般要滿足下列特性：
在這里插入圖片描述
為了增加ID的安全性，我們可以不直接使用Redis自增的數值，而是拼接一些其它信息：

在這里插入圖片描述
ID的組成部分：符號位：1bit，永遠為0

時間戳：31bit，以秒為單位，可以使用69年

序列號：32bit，秒內的計數器，支持每秒產生2^32個不同ID

Redis實現全局唯一Id

@Component
public class RedisIdWorker {/*** 開始時間戳*/private static final long BEGIN_TIMESTAMP = 1640995200L;/*** 序列號的位數*/private static final int COUNT_BITS = 32;private StringRedisTemplate stringRedisTemplate;public RedisIdWorker(StringRedisTemplate stringRedisTemplate) {this.stringRedisTemplate = stringRedisTemplate;}public long nextId(String keyPrefix) {// 1.生成時間戳LocalDateTime now = LocalDateTime.now();long nowSecond = now.toEpochSecond(ZoneOffset.UTC);long timestamp = nowSecond - BEGIN_TIMESTAMP;// 2.生成序列號// 2.1.獲取當前日期，精確到天String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));// 2.2.自增長long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);// 3.拼接并返回return timestamp << COUNT_BITS | count;}
}

超賣問題

秒殺下單應該思考的內容：

下單時需要判斷兩點：

秒殺是否開始或結束，如果尚未開始或已經結束則無法下單
庫存是否充足，不足則無法下單

下單核心邏輯分析：

當用戶開始進行下單，我們應當去查詢優惠卷信息，查詢到優惠卷信息，判斷是否滿足秒殺條件

比如時間是否充足，如果時間充足，則進一步判斷庫存是否足夠，如果兩者都滿足，則扣減庫存，創建訂單，然后返回訂單id，如果有一個條件不滿足則直接結束。

在這里插入圖片描述


@Override
public Result seckillVoucher(Long voucherId) {// 1.查詢優惠券SeckillVoucher voucher = seckillVoucherService.getById(voucherId);// 2.判斷秒殺是否開始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {// 尚未開始return Result.fail("秒殺尚未開始！");}// 3.判斷秒殺是否已經結束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {// 尚未開始return Result.fail("秒殺已經結束！");}// 4.判斷庫存是否充足if (voucher.getStock() < 1) {// 庫存不足return Result.fail("庫存不足！");}//5，扣減庫存boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update();if (!success) {//扣減庫存return Result.fail("庫存不足！");}//6.創建訂單VoucherOrder voucherOrder = new VoucherOrder();// 6.1.訂單idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 6.2.用戶idLong userId = UserHolder.getUser().getId();voucherOrder.setUserId(userId);// 6.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);return Result.ok(orderId);}

問題

其實按照串行的方法我們上面的代碼已經實現的解決了超賣問題，但在現實中web往往是高并發的，我們的代碼任然存在以下問題，

 if (voucher.getStock() < 1) {// 庫存不足return Result.fail("庫存不足！");}//5，扣減庫存boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update();if (!success) {//扣減庫存return Result.fail("庫存不足！");}

假設線程1過來查詢庫存，判斷出來庫存大于1，正準備去扣減庫存，但是還沒有來得及去扣減，此時線程2過來，線程2也去查詢庫存，發現這個數量一定也大于1，那么這兩個線程都會去扣減庫存，最終多個線程相當于一起去扣減庫存，此時就會出現庫存的超賣問題。
在這里插入圖片描述

解決方案

超賣問題是典型的多線程安全問題，針對這一問題的常見解決方案就是加鎖：而對于加鎖，我們通常有兩種解決方案：

悲觀鎖：
- 悲觀鎖可以實現對于數據的串行化執行，比如syn，和lock都是悲觀鎖的代表，同時，悲觀鎖中又可以再細分為公平鎖，非公平鎖，可重入鎖，等等
樂觀鎖：
- 樂觀鎖：會有一個版本號，每次操作數據會對版本號+1，再提交回數據時，會去校驗是否比之前的版本大1 ，如果大1 ，則進行操作成功，這套機制的核心邏輯在于，如果在操作過程中，版本號只比原來大1 ，那么就意味著操作過程中沒有人對他進行過修改，他的操作就是安全的，如果不大1，則數據被修改過，當然樂觀鎖還有一些變種的處理方式比如cas。

樂觀鎖

樂觀鎖解決超賣問題的核心就是版本號法，它的流程大致如下圖：
在這里插入圖片描述
代碼實現：

boolean success = seckillVoucherService.update().setSql("stock= stock -1") //set stock = stock -1.eq("voucher_id", voucherId).eq("stock",voucher.getStock()).update(); //where id = ？ and stock = ?

以上邏輯的核心含義是：只要我扣減庫存時的庫存和之前我查詢到的庫存是一樣的，就意味著沒有人在中間修改過庫存，那么此時就是安全的，但是以上這種方式通過測試發現會有很多失敗的情況，失敗的原因在于：在使用樂觀鎖過程中假設100個線程同時都拿到了100的庫存，然后大家一起去進行扣減，但是100個人中只有1個人能扣減成功，其他的人在處理時，他們在扣減時，庫存已經被修改過了，所以此時其他線程都會失敗

問題

雖然以上代碼解決了超賣問題，但是代碼的效率還是太低了，因為每次用戶都需要檢測庫存是否一致，但是我們的需求要把庫存扣減最低控制到零，所以我們只需要保證庫存大于0就可以

boolean success = seckillVoucherService.update().setSql("stock= stock -1").eq("voucher_id", voucherId).update().gt("stock",0); //where id = ? and stock > 0

一人一單

惠卷是為了引流，但是目前的情況是，一個人可以無限制的搶這個優惠卷，所以我們應當增加一層邏輯，讓一個用戶只能下一個單，而不是讓一個用戶下多個單

具體操作邏輯如下：比如時間是否充足，如果時間充足，則進一步判斷庫存是否足夠，然后再根據優惠卷id和用戶id查詢是否已經下過這個訂單，如果下過這個訂單，則不再下單，否則進行下單
在這里插入圖片描述
**存在問題：**現在的問題還是和之前一樣，并發過來，查詢數據庫，都不存在訂單，所以我們還是需要加鎖，但是樂觀鎖比較適合更新數據，而現在是插入數據，所以我們需要使用悲觀鎖操作。

@Transactional
public  Result createVoucherOrder(Long voucherId) {Long userId = UserHolder.getUser().getId();synchronized(userId.toString().intern()){// 5.1.查詢訂單int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();// 5.2.判斷是否存在if (count > 0) {// 用戶已經購買過了return Result.fail("用戶已經購買過一次！");}// 6.扣減庫存boolean success = seckillVoucherService.update().setSql("stock = stock - 1") // set stock = stock - 1.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0.update();if (!success) {// 扣減失敗return Result.fail("庫存不足！");}// 7.創建訂單VoucherOrder voucherOrder = new VoucherOrder();// 7.1.訂單idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 7.2.用戶idvoucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);// 7.返回訂單idreturn Result.ok(orderId);}
}