美文网首页程序员小天地
分布式id生成器设计分享

分布式id生成器设计分享

作者: 小草莓子桑 | 来源:发表于2021-06-24 22:38 被阅读0次

分布式环境下,大家可能经常会遇到需要一个全局唯一的id的需求,常见的方案雪花算法(SnowFlake)大家应该也很熟悉了,今天来分享一个分布式id生成器的设计思路,代码因为公司原因,就不贴出来了

先来分析一下分布式id生成器的应用场景

1.数据库分表分库后的主键

  • 业务数据库由于量级问题分库分表后,需要一个分布式主键id器,来生成主键,保证数据的主键id唯一
  • 这种场景下,生成的id最好基于时间自增,因为数据主键一般使用聚簇索引,基于时间自增的主键,可以避免随机IO导致的数据库写入性能低下

2.服务调用链路追踪的traceId

  • 在目前微服务架构流行的情况下,有很多分布式追踪方案应用而生,来追溯监控整个服务调用链路,来排查问题或者查看链路各个节点的响应时间,很多方案中,都会生成一个唯一id,作为traceId来追踪整个服务调用链
  • 这种场景下,因为要记录追踪每一次调用,生成的id除了要求唯一之外,还要求生成的效率高、吞吐量大

再来说一下我们这次设计的背景

我们设计分布式id生成器的背景

  • 1.随着业务的快速发展,我们一个服务的调用方越来越多,需要做水平扩容来提高服务的吞吐量;
  • 2.该服务中,分布式id生成逻辑耦合在服务逻辑代码中,目前分布式id生成的方案是基于snowflake雪花算法来生成;
  • 3.id为64bit位的long类型,算法只使用了3位bit位作为机器码,所以导致只能扩展到8个节点,严重制约了我们服务的水平扩展能力;
  • 4.而且每个节点的机器码是存储到配置文件中的,导致每一个版本上线时候,都需要根据要上线的节点,修改配置文件的机器码,造成了服务上线流程麻烦,潜在风险很大,并且没有办法实现自动扩容(因为新加节点,要修改配置文件中的机器码)

基于这个背景,我们确立了本次设计的目标

  • 1.把分布式id生成器单抽取出来,不和业务服务耦合,作为一个公共工具使用,支持多个服务的分布式id生成需求
  • 2.修改生成id的算法,接触节点的扩容限制
  • 3.机器码的配置从本地配置文件中提取到一个分布式配置中心,来简化上线流程,降低上线扩容时候的风险点。

分布式id技术选型

说一下分布式id的常用技术选型

UUID

UUID
标准格式说明:
  • UUID是128位的bit数组,格式化成36位字符串
  • 使用其8-4-4-4-12格式来分割32个16进制字符串
  • 目前为止,业界一共有5种方式生成UUID,这里就不详细说了,感兴趣的朋友可以查一下
优点
  • 本地算法生成,没有额外的网络请求开销,性能好
  • 能作为时间、空间上的唯一,而且接入成本低
缺点:
  • 如果使用作为数据库主键,36长度的字符串作为主键,占用物理空间,还占用大量的索引页(聚簇索引,辅助索引)的存储空间
  • 使用UUID作为主键,生成ID比较离散,会造成随机IO,导致的数据库写入性能低下
使用场景
  • 适用于非数据库主键场景,如幂等id、链路traceId、日志id等

基于mysql、redis等存储的自增序列

  • oracle中有序列,但是我基本没用过oracle,这里就拿mysql做例子了
mysql实现:
  • mysql实现,主要是利用自增主键auto_increment来实现,生成全局唯一id
  • 在分布式系统中,使用一个共用的数据库,创建一张表
  • 表的主键是自增式主键
  • 每次需要一个全局唯一id时候,在该表中插入一条数据,返回插入成功数据的主键来作为全局唯一的id
