Redis 实现全局唯一id

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: Redis 实现全局唯一id

ID 生成器在微博我们一直叫发号器,微博就是用这样的号来存储,而我微博里讨论的时候也都是以发号器为标签。它的主要目的确如平常大家理解的“为一个分布式系统的数据object产生一个唯一的标识”,但其实在一个真实的系统里可能也可以承担更多的作用。概括起来主要有以下几点:


  1. 唯一性


  1. 时间相关


  1. 粗略有序


  1. 可反解


  1. 可制造


下面我会分别讲每个作用后面的考虑和权衡,也会对比介绍一下业界已知的几种 ID 设计。


  1. 要唯一性,是否需要全局唯一?


说起全局唯一,通常大家都会在想到发号器服务,分布式的通常需要更大空间,中心式的则需要在一个合适的地方在会聚。这就可能涉及到锁,而锁意味着成本和性能的下降。所以当前的系统是否需要全局的唯一性,就是一个需要考虑的问题。


比如在通讯系统里,聊天消息可能就未必需要全局,因为一条消息只是某一个人发出,系统只要保证一个人维度的唯一性即可。本质上而言,这里利用了用户 ID 的唯一性,因为唯一性是可以依赖的,通常我们设计系统也都是基于类似的性质,比如后面降到的使用时间唯一性的方式。


  1. 用时间来做什么?千万年太久,只争朝夕?


前面说到唯一性可以依赖,我们需要选择的是依赖什么。通常的做法可以选择数据库自增,这在很多数据库里都是可以满足ACID 的操作。但是用数据库有个缺点,就是数据库有性能问题,在多机房情况下也很难处理。当然,你可以通过调整自增的步长来设计,但对于一个发号器而言,操作和维护都略重了。


而时间是天然唯一的,因此也是很多设计的选择。但对于一个8Byte的 ID 而言,时间并没有那么多。你如果精确到秒级别,三十年都要使用30bit,到毫秒级则要再增加10bit,你也只剩下20bit 可以做其他事情了。之所以在8Byte 上捣鼓,因为8Byte 是一个Long,不管在处理器和编译器还是语言层面,都是可以更好地被处理。


然而三十年够么?对于一个人来说,可能不够,但对一个系统而言,可能足够。我们经常开玩笑,互联网里能活三十年的系统有多少呢?三十年过去,你的系统可能都被重写 N 遍了。这样的信心同样来自于摩尔定律,三十年后,计算性能早就提高了上千倍,到时候更多Byte 都不会是问题了。


  1. 粗略有多粗略,秒还是毫秒?


每秒一个或者每毫秒一个ID明显是不够的,刚才说到还有20bit 可以做其他事情,就包括一个SequenceID。如果要达到精确的有序,就要对 Sequence 进行并发控制,性能上肯定会打折。所以经常会有的一个选择就是,在这个秒的级别上不再保证顺序,而整个 ID 则只保证时间上的有序。后一秒的 ID肯定比前一秒的大,但同一秒内可能后取的ID比前面的号小。这在使用时非常关键,你要理解,系统也要接受才可以。


那时间用秒还是毫秒呢?其实不用毫秒的时候就可以把空出来的10bit 送给 Sequence,但整个ID 的精度就下降了。峰值速度是更现实的考虑。Sequence 的空间决定了峰值的速度,而峰值也就意味着持续的时间不会太久。这方面,每秒100万比每毫秒1000限制更小。


  1. 可反解,解开的是什么?


一个 ID 生成之后,就会伴随着信息终身,排错分析的时候,我们需要查验。这时候一个可反解的 ID 可以帮上很多忙,从哪里来的,什么时候出生的。跟身份证倒有点儿相通了,其实身份证就是一个典型的分布式 ID 生成器。


如果ID 里已经有了时间而且能解开,在存储层面可能不再需要timestamp 一类的字段了。微博的 ID 还有很多业务信息,这个后面会细讲。


  1. 可制造,为什么不用UUID?


互联网系统上可用性永远是优先指标。但由于分布式系统的脆弱,网络不稳定或者底层存储系统的不可用,业务系统随时面临着失败。为了给前端更友好的响应,我们需要能尽量容忍失败。比如在存储失败时,可能需要临时导出请求供后续处理,而后续处理时已经离开了当时的时间点,顺序跟其他系统错开了。我们需要制造出这样的ID 以便系统好像一直正常运行一样,可制造的 ID 让你可以控制生产日期(汗,有点儿假冒伪劣的意思了),然后继续下面的处理。


另一个重要场景就是数据清洗。这个属于较少遇到,但并不罕见的情况,可能是原来 ID 设计的不合理,也可能由于底层存储的改变,都可能出现。这样一个可制造的 ID 就会带来很多操作层面的便利。


这也是我们不用 UUID 的一个原因。UUID 标准可以保证在某时某地生成,但如果要控制生成一个特定时间的 UUID,可能需要底层库的改动。经验告诉我们,能在上层解决的问题不要透到下层,这种库的维护成本是非常高的。


