分布式锁的实现方案探讨

目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项。”所以,很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。

在很多场景中,我们为了保证数据的最终一致性,需要很多的技术方案来支持,比如分布式事务、分布式锁等。有的时候,我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中,Java中其实提供了很多并发处理相关的API,但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。

针对分布式锁的实现,目前比较常用的有以下几种方案:

a.基于数据库实现分布式锁
b.基于缓存(redis,memcached,tair)实现分布式锁
c.基于Zookeeper实现分布式锁

在分析这几种实现方案之前我们先来想一下,我们需要的分布式锁应该是怎么样的?(这里以方法锁为例,资源锁同理)

a.可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行。
b.这把锁要是一把可重入锁(避免死锁)
c.这把锁最好是一把阻塞锁(根据业务需求考虑要不要这条)
d.有高可用的获取锁和释放锁功能
e.获取锁和释放锁的性能要好


基于数据库实现分布式锁

基于数据库表

要实现分布式锁,最简单的方式可能就是直接创建一张锁表,然后通过操作该表中的数据来实现了。

当我们要锁住某个方法或资源时,我们就在该表中增加一条记录,想要释放锁的时候就删除这条记录。

创建这样一张数据库表:

当我们想要锁住某个方法时,执行以下SQL:

因为我们对method_name做了唯一性约束,这里如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就可以认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。

当方法执行完毕之后,想要释放锁的话,需要执行以下Sql:

上面这种简单的实现有以下几个问题:

1、这把锁强依赖数据库的可用性,数据库是一个单点,一旦数据库挂掉,会导致业务系统不可用。

2、这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在数据库中,其他线程无法再获得到锁。

3、这把锁只能是非阻塞的,因为数据的insert操作,一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列,要想再次获得锁就要再次触发获得锁操作。

4、这把锁是非重入的,同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

当然,我们也可以有其他方式解决上面的问题。

  • 数据库是单点?搞两个数据库,数据之前双向同步。一旦挂掉快速切换到备库上。
  • 没有失效时间?只要做一个定时任务,每隔一定时间把数据库中的超时数据清理一遍。
  • 非阻塞的?搞一个while循环,直到insert成功再返回成功。
  • 非重入的?在数据库表中加个字段,记录当前获得锁的机器的主机信息和线程信息,那么下次再获取锁的时候先查询数据库,如果当前机器的主机信息和线程信息在数据库可以查到的话,直接把锁分配给他就可以了。

基于数据库排他锁

除了可以通过增删操作数据表中的记录以外,其实还可以借助数据中自带的锁来实现分布式的锁。

我们还用刚刚创建的那张数据库表。可以通过数据库的排他锁来实现分布式锁。 基于MySql的InnoDB引擎,可以使用以下方法来实现加锁操作:

在查询语句后面增加for update,数据库会在查询过程中给数据库表增加排他锁(这里再多提一句,InnoDB引擎在加锁的时候,只有通过索引进行检索的时候才会使用行级锁,否则会使用表级锁。这里我们希望使用行级锁,就要给method_name添加索引,值得注意的是,这个索引一定要创建成唯一索引,否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上。)。当某条记录被加上排他锁之后,其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁,当获取到锁之后,可以执行方法的业务逻辑,执行完方法之后,再通过以下方法解锁:

通过connection.commit()操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

  • 阻塞锁? for update语句会在执行成功后立即返回,在执行失败时一直处于阻塞状态,直到成功。
  • 锁定之后服务宕机,无法释放?使用这种方式,服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点和可重入问题。

这里还可能存在另外一个问题,虽然我们对method_name 使用了唯一索引,并且显示使用for update来使用行级锁。但是,MySql会对查询进行优化,即便在条件中使用了索引字段,但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的,如果 MySQL 认为全表扫效率更高,比如对一些很小的表,它就不会使用索引,这种情况下 InnoDB 将使用表锁,而不是行锁。如果发生这种情况就悲剧了。。。


