技术分享 分布式全局唯一ID的实现

steve · 2019-06-03 09:57:09 · 热度: 39

本文转载自: https://www.cnblogs.com/Tiancheng-Duan/p/10962704.html

分布式全局唯一ID的实现

前言

上周末考完试,这周正好把工作整理整理,然后也把之前的一些素材,整理一番,也当自己再学习一番。
一方面正好最近看到几篇这方面的文章,另一方面也是正好工作上有所涉及,所以决定写一篇这样的文章。
先是简单介绍概念和现有解决方案,然后是我对这些方案的总结,最后是我自己项目的解决思路。

概念

在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识。

如在金融、电商、支付、等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的自增ID显然不能满足需求,此时一个能够生成全局唯一ID的系统是非常必要的。

特点:

  • 全局唯一性(核心):作为唯一标识,不可以出现重复ID
  • 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数据,在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
  • 单调递增:保证下一个ID一定大于上一个ID,例如事务版本号、IM增量消息、 排序 等特殊需求。
  • 信息安全:如果ID是连续的,恶意用户的扒取工作就非常容易做了,直接按照顺序下载指定URL即可;如果是订单号就更危险了,竞对可以直接知道我们一天的单量。所以在一些应用场景下,会需要ID无规则、不规则。
    同时除了对ID号码自身的要求,业务还对ID号生成系统的可用性要求极高,想象一下,如果ID生成系统瘫痪,这就会带来一场灾难。

运用场景:

分布式全局唯一ID(数据库的分库分表后需要有一个唯一ID来标识一条数据或消息;特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识;MQ中消息的高可用性(确认消息是否发送成功,是否已发送等)等)
其实分布式全局ID是一个比较复杂,重要的分布式问题(什么问题涉及真正的分布式,高并发后都会比较复杂)。常见解决方案有UUID,Snowflake,Flicker,Redis,Zookeeper,Leaf等。

实现方案:

UUID(此处用的Version1:共五个版本,Version1是基于时间的)

生成一个32位16进制字符串(16字节的128位数据,通常以32位长度的字符串表示)(结合机器识别码(全局唯一的IEEE机器识别号,如果有网卡,从网卡MAC地址获得,没有网卡以其他方式获得),当前时间,一个随机数)。

优点:

  • 性能好;
  • 扩展性高;
  • 本地生成;
  • 无网络消耗;
  • 不需要考虑性能瓶颈;
  • 不需要提前商定,各自为政,但绝对不会冲突

缺点:

  • 无法保证趋势递增(由于数据库 MySQL 的InnoDB采用聚簇索引,有序的ID可以保证写入速度);
  • UUID过长(消耗内存,带宽等。更重要的是如果存储在数据库中,作为主键建立索引效率低)

适用场景:

不需要考虑空间占用,不需要生成有递增趋势的ID,且不在MySQL中存储。

Snowflake

Twitter开源,生成一个64bit(0和1)字符串(1bit不用,41bit表示存储时间戳,10bit表示工作机器id(5位数据标示位,5位机器标识位),12bit序列号)