redis实现
  • redis的实现,主要依赖于redis单线程,使用redis的原子命令incr就可以生成一个全局唯一的id
  • 在分布式系统中,使用一个共用的redis,共用一个主键生成key
  • 每次使用命令incr就可以生成一个全局唯一的id
优点
  • 这里不对比mysql实现和redis实现了
  • 实现简单,利用存储各自的特性就可以实现,接入成本小
  • 而且主键是可以保证全局唯一并且是严格自增的
缺点
  • 利用数据存储系统实现的缺点都差不多
  • 性能严重受存储系统的性能制约,以我们公司的存储性能为例,mysql健康的qps在8千左右,redis健康qps在 8万左右
  • 扩展性差,难以通过数据分片实现扩展
优化方案
  • 实现数据切片,增加多个master节点,通过设计各个节点之间自增的数字不同;来保证master之间不能生成重复ID
  • 每个节点可以批量获取多个ID,减少与数据库的交互,提高性能
  • 但是多个master节点,太耗资源,基本很少人使用该方案(我见过一个toB的项目使用了)

基于zookeeper实现

实现思路一
  • 使用znode数据版本来生成序列号,生成32位和64位的数据版本
  • 客户端以这个版本号来作为唯一的序列号
  • 每当节点数据变化的时候dataversion的版本号会自增1,可以生成全局唯一的32位id
  • 每当修改数据,对应的mzxid(修改事务id)也会自增,可以生成全局唯一的64位id
实现思路二
  • 创建一个持久化节点,节点的数据为计数器的值,可以保证多个节点下计数器可以生成全局唯一的id
优点
  • 接入成本低
  • id可以保证严格全局唯一
  • 整个系统可以利用zk的高可靠性
缺点
  • zk性能上不上,还不如利用redis实现的性能好

sonwflake

  • Twitter在把存储系统从Mysql迁移到Cassandra的过程中,由于Cassandra没有顺序ID生成机制,于是自己开发一套全局唯一id生成算法,Snowflake 雪花算法,根据Twitter的业务需求,Sonwflake系统生成64位的ID由下面三部分组成:
  • 41位的时间戳(精准到毫秒,41位的长度可以使用69年)
  • 10位的机器码(10位的长度可以最多支持部署1024个节点)
  • 12位的计数顺序号(12位的计数器顺序号支持每个节点每毫秒产生4096个序列号)
雪花算法.png
优点
  • 因为是本地算法实现的,没有额外的网络开销,所以性能高
  • 时间戳在高位,自增序列号在低位,保证唯一的同时,又可以保证基于时间上是严格递增的
  • 不依赖于外部存储系统,没有外部依赖的限制
缺点
  • 因为高位是时间戳,生成时间戳的过程依赖本地服务的时钟系统
  • 如果服务器发生时钟回拨,基于本地时钟系统获取的时间戳可能会造成id重复

我们最后采用了sonwflake雪花算法,在结合我们的业务背景做了一些改动,实现了一个分布式id服务,供团队内的业务使用,这里说一下关键的改动点吧

为了解决机器码本地配置文件存放的问题,我们引入了zk来维护整个分布式id服务各个节点的机器码

  • 每个节点启动时,先获取机器id,连接zk
  • 判断是否为新增的节点
  • 如果是新增的节点,则生成一个唯一的机器码
  • 并且持久化到zk中
  • 并吧唯一机器码返回给服务节点,服务节点持久化到服务本地
  • 如果是已经注册过的节点(节点重启)
  • 直接获取生成过的机器码返回给服务节点,服务节点持久化到服务本地

为了减少时钟回拨的影响,利用zk来实现了一个时间校验器

  • 定时进行时钟校验
  • 服务节点连接zk,把自己的当前时间戳同步到zk,在获取其他节点,进行比较
  • 如果有异常,就直接报警处理

相关文章

网友评论

    本文标题:分布式id生成器设计分享

    本文链接:https://www.haomeiwen.com/subject/fvavlktx.html