还有一个问题,就是我们要使用排他锁来进行分布式锁的lock,那么一个排他锁长时间不提交,就会占用数据库连接。一旦类似的连接变得多了,就可能把数据库连接池撑爆

总结

总结一下使用数据库来实现分布式锁的方式,这两种方式都是依赖数据库的一张表,一种是通过表中的记录的存在情况确定当前是否有锁存在,另外一种是通过数据库的排他锁来实现分布式锁。

数据库实现分布式锁的优点

直接借助数据库,容易理解。

数据库实现分布式锁的缺点

会有各种各样的问题,在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销,性能问题需要考虑。

使用数据库的行级锁并不一定靠谱,尤其是当我们的锁表并不大的时候。


基于缓存实现分布式锁

相比较于基于数据库实现分布式锁的方案来说,基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的,可以解决单点问题。

目前有很多成熟的缓存产品,包括Redis,memcached以及我们公司内部的Tair。

这里以Tair为例来分析下使用缓存实现分布式锁的方案。关于Redis和memcached在网络上有很多相关的文章,并且也有一些成熟的框架及算法可以直接使用。

基于Tair的实现分布式锁其实和Redis类似,其中主要的实现方式是使用TairManager.put方法来实现。

以上实现方式同样存在几个问题:

1、这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在tair中,其他线程无法再获得到锁。

2、这把锁只能是非阻塞的,无论成功还是失败都直接返回。

3、这把锁是非重入的,一个线程获得锁之后,在释放锁之前,无法再次获得该锁,因为使用到的key在tair中已经存在。无法再执行put操作。

当然,同样有方式可以解决。

  • 没有失效时间?tair的put方法支持传入失效时间,到达时间之后数据会自动删除。
  • 非阻塞?while重复执行。
  • 非可重入?在一个线程获取到锁之后,把当前主机信息和线程信息保存起来,下次再获取之前先检查自己是不是当前锁的拥有者。

但是,失效时间我设置多长时间为好?如何设置的失效时间太短,方法没等执行完,锁就自动释放了,那么就会产生并发问题。如果设置的时间太长,其他获取锁的线程就可能要平白的多等一段时间。这个问题使用数据库实现分布式锁同样存在


总结

可以使用缓存来代替数据库来实现分布式锁,这个可以提供更好的性能,同时,很多缓存服务都是集群部署的,可以避免单点问题。并且很多缓存服务都提供了可以用来实现分布式锁的方法,比如Tair的put方法,redis的setnx方法等。并且,这些缓存服务也都提供了对数据的过期自动删除的支持,可以直接设置超时时间来控制锁的释放。

使用缓存实现分布式锁的优点

性能好,实现起来较为方便。

使用缓存实现分布式锁的缺点

通过超时时间来控制锁的失效时间并不是十分的靠谱。


基于Zookeeper实现分布式锁

基于zookeeper临时有序节点可以实现的分布式锁。

大致思想即为:每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。 当释放锁的时候,只需将这个瞬时节点删除即可。同时,其可以避免服务宕机导致的锁无法释放,而产生的死锁问题。

来看下Zookeeper能不能解决前面提到的问题。

  • 锁无法释放?使用Zookeeper可以有效的解决锁无法释放的问题,因为在创建锁的时候,客户端会在ZK中创建一个临时节点,一旦客户端获取到锁之后突然挂掉(Session连接断开),那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
  • 非阻塞锁?使用Zookeeper可以实现阻塞的锁,客户端可以通过在ZK中创建顺序节点,并且在节点上绑定监听器,一旦节点有变化,Zookeeper会通知客户端,客户端可以检查自己创建的节点是不是当前所有节点中序号最小的,如果是,那么自己就获取到锁,便可以执行业务逻辑了。
  • 不可重入?使用Zookeeper也可以有效的解决不可重入的问题,客户端在创建节点的时候,把当前客户端的主机信息和线程信息直接写入到节点中,下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样,那么自己直接获取到锁,如果不一样就再创建一个临时的顺序节点,参与排队。
  • 单点问题?使用Zookeeper可以有效的解决单点问题,ZK是集群部署的,只要集群中有半数以上的机器存活,就可以对外提供服务。