结构:

  • 首位符号位:因为ID一般为正数,该值为0.
  • 41位时间戳(毫秒级):时间戳并不是当前时间戳,而是存储时间戳的差值(当前时间戳-起始时间戳(起始时间戳需要程序指定),理论可以适用(1<<41)/(1000x60x60x24x365),69年。
  • 10位数据机器位(说白了就是逻辑分片ID,具体实现和机器本身无关系):包括5位数据标识位和5位机器标识位(比如5位机房ID,5位机器ID),理论最多可以部署节点位:1<<10=1024。
  • 12位毫秒内的序列:同一节点,同一时刻(同一毫秒内)最多生成ID数1<<12=4096。

最后生成64位Long型数值(这里指,一般Long数据就是64位bit的)。

优点:

  • 趋势递增,且按照时间有序;
  • 性能高,稳定性高,不依赖数据库等第三方系统;
  • 可以按照自身业务特性灵活分配bit位(比如机器位改为15bit,序列位改为7bit)。

缺点:

  • 依赖机器时钟(虽然UUID也根据当前时间,但其非时间部分波动太大了(重新组织措辞)),时钟回拨会造成暂不可用或重复发号(分布式系统中,每台机器上的时钟不可能完全同步。在同步各个服务器的时间时,有一定几率发生时钟回拨(时间超了,往回拨))

适用场景:

要求高性能,可以不连续,数据类型为long型。

Flicker

主要思路是涉及单独的库表,利用数据库的自增ID+replace_into,来生成全局ID。

前置补充:

replace into跟insert功能类似,不同点在于:replace into首先尝试插入数据列表中,如果发现表中已经有此行数据(根据主键或唯一索引判断)则先删除,再插入。否则直接插入新数据。

建表:
    create table t_global_id(
            id bigint(20) unsigned not null auto_increment,
            stub char(1) not null default '',
            primary key (id),
            unique key stub (stub)
    ) engine=MyISAM;
(stub:票根,对应需要生成ID的业务方编码,可以是项目名,表名,甚至是服务器IP地址。
  MyISAM(MYSQL5.5.8前默认数据库存储引擎,5.5.8及之后默认存储引擎为InnoDB):(此处应当有MyISAM与InnoDB引擎的区别,乃至其他引擎)基于ISAM类型。不是事务安全(没有事务隔离??),不支持外键,没有行级锁。如果执行大量的select,建议MyISAM。

获取数据:
    # 每次业务可以使用以下 SQL 读写MySQL得到ID号
    replace into t_golbal_id(stub) values('a');
    select last_insert_id();

扩展:为解决单点问题,启用多台服务器,如MySQL,利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增(如通过设置起始值与步长,生成奇偶数ID)

优点:

  • 非常简单,充分利用了数据库系统的功能实现,成本小,有DBA专业维护;
  • ID号单调自增,可以实现一些对ID有特殊要求的业务。

缺点:

  • 强依赖DB,当DB异常时,整个系统不可用,属于致命问题(配置主从复制可以尽可能地增加可用性,但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能导致重复发号);
  • 水平扩展困难(定义好了起始值,步长和机器台数之后,如果要添加机器就比较麻烦(为什么我想到了 REDIS 的哈希一致原理));
  • ID发号性能瓶颈限制在单台MySQL的读写性能。

适用场景:

数据量不大,并发量不大。

Redis

由于Redis的所有命令是单线程的,所以可以利用Redis的原子操作INCR和INCRBY,来生成全局唯一的ID。

扩展:

可以通过集群来提升吞吐量(可以通过为不同Redis节点设置不同的初始值并同意步长,从而利用Redis生成唯一且趋势递增的ID)(其实这个方法和Flicker一致,只是利用到了Redis的一些特性,如原子操作,内存数据库读写快等)(Incrby:将key中储存的数字加上指定的增量值。这是一个“INCR AND GET”的原子操作,业务方可以定义一个自己的key值,通过INCR命令来获取对应的ID)

优点:

不依赖数据库,灵活方便,且性能优于基于数据库的Flicker方案。

缺点:

  • 扩展性低,Redis集群需要设置号初始值与步长(与Flicker方案一样);
  • Redis宕机可能生成重复的ID;如果系统中没有Redis,还需要引入新的组件,增加系统复杂度;
  • 需要编码和配置的工作量比较大。

适用场景:

Redis集群高可用,并发量高。

举例:

利用Redis来生成每天从0开始的流水号。如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key,适用INCR进行累加。

zookeeper

通过其znode数据版本来生成序列号,可以生成32位和64位的数据版本号,客户端可以使用这个版本号来作为唯一的序列号。

小结:很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper,并且是多步调用API,如果在竞争较大的情况下,需要考虑使用分布式锁。因此,性能在高并发的分布式环境下,也不甚理想。

Leaf

美团的Leaf分布式ID生成系统,在Flicker策略与Snowflake算法的基础上做了两套优化的方案:Leaf-segment数据库方案(相比Flicker方案每次都要读取数据库,该方案改用proxy server批量获取,且做了双buffer的优化)与Leaf-snowflake方案(主要针对时钟回拨问题做了特殊处理。若发生时钟回拨则拒绝发号,并进行告警)。

MongDB objectID

ObjectID可以算作和snowflake类似方法,通过”时间+机器码+pid+inc”共12个字节,通过4+3+2+3的方式,最终标识一个24长度的十六进制字符。

理论总结

其实除了上述方案外,还有ins等的方案,但总的来看,方案主要分为两种:第一有中心(如数据库,包括MYSQL,REDIS等),其中可以会利用事先的预约来实现集群(起始步长)。第二种就是无中心,通过生成足够散落的数据,来确保无冲突(如UUID等)。站在这两个方向上,来看上述方案的利弊就方便多了。

中心化方案:

优点:

  • 数据长度相对小一些;
  • 数据可以实现自增趋势等。

缺点:

  • 并发瓶颈处理;
  • 集群需要实现约定;横向扩展困难(当然有的方案看起来后两者没有那么问题,是因为,这些方案利用其技术特性,早就一定程度上解决了这些问题,如Redis的横向扩展等)。

非中心化方案:

优点:

  • 实现简单(因为不需要与其他节点存在这方面的约定,耦合);
  • 不会出现中心节点带来的性能瓶颈;
  • 扩展性较高(扩展的局限往往集中于数据的离散问题)。

缺点:

  • 数据长度较长(毕竟就是通过这一特性来实现无冲突的);
  • 无法实现数据的自增长(毕竟是随机的);
  • 依赖数据生成方案的优劣(数据生成方案的优劣会全盘接收,但可以推成出新)。

体悟:

技术是无穷无尽的,我们不仅需要看到其中体现的思想与原则,在学习新技术或方案时,需要明确其中一些特性,优缺点的来源,从而进行有效的总结归纳。

应用角度来说:(一方面想要标示符短,便于处理与存储,另一方面想要足够大,而不会产生冲突。呵呵)。最理想就是追求从0开始,每个标示符都被使用,且不重复,而且不用担心并发。呵呵。完全应该根据当前业务场景来选择,毕竟业务场景在当前是确定的。如果业务变动较大(比如发展初期,业务增长很快),那就需要考虑扩展性,便于日后进行该模块的更新与技术方案的替换实现(避免一个系统开发一年,用不到一年,那就尴尬了))。

个人经验

我曾经做过一个“工业物联网”系统,该系统系统是分为三个子系统:终端服务器(用于收集终端传感器数据);企业中控服务器(接收来自多个终端服务器的数据,进行综合查看与控制);云平台服务器(提供上云)。其中就涉及多个终端服务器的传感器数据辨识问题,这里以倾斜传感器数据为例。简述不同终端服务器的倾斜数据的如何实现全局唯一标识。

以企业中控服务器的数据库作为统一的数据标识来源

简单说,就是终端服务器发送一个数据到企业中控室,企业中控服务器就将该数据保存到数据库中,那么每个数据在企业中控服务器数据库中都有唯一的ID,并且保持了自增。

优点是实现简单,只需要做好数据收发,与数据的插入工作即可。唯一需要注意的是数据库插入时注意资源互斥,防止出现数据插入异常问题(Springframework生成的Bean默认时单例的)。

缺点是需要实时收发数据,防止数据丢失,数据积压,数据的create_time异常等问题。

以UUID等方式生成数据的全局唯一标识

简单说,就是终端服务器要发送的数据赋予UUID这样的ID,来确保全局唯一。这样终端服务器就可以和中控服务器保持同样且不冲突的ID了。数据的生成是实现在终端服务器的,而中控服务器只是作为数据的保存与调用(通过统一ID调用)。

优点是不需要数据的实时收发,避免系统在弱网络情况下出现各类异常。

缺点是数据的ID过长,并且无法保持自增。并且在某种程度上带来了数据复杂度,从而提高了系统复杂度。

落地方案

由于实际业务的需求,如弱网络,数据交互频率跨度大等情况。最终我的实现是先由终端服务器在启动之初,在企业中控服务器注册TerminalId,作为不同终端服务器的标识。不同终端服务器接收与保存数据时,都会在每条数据中插入TerminalId,便于企业中控服务器的识别。当然,具体实现当中还有一些细节。如终端服务器在注册时由于网络等情况注册失败,会先建立一个类似UUID的TerminalId来先保存监测数据。当注册成功时(系统会根据TerminalId的长度等特性来判断是否注册失败,是否需要重新注册),会重新修改所有数据的TerminalId,再允许数据上传。

优点是确保了数据在弱网络情况下的正确性,并且实现了自动注册等通用模块的实现。

缺点是最终数据插入企业中控服务器数据库时,并没有严格实现数据符合实际时间的增长(如某终端服务器由于网络等情况没法发送数据,等待一段时间后发送了这段时间堆积的数据),但保持了总体增长的趋势。

总结

IT没有银弹,我们要做的是多去了解现有的技术方案,再产生符合自己需求的技术方案。因为不同的技术方案都因为其使用场景有着各自的特点,而我们需要了解各种特点的技术来源(是什么技术造就了这一特点,或者说是什么架构造就了这一特点等),从而构建出最符合自己需求的技术方案。

没有最好,只有最适合。

附录

参考

阿里P8架构师谈:分布式系统全局唯一ID简介、特点、5种生成方式

分布式ID生成策略

分布式全局唯一ID生成策略

本文转载自: https://www.cnblogs.com/Tiancheng-Duan/p/10962704.html

猜你喜欢:
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册