设计细节UUID 就不说了, 其他公开出来的这里说下SnowFlake、Weibo以及 Ticktick 的设计。


  1. SnowFlake41bit留给毫秒时间,10bit给MachineID,也就是机器要预先配置,剩下12位留给Sequence。代码虽然露出来了,但其实已经不可用了,据说是内部改造中。


  1. Weibo微博使用了秒级的时间,用了30bit,Sequence 用了15位,理论上可以搞定3.2w/s的速度。用4bit来区分IDC,也就是可以支持16个 IDC,对于核心机房来说够了。剩下的有2bit 用来区分业务,由于当前发号服务是机房中心式的,1bit 来区分热备。是的,也没有用满64bit。


  1. Ticktick也就是当前在环信系统里要用到的。使用了30bit 的秒级时间,20bit 给Sequence。这里是有个考虑,第一版实现还是希望到毫秒级,所以20bit 的前10bit给了毫秒来用,剩下10bit给 Sequence。等到峰值提高的时候可以暂时回到秒级。


前面说到的三十年问题,因此我在高位留了2bit 做 Version,或者到时候改造使用更长字节数,用第一位来标识不同 ID,或者可以把这2bit 挪给时间用,可以给系统改造留出一定的时间。


剩下的10bit 留给 MachineID,也就是说当前 ID 生成可以直接内嵌在业务服务中,最多支持千级别的服务器数量。最后有2bit 做Tag 用,可能区分群消息和单聊消息。同时你也看出,这个 ID 最多支持一天10亿消息,也是怕系统增速太快,这2bit 可以挪给 Sequence,可以支持40亿级别消息量,或者结合前面的版本支持到百亿级别。


另外表如果使用数据库自增ID就存在一些问题:


  • id的规律性太明显


  • 受单表数据量的限制


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


场景分析二:随着我们商城规模越来越大,mysql 的单表的容量不宜超过500W,数据量过大之后,我们要进行拆库拆表,但拆分表了之后,他们从逻辑上讲他们是同一张表,所以他们的id是不能一样的, 于是乎我们需要保证id的唯一性。


全局ID生成器,是一种在分布式系统下用来生成 全局唯一 ID的工具,一般要满足下列特性:



为了增加ID的安全性,我们可以不直接使用Redis自增的数值,而是拼接一些其它信息:



成部分:符号位: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.自增长 (每天一个key)
        long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);
        // 3.拼接并返回
        return timestamp << COUNT_BITS | count; 
    }
}


除了 redis 之外,还有 UUID 、雪花算法 等方式可以生成全局唯一 id。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
4月前
|
缓存 负载均衡 NoSQL
Redis系列学习文章分享---第十四篇(Redis多级缓存--封装Http请求+向tomcat发送http请求+根据商品id对tomcat集群负载均衡)
Redis系列学习文章分享---第十四篇(Redis多级缓存--封装Http请求+向tomcat发送http请求+根据商品id对tomcat集群负载均衡)
73 1
|
4月前
|
NoSQL Redis
Redis系列学习文章分享---第五篇(Redis实战篇--优惠券秒杀,全局唯一id 添加优惠券 实现秒杀下单 库存超卖问题分析 乐观锁解决超卖 实现一人一单功能 集群下的线程并发安全问题)
Redis系列学习文章分享---第五篇(Redis实战篇--优惠券秒杀,全局唯一id 添加优惠券 实现秒杀下单 库存超卖问题分析 乐观锁解决超卖 实现一人一单功能 集群下的线程并发安全问题)
105 0
|
5月前
|
存储 数据采集 NoSQL
Redis入门到通过之Redis实现全局唯一id
Redis入门到通过之Redis实现全局唯一id
106 0
|
5月前
|
NoSQL 算法 Java
【Redis】4、全局唯一 ID生成、单机(非分布式)情况下的秒杀和一人一单
【Redis】4、全局唯一 ID生成、单机(非分布式)情况下的秒杀和一人一单
138 0
|
5月前
|
存储 监控 负载均衡
深入Redis Streams:解密神秘的消息ID
深入Redis Streams:解密神秘的消息ID
119 0
|
11月前
|
消息中间件 存储 NoSQL
阿里云国际站代理商:使用Redis实现一个分布式的全局ID怎么操作?
阿里云国际站代理商:使用Redis实现一个分布式的全局ID怎么操作?Redis(Remote Dictionary Server)是一款基于内存的高性能键值对(Key-Value)存储系统。它支持多种数据结构,如字符串、整数、浮点数等,具有高速读写、持久化、分布式等特点。在很多场景下,Redis可以作为数据库、缓存、消息队列等多种应用的数据存储方案。本文将介绍如何使用Redis实现一个分布式的全局ID生成器。
|
NoSQL 关系型数据库 MySQL
基于Redis实现全局唯一Id
基于Redis 的INCR 命令生成分布式全局唯一id。基于redis实现全局唯一ID,性能还是非常高的,并且耗时非常短的。
|
NoSQL 算法 Java
高并发下分布式ID各个的解决方案以及redis集群分布式ID代码实现
高并发下分布式ID各个的解决方案以及redis集群分布式ID代码实现
高并发下分布式ID各个的解决方案以及redis集群分布式ID代码实现
|
NoSQL 安全 Java
分布式唯一ID系列(4)——Redis集群实现的分布式ID适合做分布式ID吗
首先把我用Redis实现分布式Id的最终项目地址列出来: https://github.com/maqiankun/distributed-id-redis-generator 关于Redis集群生成分布式ID,这里要先了解redis使用lua脚本的时候的EVAL,EVALSHA命令: https://www.
2881 0
|
NoSQL Redis
分布式Id - redis方式
本篇分享内容是关于生成分布式Id的其中之一方案,除了redis方案之外还有如:数据库,雪花算法,mogodb(object_id也是数据库)等方案,对于redis来说是我们常用并接触比较多的,因此主要谈谈结合redis生成分布式id方案。
5357 0