可以直接使用zookeeper第三方库Curator客户端,这个客户端中封装了一个可重入的锁服务。

Curator提供的InterProcessMutex是分布式锁的实现。acquire方法用户获取锁,release方法用于释放锁。

使用ZK实现的分布式锁好像完全符合了本文开头我们对一个分布式锁的所有期望。但是,其实并不是,Zookeeper实现的分布式锁其实存在一个缺点,那就是性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中,都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行,然后将数据同不到所有的Follower机器上。

其实,使用Zookeeper也有可能带来并发问题,只是并不常见而已。考虑这样的情况,由于网络抖动,客户端可ZK集群的session连接断了,那么zk以为客户端挂了,就会删除临时节点,这时候其他客户端就可以获取到分布式锁了。就可能产生并发问题。这个问题不常见是因为zk有重试机制,一旦zk集群检测不到客户端的心跳,就会重试,Curator客户端支持多种重试策略。多次重试之后还不行的话才会删除临时节点。(所以,选择一个合适的重试策略也比较重要,要在锁的粒度和并发之间找一个平衡。)


总结

使用Zookeeper实现分布式锁的优点

有效的解决单点问题,不可重入问题,非阻塞问题以及锁无法释放的问题。实现起来较为简单。

使用Zookeeper实现分布式锁的缺点

性能上不如使用缓存实现分布式锁。 需要对ZK的原理有所了解。


三种方案的比较

上面几种方式,哪种方式都无法做到完美。就像CAP一样,在复杂性、可靠性、性能等方面无法同时满足,所以,根据不同的应用场景选择最适合自己的才是王道。

从理解的难易程度角度(从低到高)

数据库 > 缓存 > Zookeeper

从实现的复杂性角度(从低到高)

Zookeeper >= 缓存 > 数据库

从性能角度(从高到低)

缓存 > Zookeeper >= 数据库

从可靠性角度(从高到低)

Zookeeper > 缓存 > 数据库

0

面试题:聊一聊分布式对象存储解决方案

OSS(Object Storage Service)俗称对象存储,主要提供图片、文档、音频、视频等二进制文件的海量存储功能。目前除了公有云提供对象存储服务外,一般私有云比较关心一些开源的分布式对象存储解决方案,本文列举了一些常见的技术方案供参考。

概念普识

块存储

通常SAN(Storage Area Network)结构的产品属于块存储,比如我们常见的硬盘、磁盘阵列等物理盘。

文件存储

一般NAS(Network Attached Storage)产品都是文件级存储,如Ceph的CephFS,另外GFS、HDFS、FastDFS等也属于文件存储。

对象存储

同时兼顾着SAN高速直接访问磁盘特点及NAS的分布式共享特点的一类存储,一般是通过RESTful接口访问。

开源解决方案介绍

Swift

Swift 是 OpenStack 社区核心子项目,是一个弹性可伸缩、高可用的分布式对象存储系统,使用Python语言实现,采用 Apache 2.0 许可协议。

Swift 提供一个基于RESTful HTTP接口的 Object Storage API,用于创建,修改和获取对象和元数据。用户可以使用 Swift 高效、安全且廉价地存储大量数据。Swift 整体架构:

总的来说,企业如果想要建立可扩展的分布式对象存储集群,可以考虑 Swift。

Ceph

Ceph是一种高性能、高可用、可扩展的分布式存储系统,统一的对外提供对象存储、块存储以及文件存储功能,底层使用C/C++语言。

其中对象存储功能支持 2 种接口:

1、兼容S3:提供了对象存储接口,兼容 S3 RESTful 接口的一个大子集。

