【Redis场景拓展】秒杀问题-全局唯一ID生成策略

全局唯一ID

为什么要使用全局唯一ID：

当用户抢购时,就会生成订单并保存到订单表中,而订单表如果使用数据库自增ID就存在一些问题：

受单表数据量的限制

id的规律性太明显

场景分析一：如果我们的id具有太明显的规则,用户或者说商业对手很容易猜测出来我们的一些敏感信息,比如商城在一天时间内,卖出了多少单,这明显不合适.

场景分析三：如果全部使用数据库自增长ID,那么多张表都会出现相同的ID,不满足业务需求.

在分布式系统下全局唯一ID需要满足的特点：

唯一性

递增性

安全性

高可用(服务稳定)

高性能(生成速度够快)

ID的组成部分：符号位：1bit,永远为0

类雪花算法开发

我们的生成策略是基于redis的自增长,及序列号部分,在实现的时候需要传入不同的前缀(即不同业务不同序列号)

我们开始实现时间戳位数,先设置一个基准值,即某一时间的秒数,使用的时候用当前时间秒数-基准时间=所得秒数即时间戳；

public static void main(String[] args) {

System.out.println(l);
}

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);

//获取当日日期,精确到天
String date = dateTime.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
//自增长上限2^64
long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);

这样做的好处是：

在redis中缓存是分层的,方便查看,也方便统计每天、每月的订单量或者其他数据等

不会超过Redis的自增长的值,安全性提高

timestamp << COUNT_BITS | count;

测试

在同一个业务中使用全局唯一ID生成.

/**
 * 测试全局唯一ID生成器
 * @throws InterruptedException
 */
@Test
public  void testIdWorker() throws InterruptedException {
    for (int i = 0; i < 100; i++) {
for (int i = 0; i < 300; i++) {
System.out.println("time= "+(endTime-begin));
}

取两个相近的十进制转为二进制对比：

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

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 {
}
}

日志记录：

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

以上就是土嘎嘎小编为大家整理的【Redis场景拓展】秒杀问题-全局唯一ID生成策略相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！