分布式id解决什么问题 分布式唯一ID



文章插图
分布式id解决什么问题 分布式唯一ID

文章插图

【分布式id解决什么问题 分布式唯一ID】在分布式系统中,经常需要对大量的数据、消息、http请求等进行唯一标识,例如链路追踪traceId、身份标识号、订单流水号、操作记录流水号、优惠券id等等 。
这个时候数据库自增主键已经不能满足需求,需要一个能够生成分布式ID的系统 。
分布式ID的特性全局唯一 。不能出现重复的ID,这是最基本的要求 。递增 。递增有利于关系数据库索引性能 。除了常见的连续递增,如1001,1002,1003等等,分布式ID还存在趋势递增的形式,即保证下一个ID大于上一个ID但不连续 。这样的好处可以防止关键信息被泄露,例如toc业务中暴露给用户的ID,可能会暴露用户数量 。(订单id同理)高可用 。为多个服务提供ID服务,一旦宕机,会造成严重影响 。好接入 。秉着拿来即用的设计原则,接入文档要尽可能的简单 。高性能:必须要在压测下表现良好,如果达不到要求则在高并发环境下会导致系统瘫痪 。灵活多变:每个业务场景对ID的要求也各不相同,ID生成要做到灵活多变可配置,尽可能多的满足需求 。解决方案1. UUID
UUID是Universally Unique Identifier的缩写,包含32个16进制数字,以连字号分为五段,形式为8-4-4-4-12包含36个字符的字符串,例如:321dsa13-das2-d231-gfdd-213as8asd899
UUID经由一定的算法机器生成,为了保证UUID的唯一性,规范定义了包括网卡MAC地址、时间戳、名字空间、随机或伪随机数、时序等元素,以及从这些元素生成UUID的算法 。
优点:
性能非常高,本地生成,没有网络消耗 。生成简单,没有高可用风险 。有利于信息安全,因为可读性差,无规律 。
缺点:
太长,不易于存储 。无序,对MySQL索引不利,在InnoDB中,UUID的无序性可能会引起数据位置频繁变动,严重影响性能 。UUID不能标识业务含义,可读性差 。2. 数据库自增 ID
利用数据库自增ID的特性来生成,如MySQL的auto_increment 。其优点是数字类型,并且可以自增 。当然缺点就是并发场景下的性能瓶颈 。
优点:
简单,利用数据库自有功能实现 。ID严格连续自增,可以实现一些对ID有特殊要求的业务 。
缺点:
有重复发号的风险,例如MySQL数据库主从切换的场景 。发号性能限制于数据库性能 。强依赖数据库,当数据库异常时整个系统不可用 。
进一步优化:放弃主从复制的高可用架构,采用多主架构 。每个主库设置不同的起始值和相同的步长,保证了号段的隔离 。
3. Redis
Redis中的incr命令,可以实现原子自增 。相比较数据库而言,Redis可支撑的并发量非常高,性能好 。
但需要考虑下面两种情况造成的数据不一致问题:
宕机后重启恢复但存在未及时初始化 。主从切换,主从数据同步延迟 。
优点:
简单,自有能力 。高并发环境下性能好,优于数据库 。
缺点:
可能会重复发号 。需要保障Redis服务的高可用 。4. Zookeeper 实现
使用ZooKeeper作为分段节点协调工具,每台服务器首先从Zookeeper 获取一段号码,如[1,1000]的ID,此时Zookeeper上保存最大值 1000,每次获取的时候都会进行判断,如果ID <=1000,则更新本地的当前值,如果为1001,则会将Zookeeper 上的最大值更新至2000,本地缓存段更新为1001-2000,更新的时候使用分布式锁来实现 。(相当于用Zookeeper实现了基于数据库的号段模式)
优点:
效率高 。
缺点:
维护成本较高,不能同时满足多个系统对ID的需求,不够灵活 。
5、基于数据库的号段模式
号段模式的思想是客户端每次从数据库中取出一批ID供程序使用,从表中获取本次ID值的范围,如[1,1000],然后客户端将申请的号段[1,1000]加载到内存 。表结构参考如下:
CREATE TABLE id_generator (id int(10) NOT NULL,max_id bigint(20) NOT NULL COMMENT '当前最大id',step int(20) NOT NULL COMMENT '号段的布长',biz_typeint(20) NOT NULL COMMENT '业务类型',version int(20) NOT NULL COMMENT '乐观锁版本号',PRIMARY KEY (`id`))等这批号段ID用完,再次向数据库申请新号段,对max_id字段做一次update操作(update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX),update成功则说明新号段获取成功,新的号段范围是(max_id ,max_id +step]
进一步优化:
在号段消耗一半的时候,提前预留下一段号段 。将预留号段时机提前,减少阻塞发生概率 。一般称此为双Buffer机制 。不同业务可以设置不同的生成规则 。
5.雪花算法
雪花算法(Snowflake)是twitter公司内部分布式项目采用的ID生成算法,开源后广受国内大厂的好评,在该算法影响下各大公司相继开发出各具特色的分布式生成器 。
雪花算法,不依赖其它系统或数据库,以服务的方式部署,供其它服务调用,稳定性高,生成 ID 的性能也非常高 。
给每台机器分配一个唯一标识,然后通过下面的结构实现全局唯一ID:
1位 。未使用(二进制中最高位为1的都是负数,所以这个最高位固定是0)41位 。毫秒级时间(41 位的长度可以使用 69 年)10位 。包含5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点)12位 。最后12位是毫秒内的计数(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)
由于在Java中64bit的整数是long类型,所以在Java中SnowFlake算法生成的id就是long来存储的 。
优点:
生成性能高 。整体上按照时间自增排序 。
缺点:
强依赖机器时钟,如果时钟回拨,可能会导致服务异常 。不能同时满足多个系统对ID的需求,不够灵活 。在单机上是递增的,但是由于涉及到分布式环境,每台机器上的时钟不可能完全同步,会出现不是全局递增的情况 。6.Tinyid
Tinyid是滴滴开源的分布式ID生成方案,开源地址见于参考文档1,只提供基于号段模式来生成ID(加入了双Buffer机制) 。
7.Uidgenerator
UidGenerator是由百度技术部开发,开源地址见于参考文档2,基于Snowflake实现的优化算法 。借用未来时间和双Buffer来解决时间回拨与生成性能等问题,同时结合MySQL进行ID分配 。
8.Leaf
Leaf是美团开源的分布式ID生成方案,开源地址见于参考文档3 。提供两种生成的ID的方式:雪花算法模式和号段模式 。可通过配置文件来指定 。
Leaf的雪花算法模式依赖于ZooKeeper,其workId的生成策略是基于ZooKeeper的顺序ID来生成的;号段模式也是基于数据库的号段模式+双Buffer机制实现的 。