2、兼容Swift:提供了对象存储接口,兼容 Openstack Swift 接口的一个大子集。

Ceph是一个企业级分布式存储系统,功能强大,不仅可以为企业建立对象存储服务,还可以帮助企业建立自己的云平台,具有广泛的应用场景特别是在云环境下使用广泛。

Minio

Minio是一个企业级、兼容S3接口的对象存储系统。Minio基于 Apache 2.0 许可协议,采用Go语言实现,客户端支持Java、Python、Go等多种语言,是一种轻量级、高并发的开源解决方案,可以作为云存储方案用来保存海量的图片,视频,文档等。

大数据集成方面,Minio支持各种常见的查询计算引擎,比如Spark、Presto、Hive以及Flink等,可以使用这些处理框架查询分析对象数据,此外,Minio支持Parquet,Json、Csv格式等多种文件存储格式,包括压缩与编码。更多特性可以参考官网 地址https://min.io。Minio架构:

Minio主要为人工智能、机器学习而设计,并适用于其他大数据负载。从架构与功能方面考虑,Minio是一个比较好的开源对象存储解决方案。

HBase MOB

这是利用HBase的MOB特性支持对象存储功能。Apache HBase2.0 版本开始支持中等对象存储(Medium Object Storage,简称 MOB),这个特性使得HBase能够非常良好的存储大小在100KB-10M的图片、文档、音频、短视频等二进制数据。

架构如上,HBase MOB的设计类似于HBase + HDFS的方式,中等对象在写入HDFS之前同样是先写入MemStore,但是刷写与其他写入数据不同,MOB数据被刷写到MOB File中,MOB File被存放在特殊的Region中。

MOB特性在Apache HBase 2.0、CDH 5.4.x 或 HDP 2.5.x 及以上版本支持,用户可以基于HBase MOB特性设计自己的对象存储服务。

Hadoop Ozone

Ozone是 Apache Hadoop 的子项目,为了提供分布式、可扩展的对象存储功能,主要是为了弥补HDFS在小文件存储方面的不足之处。Ozone建立在一个高可用、支持块复制的Hadoop分布式数据存储层之上,称为Hadoop Distributed Data Store(HDDS),上层可对接 Spark、Hive 以及 Yarn 等计算调度引擎。但是目前还处于alpha内部测试版本,暂时不建议生产环境中使用。

小结

对象存储主要是解决海量图片、文档、音视频的存储,其中主流的重量级解决方案是Swift与Ceph,它们各有特点,可以参考搜索引擎上的对比,Hadoop生态体系中备受关注的是HBase MOB,另外轻量级的Minio也是一种比较好的选择。MongoDB也提供了大文件存储模块GridFS。建议根据实际情况做技术选型。

0

分布式架构设计里的Eureka与ZooKeeper区别理解

前言

一个系统最重要的是什么?是数据。数据放在哪?数据库里。但是光有数据也不行,还需要程序对数据进行各种增删改查操作。

那各种增删改查操作,最重要的是什么?是数据的安全性、可扩展性和性能。

数据库又分关系型数据库和非关系型数据库。

关系型数据库RDBMS(Relational database management system)MySQL、SQL server、Oracle我们都经常用,其遵循的事务原则是ACID原则(Atomicity:原子性、Consistency:一致性、Isolation:隔离性、Durability:持久性)

非关系型数据库NoSQL(Redis、MongoDB)遵循的原则是CAP原则一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。

分布式系统架构设计

我们在进行分布式架构设计时,关系数据库的很多主要特性却往往无用武之地。

数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求并不高。允许实现最终一致性。

数据库的写实时性和读实时性需求

对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之 后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

对复杂的SQL查询,特别是多表关联查询的需求。

任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

而与之不同的是,NoSQL系统通常注重性能和扩展性,而非事务机制(事务就是强一致性的体现)。

cap原则

