[发明专利]生成分布式ID的系统和方法

说明书

本发明公开了一种生成分布式ID的系统和方法，涉及大数据技术领域。该方法的一具体实施方式包括：分布式数据库集群，用于生成并存储ID可用号段，ID可用号段中包括多个依次增大的可用序列值；第一服务器集群，用于确定第二服务器集群中每个第二服务器的ID；其中，每个第二服务器的ID依次增大；第二服务器集群，用于根据ID可用号段和各第二服务器的ID，生成多个可用业务ID；以及根据ID申请请求，从多个可用业务ID中确定与ID申请请求对应的目标业务ID。该实施方式能够保证在某一台服务器或者某一个机房出问题的情况下，整个系统依然具有高可用性，能够跨城市跨机房访问，适用于大型的金融级项目。

技术领域

本发明涉及大数据技术领域，尤其涉及一种生成分布式ID的系统和方法。

背景技术

在业务数据量不大的时候，可以通过多种方法生成业务ID，主要是通过自增ID实现。具体的，可以通过Redis的原子操作incrby来实现值的自增，然后获取到自增后的ID值，作为业务ID使用。或者，通过访问Mysql，向Mysql表中插入新的数据，然后获取到新的自增主键值来作为业务ID使用。或者，通过访问ZooKeeper，修改ZooKeeper的节点，获得一个新的顺序的节点的版本号，然后用这个版本号作为业务ID使用。又或者，利用本机的时间戳与机器ID拼接来作为业务ID使用。但是，在大型复杂系统中，可能订单、产品、售后都会分库分表，会分布在多个表多个库中，这时如果使用自增ID将会出现大量重复ID，使业务出现问题。即对于大规模复杂业务、分布式高并发的应用场景，显然上述依靠自增序列来生成ID的方式各自存在不同的缺陷，不能满足业务的需求。其中，该缺陷主要表现为：Redis并没有能实现完全实时同步的机制，所以不能很好的支持水平扩展，也就不能很好的实现跨机房访问的情况。Mysql的性能并不够好，当访问量大的时候，Mysql完全无法抗住访问压力，表的高并发插入将会造成大量锁等待，延迟将会非常大，有ID需求的业务将会因为获取不到ID而延迟等待。ZooKeeper虽然支持分布式部署，能实现跨机房访问，但是ZooKeeper性能并不够好，当每秒有上千个ID需求的时候，ZooKeeper将会无法满足需求。利用本机的时间戳与机器ID拼接来作为业务ID的方法严重依赖时间，如果时间回调可能造成重复ID(服务器通常会定时与时钟服务器同步时间，而时钟服务器经常会修正自己的时间，当遇到修正的时候，将会发生时钟回拨，这是就会产生重复ID)，并且没有统一的管理，ID无法溯源。因此，亟需一种支持跨机房的高性能高可靠的分布式ID生成方法。

发明内容

有鉴于此，本发明实施例提供一种生成分布式ID的系统和方法，该系统能够保证在某一台服务器或者某一个机房出问题的情况下，整个系统依然具有高可用性，能够跨城市跨机房访问，适用于大型的金融级项目。

为实现上述目的，根据本发明实施例的一个方面，提供了一种生成分布式ID的系统，包括分布式数据库集群、第一服务器集群和第二服务器集群；

其中，所述分布式数据库集群，用于生成并存储ID可用号段，所述ID可用号段中包括多个依次增大的可用序列值；

所述第一服务器集群，用于确定所述第二服务器集群中每个第二服务器的ID；其中，所述每个第二服务器的ID依次增大；

所述第二服务器集群，用于根据所述ID可用号段和各第二服务器的ID，生成多个可用业务ID；以及根据ID申请请求，从所述多个可用业务ID中确定与所述ID申请请求对应的目标业务ID。

可选地，所述分布式数据库集群还用于设置所述ID可用号段的位数；所述第一服务器集群还用于设置所述第二服务器的ID的位数；所述第二服务器集群还用于设置所述可用业务ID的位数。

可选地，每个所述第二服务器还用于：将所述ID可用号段中的每个所述可用序列值与所述第二服务器的ID进行拼接，若拼接后得到的可用序列值的位数小于所述可用业务ID的位数，则对拼接后得到的可用序列值进行补齐，将补齐后的可用序列值作为可用业务ID。