基于Redis自增实现全局ID生成器（详解）

向上的咸鱼blueblue

已于 2024-07-07 11:43:15 修改

阅读量2k

点赞数 21

分类专栏： Redis 文章标签：数据库

于 2024-03-08 11:30:58 首次发布

本文链接：https://blog.csdn.net/aaa131420030415/article/details/136555545

版权

Redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

本博客为个人学习笔记，学习网站与详细见：黑马程序员Redis入门到实战 P48 - P49

全局ID生成器介绍

背景介绍
当用户在抢购商品时，会生成订单并保存到数据库的某一张表中，而订单id如果使用数据库表的自增ID就会存在一些问题：
1. id的规律性太明显
2. 受单表数据量的限制

基于使用数据库自增ID带来的两个问题，我们来做场景分析：
1. 场景分析一：如果订单id具有太明显的规则，用户或者说商业对手很容易猜测出我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。
2. 场景分析二：MySQL的单表容量不宜超过500万条记录。随着我们商城规模的扩大，数据量增长到一定程度后，我们需要进行数据库拆分和表拆分。拆分后，这些表在逻辑上仍然属于同一张表，因此它们之间的数据ID不能相同。因此，我们必须确保全局ID的唯一性。

全局ID生成器
全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：
1. 唯一性
2. 高性能
3. 高可用
4. 递增性
5. 安全性

基于Redis自增实现全局ID

全局ID组成结构图：

序列号：由于Redis的自增操作是原子性的，保证了在并发情况下生成ID的唯一性，避免了传统数据库中的锁竞争和性能瓶颈。因此我们可以利用Redis的自增原子性，让序列号由Redis自增的数值组成，因此我们确保了全局ID序列号的唯一性，从而确保了整个全局ID的唯一性。

同时，我们还需要考虑一个问题，我们利用Redis自增实现全局ID，但如果我们只设置一个Key值，随着业务的日积月累，自增值将会达到上限。为避免这种情况发生，我们需要设置不同的Key值，于是我们决定用年月日的格式 yyyy:MM:dd 来添加到Key值的前缀当中，因此一个Key值的自增量不再是用来表示所有时间的业务量，而只是用来表示某年某月某天的业务量，而一天的业务量是不可能超过 2^32 (几十亿) 这么大的数值的，我们从而确保了Key值不会达到上限。

而这种做法也方便了我们对业务数据的统计，当我们想查询一年中的业务量时，我们只需要查询前缀为 yyyy 的Key值自增量即可，如果我们想查询某年某月的业务量时，我们只需要查询前缀为 yyyy:MM 的Key值自增量即可。

时间戳：为了增加全局ID的安全性，我们并能不直接把Redis的自增值(序列号)当作全局ID，而是应该在此基础上拼接一些其它信息，我们可以先设置某一个时间的时间戳作为参照时间戳，如2000年1月1日0时0分0秒，之后每当用户下单，我们可以获取下单时间的时间戳，再与参照时间戳做差，得到的差值用来组成全局ID的时间戳这一部分。（显然，我们全局ID设置的时间戳只有32位，因此我们需要确保差值是在2^32大小内，而2^32秒相当于136年的时间，因此是妥妥够用的，或者我们也可以选择对参照时间差进行调整来确保差值不会超过2^32）

实现代码

全局ID生成器代码如下

@Component
public class RedisIdWorker {

    private static final long BEGIN_TIMESTAMP = 1640995200L;
    private static final long COUNT_BITS = 32;

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    public long nextId(String KeyPrefix) {
        // 1.生成全局ID时间戳部分
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp = nowSecond - BEGIN_TIMESTAMP;

        // 2.生成全局ID序列号部分
        // 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;
    }

    // 用于计算20220101时间戳给BEGIN_TIMESTAMP赋值
    public static void main(String[] args) {
        LocalDateTime time = LocalDateTime.of(2022, 1, 1, 0, 0, 0);
        long second = time.toEpochSecond(ZoneOffset.UTC);
        System.out.println("second = " + second);
    }

}

功能测试

编写测试类对全局ID生成器进行测试，在测试类中开启300个线程，让每个线程生成100个全局ID，最终将生成30000个ID，Redis中对应的key自增长将会达到30000。

@SpringBootTest
class HmDianPingApplicationTests {

    @Resource
    private RedisIdWorker redisIdWorker;

    //建立线程池，赋予500个线程
    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));
    }

}

成功运行测试类后，在RESP中查询对应的key值，如下图所示，key值为30000，和预期相同。

知识小贴士：关于CountDownLatch

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

如果没有CountDownLatch ，由于程序是异步的，当异步程序没有执行完时，主线程就已经执行完了，这将导致计时失效。我们期望的是分线程全部走完之后，主线程再走，所以我们需要使用到CountDownLatch。

CountDownLatch 中有两个重要的方法

1、countDown

2、await

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