CAP理论也就是说在分布式存储系统中,最多只能实现以上两点。而由于当前网络延迟故障会导致丢包等问题,所以我们分区容错性是必须实现的。也就是NoSqL数据库P肯定要有,我们只能在一致性和可用性中进行选择,没有Nosql数据库能同时保证三点。(==>AP 或者 CP)。

提出一个想法,当你面对双十一这种业务处理时,你是选择AP还是CP呢?

个人想法是在面对这种业务处理时,先保证可用性也就是AP原则(服务器不能瘫痪),在过了双十一高峰,再核对数据,保证数据一致性。

Eureka和ZooKeeper的区别

综上,我们在进行分布式架构设计时,就必须针对上面提到的cap原则做出取舍。

一般是通过分布式缓存中各节点的最终一致性来提高系统的性能,通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 redis 之类的 NOSQL 作为实现手段。

Eureka和Zookeeper就是CAP定理中的实现,Eureka(保证AP),Zookeeper(保证CP)

zookeeper保证cp

当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
  3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

Zookeeper的设计理念就是分布式协调服务,保证数据(配置数据,状态数据)在多个服务系统之间保证一致性,这也不难看出Zookeeper是属于CP特性(Zookeeper的核心算法是Zab,保证分布式系统下,数据如何在多个服务之间保证数据同步)。Eureka是吸取Zookeeper问题的经验,先保证可用性。

0

分布式数据库 ID 生成器百度 UidGenerator 原理

UidGenerator 是用 Java 语言实现的基于 Snowflake 算法的分布式唯一 ID 生成器。

UidGenerator 是以组件形式工作在应用项目中, 支持自定义 workerId 位数和初始化策略, 从而适用于 Docker 等虚拟化环境下实例自动重启、漂移等场景。在实现上,UidGenerator 通过借用未来时间来解决 Sequence 天然存在的并发限制;采用 RingBuffer 来缓存已生成的 UID, 并行化 UID 的生产和消费,,同时对 CacheLine 补齐,避免了由 RingBuffer 带来的硬件级「伪共享」问题,最终单机 QPS 可达600万。

uid-generator 中的 workId 是由 uid-generator 自动生成的,并且考虑到了应用部署在 docker 上的情况,在 uid-generator 中,用户可以自己去定义 workId 的生成策略,默认提供的策略是:应用启动时由数据库分配。说的简单就是:应用在启动时会往数据库表 ( uid-generator 需要新增 WORKER_NODE 表)中去插入一条数据,数据插入成功后,返回的自增唯一 id 就是该机器的 workId,而数据由 host 和 port 组成

对于 uid-generator 中的 workId,占用了22个 bit 位,时间占用了28个 bit 位,序列化占用了13个 bit 位,需要注意的是,和原始的 snowflake 不太一样,时间的单位是秒,而不是毫秒,workId 也不一样,同一个应用每重启一次就会消费一个 workId。

DefaultUidGenerator

delta seconds

指的是当前时间和epoch时间的时间差,单位位秒。epoch时间指的是UidGenerator生成分布式ID服务第一次上线的时间,可配置,也一定要根据你的上线时间进行配置,因为默认的epoch时间可是2016-09-20,不配置的话,会浪费好几年的可用时间

worker id

看下worker id是如何赋值的,先创建worker_node表,分布式ID的实例启动的时候,往这个表中插入一行数据,得到的id值就是准备赋给workerId的值。由于workerId默认22位,那么,集成UidGenerator生成分布式ID的所有实例重启次数是不允许超过4194303次(即2^22-1),否则会抛出异常。 当然也可以自定义生成workerid的方式。

sequence

关键点实现:

synchronized保证线程安全;
如果时间有任何的回拨,那么直接抛出异常;
如果当前时间和上一次是同一秒时间,那么sequence自增。如果同一秒内自增值超过2^13-1,那么就会自旋等待下一秒(getNextSecond);
如果是新的一秒,那么sequence重新从0开始;

