【Redis場景拓展】秒殺問題-全局唯一ID生成策略

全局唯一ID

爲什麼要使用全局唯一ID：

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

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

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

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

場景分析三：如果全部使用數據庫自增長ID，那麼多張表都會出現相同的ID，不滿足業務需求。

在分佈式系統下全局唯一ID需要滿足的特點：

1. 唯一性
2. 遞增性
3. 安全性
4. 高可用(服務穩定)
5. 高性能(生成速度夠快)

爲了提高數據庫性能，這裏採用Java中的數值類型(Long--8(Byte)字節，64位),

• ID的組成部分：符號位：1bit，永遠爲0
• 時間戳：31bit，以秒爲單位，可以使用69年
• 序列號：32bit，秒內的計數器，支持每秒產生2^32個不同ID

類雪花算法開發

我們的生成策略是基於redis的自增長，及序列號部分，在實現的時候需要傳入不同的前綴(即不同業務不同序列號)

我們開始實現時間戳位數，先設置一個基準值，即某一時間的秒數，使用的時候用當前時間秒數-基準時間=所得秒數即時間戳；

基準值計算：這裏我是用2023/1/1 0:0:0;秒數爲：1672531200

public static void main(String[] args) {
    LocalDateTime time = LocalDateTime.of(2023, 1, 1, 0, 0, 0);
    //設置時區
    long l = time.toEpochSecond(ZoneOffset.UTC);
    System.out.println(l);
}

開始生成時間戳：獲得當前時間的秒數-基準值(BEGIN_TIMESTAMP=1672531200)

LocalDateTime dateTime = LocalDateTime.now();
//秒數設置時區
long nowSecond = dateTime.toEpochSecond(ZoneOffset.UTC);
long timestamp = nowSecond - BEGIN_TIMESTAMP;

然後生成序列號，採用Redis的自增操作實現。keyPrefix業務Key(傳入的)

long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix);

這一行代碼的使用問題是，同一個業務使用的同一個key,但是redis的自增上限爲2^64，總有時候會超過32位，所以最好是讓其同一業務也要有不同的key值，這裏我們可以加上當前時間。

//獲取當日日期，精確到天
String date = dateTime.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
//自增長上限2^64
long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);

這樣做的好處是：

1. 在redis中緩存是分層的，方便查看，也方便統計每天、每月的訂單量或者其他數據等
2. 不會超過Redis的自增長的值，安全性提高

最後將時間戳和序列號進行拼接即可，位運算。COUNT_BITS=32

timestamp << COUNT_BITS | count;

首先將時間戳左移32位，低處補零，然後進行或運算(遇1得1)，這樣實現整個的全局唯一ID。

測試

在同一個業務中使用全局唯一ID生成。

/**
 * 測試全局唯一ID生成器
 * @throws InterruptedException
 */
@Test
public  void testIdWorker() throws InterruptedException {
    CountDownLatch countDownLatch = new CountDownLatch(300);
    ExecutorService executorService = Executors.newFixedThreadPool(300);
    Runnable task = ()->{
        for (int i = 0; i < 100; i++) {
            long id = redisIdWorker.nextId("order");
            System.out.println("id："+id);
        }
        //計數-1
        countDownLatch.countDown();
    };
    long begin = System.currentTimeMillis();
    for (int i = 0; i < 300; i++) {
        executorService.submit(task);
    }
    //等待子線程結束
    countDownLatch.await();
    long endTime = System.currentTimeMillis();
    System.out.println("time= "+(endTime-begin));
}

time= 2608ms=2.68s，生成數量：30000

取兩個相近的十進制轉爲二進制對比：

id ： 148285184708444304

0010 0000 1110 1101 0000 1001 0111 0000 0000 0000 0000 0000 0000 1001 0000

id ： 148285184708444305

0010 0000 1110 1101 0000 1001 0111 0000 0000 0000 0000 0000 0000 1001 0001

短碼生成策略

僅支持很小的調用量，用於生成活動配置類編號，保證全局唯一

import java.util.Calendar;
import java.util.Random;

/**
 * @author xbhog
 * @describe:短碼生成策略，僅支持很小的調用量，用於生成活動配置類編號，保證全局唯一
 * @date 2022/9/18
 */
@Slf4j
@Component
public class ShortCode implements IIdGenerator {
    @Override
    public synchronized long nextId() {
        Calendar calendar = Calendar.getInstance();
        int year = calendar.get(Calendar.YEAR);
        int week = calendar.get(Calendar.WEEK_OF_YEAR);
        int day = calendar.get(Calendar.DAY_OF_WEEK);
        int hour = calendar.get(Calendar.HOUR_OF_DAY);
        log.info("年：{}，周：{}，日：{}，小時：{}",year, week,day,hour);
        //打亂順序：2020年爲準 + 小時 + 週期 + 日 + 三位隨機數
        StringBuilder idStr = new StringBuilder();
        idStr.append(year-2020);
        idStr.append(hour);
        idStr.append(String.format("%02d",week));
        idStr.append(day);
        idStr.append(String.format("%03d",new Random().nextInt(1000)));
        log.info("查看拼接之後的值：{}",idStr);
        return Long.parseLong(idStr.toString());
    }

    public static void main(String[] args) {
        long l = new ShortCode().nextId();
        System.out.println(l);
    }
}

日誌記錄：

14:40:22.336 [main] INFO ShortCode - 年：2023，周：5，日：7，小時：14
14:40:22.341 [main] INFO ShortCode - 查看拼接之後的值：314057012
314057012