526互联

Redis学习之分布式全局id生成

发布时间 2023-10-06 16:17:14作者: 万事胜意k

介绍

为什么需要分布式全局 ID 生成器？

  1. 对于订单这种数据，数据库自增的规律性太明显，会暴露一些信息（比如根据昨日和今日的订单号差值看出销量）

  2. 数据量过大时，不同表的 id 分别自增，容易出现 id 冲突

分布式全局 ID 生成应满足的特点：

  1. 唯一：整个系统每个 id 都是唯一的

  2. 递增：虽然不连续，但整体 ID 保持递增，有利于数据库创建索引（也符合自然规律）

  3. 安全：不能通过 id 看出敏感业务信息

  4. 高可用：作为核心服务，不能挂掉，否则会影响新数据的生成

  5. 高性能：作为频繁调用的服务，性能一定要高

几种常见的 ID 生成方法，建议根据自己的实际需求选择和设计算法：

  • 雪花算法：性能更高，引入机器序号，但依赖全局时钟

  • 数据库自增：单独的自增表，所有 id 全从这个表取。但性能没有 Redis 高

  • UUID：随机生成十六进制字符串，性能高，但是乱序、字符串会占用更多空间

  • Redis 自增 ID：利用 incr 命令实现单 key 的自增

Redis 自增 ID 完全可以满足以上几个分布式全局 ID 的特点。

设计实现

image-20231006160138263

使用Redis 的Incr命令，可以实现后32位的原子性递增。

Redis的key可以设计为[业务]:[类型]:[日期]，这样每天都会从1开始生成序列号。如果用单key，可能会出现生成序号数溢出2^32的情况。（key设计为所述类型便于统计订单量）

实现

@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;
    }
}

测试

知识小贴士：关于countdownlatch

countdownlatch名为信号枪：主要的作用是同步协调在多线程的等待于唤醒问题

我们如果没有CountDownLatch ，那么由于程序是异步的，当异步程序没有执行完时，主线程就已经执行完了，然后我们期望的是分线程全部走完之后，主线程再走，所以我们此时需要使用到CountDownLatch

CountDownLatch 中有两个最重要的方法

1、countDown

2、await

await 方法 是阻塞方法，我们担心分线程没有执行完时，main线程就先执行，所以使用await可以让main线程阻塞，那么什么时候main线程不再阻塞呢？当CountDownLatch 内部维护的 变量变为0时，就不再阻塞，直接放行，那么什么时候CountDownLatch 维护的变量变为0 呢，我们只需要调用一次countDown ，内部变量就减少1，我们让分线程和变量绑定， 执行完一个分线程就减少一个变量，当分线程全部走完，CountDownLatch 维护的变量就是0，此时await就不再阻塞，统计出来的时间也就是所有分线程执行完后的时间。

    @Resource
    private RedisIdWorker redisIdWorker;
​
    private ExecutorService es = Executors.newFixedThreadPool(500);
    @Test
    void testIdWorker() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(300);
​
        Runnable task = () -> {
            for (int i = 0; i < 100; i++) {
                long id = redisIdWorker.nextId("order");
                System.out.println("id = " + id);
            }
            latch.countDown();
        };
        long begin = System.currentTimeMillis();
        for (int i = 0; i < 300; i++) {
            es.submit(task);
        }
        latch.await();
        long end = System.currentTimeMillis();
        System.out.println("time = " + (end - begin));
    }

运行结果

id没有出现重复

image-20231006161103653