总结

时钟回拨的处理比较简单粗暴。另外如果使用UidGenerator的DefaultUidGenerator方式生成分布式ID,一定要根据你的业务的情况和特点,调整各个字段占用的位数:

CachedUidGenerator

CachedUidGenerator是UidGenerator的重要改进实现。它的核心利用了RingBuffer,如下图所示,它本质上是一个数组,数组中每个项被称为slot。UidGenerator设计了两个RingBuffer,一个保存唯一ID,一个保存flag。RingBuffer的尺寸是2^n,n必须是正整数:

RingBuffer Of Flag

保存flag这个RingBuffer的每个slot的值都是0或者1,0是CAN_PUT_FLAG的标志位,1是CAN_TAKE_FLAG的标识位。每个slot的状态要么是CAN_PUT,要么是CAN_TAKE。以某个slot的值为例,初始值为0,即CAN_PUT。接下来会初始化填满这个RingBuffer,这时候这个slot的值就是1,即CAN_TAKE。等获取分布式ID时取到这个slot的值后,这个slot的值又变为0,以此类推。

RingBuffer Of UID

保存唯一ID的RingBuffer有两个指针,Tail指针和Cursor指针。

Tail指针表示最后一个生成的唯一ID。如果这个指针追上了Cursor指针,意味着RingBuffer已经满了。这时候,不允许再继续生成ID了。用户可以通过属性rejectedPutBufferHandler指定处理这种情况的策略。

Cursor指针表示最后一个已经给消费的唯一ID。如果Cursor指针追上了Tail指针,意味着RingBuffer已经空了。这时候,不允许再继续获取ID了。用户可以通过属性rejectedTakeBufferHandler指定处理这种异常情况的策略。

另外,如果你想增强RingBuffer提升它的吞吐能力,那么需要配置一个更大的boostPower值:

CachedUidGenerator的理论讲完后,接下来就是它具体是如何实现的了,我们首先看它的申明,它是实现了DefaultUidGenerator,所以,它事实上就是对DefaultUidGenerator的增强:

public class CachedUidGenerator extends DefaultUidGenerator implements DisposableBean {
… …
}

worker id

CachedUidGenerator的workerId实现继承自它的父类DefaultUidGenerator,即实例启动时往表WORKER_NODE插入数据后得到的自增ID值。

接下来深入解读CachedUidGenerator的核心操作,即对RingBuffer的操作,包括初始化、取分布式唯一ID、填充分布式唯一ID等。

初始化

CachedUidGenerator在初始化时除了给workerId赋值,还会初始化RingBuffer。这个过程主要工作有:

根据boostPower的值确定RingBuffer的size;

构造RingBuffer,默认paddingFactor为50。这个值的意思是当RingBuffer中剩余可用ID数量少于50%的时候,就会触发一个异步线程往RingBuffer中填充新的唯一ID(调用BufferPaddingExecutor中的paddingBuffer()方法,这个线程中会有一个标志位running控制并发问题),直到填满为止;
判断是否配置了属性scheduleInterval,这是另外一种RingBuffer填充机制, 在Schedule线程中, 周期性检查填充。默认:不配置, 即不使用Schedule线程. 如需使用, 请指定Schedule线程时间间隔, 单位:秒;
初始化Put操作拒绝策略,对应属性rejectedPutBufferHandler。即当RingBuffer已满, 无法继续填充时的操作策略。默认无需指定, 将丢弃Put操作, 仅日志记录. 如有特殊需求, 请实现RejectedPutBufferHandler接口(支持Lambda表达式);
初始化Take操作拒绝策略,对应属性rejectedTakeBufferHandler。即当环已空, 无法继续获取时的操作策略。默认无需指定, 将记录日志, 并抛出UidGenerateException异常. 如有特殊需求, 请实现RejectedTakeBufferHandler接口;
初始化填满RingBuffer中所有slot(即塞满唯一ID,这一步和第2步骤一样都是调用BufferPaddingExecutor中的paddingBuffer()方法);
开启buffer补丁线程(前提是配置了属性scheduleInterval),原理就是利用ScheduledExecutorService的scheduleWithFixedDelay()方法。
说明:第二步的异步线程实现非常重要,也是UidGenerator解决时钟回拨的关键:在满足填充新的唯一ID条件时,通过时间值递增得到新的时间值(lastSecond.incrementAndGet()),而不是System.currentTimeMillis()这种方式,而lastSecond是AtomicLong类型,所以能保证线程安全问题。

取值

RingBuffer初始化有值后,接下来的取值就简单了。不过,由于分布式ID都保存在RingBuffer中,取值过程中就会有一些逻辑判断:

如果剩余可用ID百分比低于paddingFactor参数指定值,就会异步生成若干个ID集合,直到将RingBuffer填满。
如果获取值的位置追上了tail指针,就会执行Task操作的拒绝策略。
获取slot中的分布式ID。
将这个slot的标志位只为CAN_PUT_FLAG。

总结

通过上面对UidGenerator的分析可知,CachedUidGenerator方式主要通过采取如下一些措施和方案规避了时钟回拨问题和增强唯一性:

自增列:UidGenerator的workerId在实例每次重启时初始化,且就是数据库的自增ID,从而完美的实现每个实例获取到的workerId不会有任何冲突。
RingBuffer:UidGenerator不再在每次取ID时都实时计算分布式ID,而是利用RingBuffer数据结构预先生成若干个分布式ID并保存。
时间递增:传统的雪花算法实现都是通过System.currentTimeMillis()来获取时间并与上一次时间进行比较,这样的实现严重依赖服务器的时间。而UidGenerator的时间类型是AtomicLong,且通过incrementAndGet()方法获取下一次的时间,从而脱离了对服务器时间的依赖,也就不会有时钟回拨的问题(这种做法也有一个小问题,即分布式ID中的时间信息可能并不是这个ID真正产生的时间点,例如:获取的某分布式ID的值为3200169789968523265,它的反解析结果为{“timestamp”:”2019-05-02 23:26:39″,”workerId”:”21″,”sequence”:”1″},但是这个ID可能并不是在”2019-05-02 23:26:39″这个时间产生的)。

0

SpringBoot项目快速优雅集成百度UidGenerator分布式数据库id生成器

简介

百度UidGenerator是一个分布式数据库id生成器,本文在SpringBoot项目快速优雅集成百度UidGenerator,使用的是 uid-generator-spring-boot-starter ,它是基于百度UidGenerator,在此基础上做了部分改进。

  • 改造为spring-boot-starter的形式,不用部署为分布式,直接建表、在项目中引入,即可使用
  • 针对时钟回拨,提供了修正选项(默认启用,可通过配置关闭),小于阈值直接休眠,大于阈值更改机器号
  • 对机器id用尽提供了复用策略:取余
  • 解除id位数限制,由“必须64位”改为“不大于64位”,可根据需要获取更短id

集成步骤

1.在项目使用的数据库里,执行WORKER_NODE表脚本

我这边使用的是MySQL数据库

2.maven的pom文件里引入依赖

其它的springboot默认依赖和mysql依赖我就不贴了

3.配置文件application.properties里引入自定义配置

这些自定义配置不是必须的,大家结合自己实际情况配置即可。

还是老规矩,其它的(例如MySQL)配置项我就不贴出来了。

4.IdGenerator.java工具类

这边我们使用CachedUidGenerator,因为它的性能更好。

5.UidController.java测试类

运行测试

1.启动springboot项目

可以看到worker_node表里已经插入一条记录

2.调用接口 http://localhost:5656/testGet

3.调用接口 http://localhost:5656/testParse/898654797824

898654797824 是刚刚获取到的uid

0