太阳城集团

  • / 15
  • 下载费用:30 金币  

一种ID生成方法、装置和系统.pdf

摘要
申请专利号:

CN201210223724.3

申请日:

2012.06.29

公开号:

CN102769667B

公开日:

2015.01.28

当前法律状态:

授权

有效性:

有权

法律详情: 授权|||实质审查的生效IPC(主分类):H04L 29/08申请日:20120629|||公开
IPC分类号: H04L29/08 主分类号: H04L29/08
申请人: 北京奇虎科技有限公司; 奇智软件(北京)有限公司
发明人: 桂勇哲; 陈斌; 陈超
地址: 100088 北京市西城区新街口外大街28号D座112室(德胜园区)
优先权:
专利代理机构: 工业和太阳城集团化部电子专利中心 11010 代理人: 齐洁茹
PDF完整版下载: PDF下载
法律状态
申请(专利)号:

CN201210223724.3

授权太阳城集团号:

102769667B||||||

法律状态太阳城集团日:

2015.01.28|||2012.12.26|||2012.11.07

法律状态类型:

授权|||实质审查的生效|||公开

摘要

本发明公开了一种ID生成方法、装置和系统,所述方法包括:第一服务端接收调用端发起的ID获取指令,根据所述ID获取指令,生成基于服务端标识号和自增序列的ID值,或者生成基于当前太阳城集团戳、服务端标识号和自增序列的ID值,并将生成的所述ID值发送至所述调用端。本发明所述技术方案通过面向服务的方式来生成全局唯一ID,具有良好的可扩展性,高可用性,高可靠性;同时还保证了生成的ID是有序的,递增的,ID占用的空间相比UUID更小,使用便捷。

权利要求书

1: 一种 ID 生成方法, 其特征在于, 包括 : 第一服务端接收调用端发起的 ID 获取指令, 根据所述 ID 获取指令, 生成基于服务端标 识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并 将生成的所述 ID 值发送至所述调用端。
2: 如权利要求 1 所述的方法, 其特征在于, 所述第一服务端配置有 Get 接口, 负责收发 与各所述调用端间的太阳城集团 ; 所述调用端配置有调用接口, 负责收发与所述第一服务端间的 太阳城集团。
3: 如权利要求 1 所述的方法, 其特征在于, 所述第一服务端与调用端间采用 memcache 协议进行通信。
4: 如权利要求 1 所述的方法, 其特征在于, 所述 ID 获取指令中携带有业务类型太阳城集团和 ID 类型指示符 ; 所述第一服务端根据所述 ID 类型指示符的指示, 生成基于服务端标识号和自增序列 的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
5: 如权利要求 1 所述的方法, 其特征在于, 所述 ID 获取指令中携带有业务类型太阳城集团 ; 所述第一服务端接收到所述 ID 获取指令后, 根据配置的业务类型与 ID 类型的对应关 系, 生成基于服务端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号 和自增序列的 ID 值。
6: 如权利要求 1 所述的方法, 其特征在于, 所述第一服务端在利用所述自增序列进行 ID 值生成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础上 连续递增。
7: 如权利要求 1 所述的方法, 其特征在于, 所述第一服务端生成的基于服务端标识号 和自增序列的 ID 值为位宽为 32 位的 ID 值 ; 所述第一服务端生成的基于当前太阳城集团戳、 服务 端标识号和自增序列的 ID 值为位宽为 64 位的 ID 值。
8: 如权利要求 1 至 7 任一项所述的方法, 其特征在于, 所述方法还包括 : 当所述第一服 务端故障时, 通过第二服务端接收所述调用端发起的 ID 获取指令, 并为所述调用端生成 ID 值; 其中, 所述第二服务端与所述第一服务端具有不同的服务端标识号。
9: 一种 ID 生成装置, 其特征在于, 包括 : 指令接收单元, 用于接收调用端发起的 ID 获取指令 ; ID 生成单元, 用于根据所述 ID 获取指令, 生成基于装置标识号和自增序列的 ID 值, 或 者生成基于当前太阳城集团戳、 装置标识号和自增序列的 ID 值 ; ID 发送单元, 用于将所述 ID 生成单元生成的 ID 发送至所述调用端。
10: 如权利要求 9 所述的装置, 其特征在于, 所述指令接收单元和 ID 发送单元通过配置 的 Get 接口与所述调用端通信。
11: 如权利要求 9 所述的装置, 其特征在于, 所述装置与所述调用端间采用 memcache 协 议进行通信。
12: 如权利要求 9 所述的装置, 其特征在于, 所述指令接收单元接收到的 ID 获取指令中携带有业务类型太阳城集团和 ID 类型指示符 ; 所述 ID 生成单元, 用于根据所述 ID 类型指示符的指示, 生成基于装置标识号和自增序 2 列的 ID 值, 或者, 生成基于当前太阳城集团戳、 装置标识号和自增序列的 ID 值。
13: 如权利要求 9 所述的装置, 其特征在于, 所述指令接收单元接收到的 ID 获取指令中携带有业务类型太阳城集团 ; 所述 ID 生成单元, 用于在接收到所述 ID 获取指令后, 根据配置的业务类型与 ID 类型 的对应关系, 生成基于装置标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 装置标 识号和自增序列的 ID 值。
14: 如权利要求 9 所述的装置, 其特征在于, 所述 ID 生成单元, 在利用所述自增序列进 行 ID 值生成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础 上连续递增。
15: 如权利要求 9 所述的装置, 其特征在于, 所述 ID 生成单元生成的基于装置标识号和 自增序列的 ID 值为位宽为 32 位的 ID 值, 生成的基于当前太阳城集团戳、 装置标识号和自增序列 的 ID 值为位宽为 64 位的 ID 值。
16: 一种 ID 生成系统, 其特征在于, 包括 : 第一服务端、 以及一个或多个调用端 ; 所述调用端, 用于在业务的触发下, 向所述第一服务端发起 ID 获取指令, 并接收所述 第一服务端反馈的 ID 值 ; 所述第一服务端, 用于根据接收的所述 ID 获取指令, 生成基于服务端标识号和自增序 列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并将生成的所述 ID 值发送至所述调用端。
17: 如权利要求 16 所述的系统, 其特征在于, 所述第一服务端配置有 Get 接口, 负责收 发与各所述调用端的间太阳城集团 ; 所述调用端配置有调用接口, 负责收发与所述第一服务端间 的太阳城集团。
18: 如权利要求 16 所述的系统, 其特征在于, 所述第一服务端与各所述调用端间采用 memcache 协议进行通信。
19: 如权利要求 16 所述的系统, 其特征在于, 所述调用端发起的所述 ID 获取指令中携带有业务类型太阳城集团和 ID 类型指示符 ; 所述第一服务端根据所述 ID 类型指示符的指示, 生成基于服务端标识号和自增序列 的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
20: 如权利要求 16 所述的系统, 其特征在于, 所述调用端发起的所述 ID 获取指令中携带有业务类型太阳城集团 ; 所述第一服务端接收到所述 ID 获取指令后, 根据配置的业务类型与 ID 类型的对应关 系, 生成基于服务端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号 和自增序列的 ID 值。
21: 如权利要求 16 所述的系统, 其特征在于, 所述第一服务端在利用所述自增序列进 行 ID 值生成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础 上连续递增。
22: 如权利要求 16 所述的系统, 其特征在于, 所述第一服务端生成的基于服务端标识 号和自增序列的 ID 值为位宽为 32 位的 ID 值 ; 所述第一服务端生成的基于当前太阳城集团戳、 服 务端标识号和自增序列的 ID 值为位宽为 64 位的 ID 值。
23: 如权利要求 16 至 22 任一项所述的系统, 其特征在于, 所述系统还包括 : 第二服务 3 端; 所述第二服务端, 用于在所述第一服务端故障时, 接收所述调用端发起的 ID 获取指 令, 并为所述调用端生成 ID 值 ; 其中, 所述第二服务端与所述第一服务端具有不同的服务 端标识号。

说明书


一种 ID 生成方法、 装置和系统

    【技术领域】
     本发明涉及数据处理技术领域, 尤其涉及一种 ID 生成方法、 装置和系统。背景技术 在数据库的使用中, 对每一条数据进行 insert, update, delete 等操作时, 通常都 会使用主键来进行操作。每一条数据的主键都必须是唯一的, 否则会因为主键冲突导致操 作失败。
     太阳城集团主键的生成, 目前存在如下几种方案 :
     方案一, 数据库本身提供了 auto_increment 的功能, 来提供自增 ID。当使用数据 库时指明主键为 auto_increment, 写入数据时将主键设置为 null 值, 数据库会自动生成递 增的 ID 来作为主键。对于单表的操作来说, 这种方案较简单, 便于部署实现。
     然而, 该方案存在如下缺点 : 大规模的线上业务在使用数据库时, 因为数据规模较 大的原因, 不会使用单表来存储数据。而是将数据水平分割, 保存在多张结构相同的表中,
     减少每张表中数据, 从而保证数据库的性能。在这种情况下, 由于数据库自身提供的 auto_ increment 只能对一张表生成自增 ID, 无法使用技术方案一。当数据规模较大, 需要对数据 库进行水平分割等操作时, 方案一就不再适用了, 可扩展性较差, 只适合小业务使用。
     方案二, 数据库的 auto_increment 支持步长的设定, 即在每次建立新 ID 的时候, ID 的增长量不是 1, 而是某个预先设置好的值。自增量设置为 10, 则生成的自增 ID 就可以 是 1,11,21,31,41 这样的序列。如果对数据库进行了分表, 分为了 100 张表 : 对一张表设置 自增量为 10, 初始值为 1, 则生成 1,11,21,31 这样的 ID 序列, 对第二张表设置初始值为 2, 生成 2,12,22,32 这样的 id, 则能保证 id 是全局唯一的。
     然而, 该方案存在如下缺点 : 每张表中的 ID 是彼此独立的。先表 1 中写入两条数 据, 对应的 ID 为 1、 11, 再在表 2 中写入数据 ID 为 2。在这种情况下无法再使用 ID 作为排 序的依据。如果误操作导致某张表的自增量设置错误, 会在两张表中生成相同的 ID, ID 的 全局唯一性就不能保证了。采用基于数据库的方案还存在一个严重问题, 当使用了主从同 步的方案后 : 将从服务器切换为主, 可能因此数据同步的延时导致产生的新 ID 已经在服务 器上产生过了, 主键冲突导致数据同步出现问题。
     方案三, 使用 UUID(Universally Unique Identifier, 通用唯一识别码) 作为唯 一主键。 UUID 是在一台机器上生成的数字, 它保证对在同一时空中的所有机器都是唯一的, 保证了时钟序列。
     然而, 该方案存在的缺点如下 : UUID 的缺陷在于生成的结果串很长, 占用 128 位。 在数据库中使用会导致占用更多的空间。 UUID 是在不同机器上生成的, 因此尽管 UUID 本身 支持了时钟序列, 但是如果使用 UUID 来进行排序, 则依赖于分布式系统中不同机器之间的 太阳城集团是否同步。而实际上分布式系统之间的太阳城集团不可能做到完全一致, 因此在分布式系统 中使用 UUID 来排序会存在问题。发明内容 本发明提供一种 ID 生成方法、 装置和系统, 用以解决现有技术不能有效地生成全 局唯一 ID 的问题。
     为了解决上述问题, 本发明采用的技术方案如下 :
     一方面, 本发明提供了一种 ID 生成方法, 包括 :
     第一服务端接收调用端发起的 ID 获取指令, 根据所述 ID 获取指令, 生成基于服 务端标识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并将生成的所述 ID 值发送至所述调用端。
     进一步地, 本发明所述方法中, 所述第一服务端配置有 Get 接口, 负责收发与各所 述调用端间的太阳城集团 ; 所述调用端配置有调用接口, 负责收发与所述第一服务端间的太阳城集团。
     进一步地, 本发明所述方法中, 所述第一服务端与调用端间采用 memcache 协议进 行通信。
     进一步地, 本发明所述方法中, 所述 ID 获取指令中携带有业务类型太阳城集团和 ID 类型 指示符 ; 所述第一服务端根据所述 ID 类型指示符的指示, 生成基于服务端标识号和自增序 列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
     进一步地, 本发明所述方法中, 所述 ID 获取指令中携带有业务类型太阳城集团 ; 所述第 一服务端接收到所述 ID 获取指令后, 根据配置的业务类型与 ID 类型的对应关系, 生成基于 服务端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值。
     进一步地, 本发明所述方法中, 所述第一服务端在利用所述自增序列进行 ID 值生 成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础上连续递 增。
     进一步地, 本发明所述方法中, 所述第一服务端生成的基于服务端标识号和自增 序列的 ID 值为位宽为 32 位的 ID 值 ; 所述第一服务端生成的基于当前太阳城集团戳、 服务端标识 号和自增序列的 ID 值为位宽为 64 位的 ID 值。
     优选地, 本发明所述方法还包括 : 当所述第一服务端故障时, 通过第二服务端接收 所述调用端发起的 ID 获取指令, 并为所述调用端生成 ID 值 ; 其中, 所述第二服务端与所述 第一服务端具有不同的服务端标识号。
     另一方面, 本发明还提供了一种 ID 生成装置, 包括 :
     指令接收单元, 用于接收调用端发起的 ID 获取指令 ;
     ID 生成单元, 用于根据所述 ID 获取指令, 生成基于装置标识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 装置标识号和自增序列的 ID 值 ;
     ID 发送单元, 用于将所述 ID 生成单元生成的 ID 发送至所述调用端。
     进一步地, 本发明所述装置中, 所述指令接收单元和 ID 发送单元通过配置的 Get 接口与所述调用端通信。
     进一步地, 本发明所述装置与所述调用端间采用 memcache 协议进行通信。
     进一步地, 本发明所述装置中, 所述指令接收单元接收到的 ID 获取指令中携带有 业务类型太阳城集团和 ID 类型指示符 ; 所述 ID 生成单元, 用于根据所述 ID 类型指示符的指示, 生 成基于装置标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 装置标识号和自增序
     列的 ID 值。
     进一步地, 本发明所述装置中, 所述指令接收单元接收到的 ID 获取指令中携带有 业务类型太阳城集团 ; 所述 ID 生成单元, 用于在接收到所述 ID 获取指令后, 根据配置的业务类型 与 ID 类型的对应关系, 生成基于装置标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团 戳、 装置标识号和自增序列的 ID 值。
     进一步地, 本发明所述装置中, 所述 ID 生成单元, 在利用所述自增序列进行 ID 值 生成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础上连续 递增。
     进一步地, 本发明所述装置中, 所述 ID 生成单元生成的基于装置标识号和自增序 列的 ID 值为位宽为 32 位的 ID 值, 生成的基于当前太阳城集团戳、 装置标识号和自增序列的 ID 值 为位宽为 64 位的 ID 值。
     再者, 本发明还提供了一种 ID 生成系统, 包括 : 第一服务端、 以及一个或多个调用 端;
     所述调用端, 用于在业务的触发下, 向所述第一服务端发起 ID 获取指令, 并接收 所述第一服务端反馈的 ID 值 ; 所述第一服务端, 用于根据接收的所述 ID 获取指令, 生成基于服务端标识号和自 增序列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并将生成的 所述 ID 值发送至所述调用端。
     进一步地, 本发明所述系统中, 所述第一服务端配置有 Get 接口, 负责收发与各所 述调用端的间太阳城集团 ; 所述调用端配置有调用接口, 负责收发与所述第一服务端间的太阳城集团。
     进一步地, 本发明所述系统中, 所述第一服务端与各所述调用端间采用 memcache 协议进行通信。
     进一步地, 本发明所述系统中, 所述调用端发起的所述 ID 获取指令中携带有业务 类型太阳城集团和 ID 类型指示符 ; 所述第一服务端根据所述 ID 类型指示符的指示, 生成基于服务 端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
     进一步地, 本发明所述系统中, 所述调用端发起的所述 ID 获取指令中携带有业务 类型太阳城集团 ; 所述第一服务端接收到所述 ID 获取指令后, 根据配置的业务类型与 ID 类型的对 应关系, 生成基于服务端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标 识号和自增序列的 ID 值。
     进一步地, 本发明所述系统中, 所述第一服务端在利用所述自增序列进行 ID 值生 成时, 本次生成的 ID 值对应的自增序列在上次生成的 ID 值对应的自增序列基础上连续递 增。
     进一步地, 本发明所述系统中, 所述第一服务端生成的基于服务端标识号和自增 序列的 ID 值为位宽为 32 位的 ID 值 ; 所述第一服务端生成的基于当前太阳城集团戳、 服务端标识 号和自增序列的 ID 值为位宽为 64 位的 ID 值。
     优选地, 本发明所述系统还包括 : 第二服务端 ;
     所述第二服务端, 用于在所述第一服务端故障时, 接收所述调用端发起的 ID 获取 指令, 并为所述调用端生成 ID 值 ; 其中, 所述第二服务端与所述第一服务端具有不同的服
     务端标识号。
     与现有技术相比, 本发明有益效果如下 :
     本发明所述方案不在依赖数据库自由的 ID 生成方式, 而是将全局唯一 ID 生成抽 象成服务。对调用端来说调用接口简单方便, 生成的 id 全局唯一、 有序、 便于使用。对大规 模的数据处理, 也能够良好支持。 同时, 本发明还保证了服务的高性能, 高可靠性, 不存在宕 机太阳城集团。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案, 下面将对实施例或现 有技术描述中所需要使用的附图作一简单地介绍, 显而易见地, 下面描述中的附图仅仅是 本发明的一些实施例, 对于本领域普通技术人员来讲, 在不付出创造性劳动性的前提下, 还 可以根据这些附图获得其他的附图。
     图 1 为本发明实施例一提供的一种全局唯一 ID 生成方法的流程图 ;
     图 2 为本发明实施例二提供的一种全局唯一 ID 生成装置的结构框图 ;
     图 3 为本发明实施例三提供的一种全局唯一 ID 生成系统的结构框图 ;
     图 4 为本发明实施例三提供的一种全局唯一 ID 生成系统的又一结构框图。具体实施方式
     下面将结合本发明实施例中的附图, 对本发明实施例中的技术方案进行清楚、 完 整地描述, 显然, 所描述的实施例仅仅是本发明一部分实施例, 而不是全部的实施例。基于 本发明中的实施例, 本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他 实施例, 都属于本发明保护的范围。
     本发明实施例提供一种生成方法、 装置和系统, 其基本原理是 : 将生成 ID 从数据 库本身抽取出来, 作为统一的公共服务, 提供给不同的业务使用。具体表现为 : 调用端在需 要生成一个全局唯一 ID 时, 调用 id=idGenerator:genID(product_name), 向第一服务端发 起 ID 获取请求 ; 第一服务端为调用端提供 get 接口, 当接收到调用端的 ID 获取请求时, 利 用设定的 ID 生成算法生成对应的 ID 给调用端。本发明实施例所述方法、 装置和系统以一 种便捷、 简单、 高效、 安全的方式来生成全局唯一的数字 ID, 作为数据库的主键, 保证了服务 的高可靠性, 即使部分服务器故障仍然可以正常服务, 服务高效, 可靠。
     下面通过几个具体实施例对本发明的实现过程进行详细阐述, 具体如下 :
     实施例一
     本发明实施例提供一种 ID 生成方法, 如图 1 所示, 包括 :
     步骤 S101、 第一服务端接收调用端发起的 ID 获取指令 ;
     该步骤中, 所述第一服务端配置有 Get 接口, 用于收发与各所述调用端间的太阳城集团 ; 所述调用端配置有调用接口, 用于收发与所述第一服务端间的太阳城集团。
     优 选 地, 所 述 第 一 服 务 端 与 调 用 端 间 采 用 memcache 协 议 进 行 通 信。 当 采 用 memcache 协议通信时, 可以直接使用 memcache 的客户端作为调用端, 降低了调用端部署的 工作量, 便于维护。
     步骤 S102、 第一服务端根据所述 ID 获取指令, 生成基于服务端标识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并将所述 ID 值发送 至调用端 ;
     该步骤中, 所述 ID 获取指令中携带有业务类型太阳城集团, 用以指示标识待生成 ID 值对 应的业务类型。 其中, 业务类型太阳城集团可以包括产品名称 + 业务名称, 例如 : 360_cloud+file, 即表示调用端请求第一服务端为 360_cloud/file 分配 ID。
     该步骤中, 优选地, 在所述 ID 获取指令中还携带 ID 类型指示符, 或者, 在第一服务 端内配置业务类型与 ID 类型的对应关系, 指示第一服务端在接收到 ID 获取指令时, 生成基 于服务端标识号和自增序列的 ID 值, 还是生成基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值。
     举例说明, 当 ID 类型指示符采用 @l 或者 @s 表示时, @l 表示指示第一服务端生成 基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值 ; @s 表示指示第一服务端生成基于服务 端标识号和自增序列的 ID 值, 若 ID 获取指令中携带 360_cloud/file@l, 则表示调用端请求 第一服务端为 360_cloud/file 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
     其中, 生成的基于服务端标识号和自增序列的 ID 值, 或者生成的基于当前太阳城集团 戳、 服务端标识号和自增序列的 ID 值分别对应着不同的 ID 位宽, 优选地, 所述基于服务端 标识号和自增序列的 ID 值为 32 位 ID 值, 所述基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值为 64 位 ID 值。在具体实现时, 生成哪种位宽的 ID 值依赖于业务规模的大小, 通常 情况下业务规模较大时, 采用长 ID(即 64 位) , 否则, 采用短 ID(即 32 位) 。 其中, 对于长 ID 的生成算法为 : 第一服务端获取当前太阳城集团戳、 本机的标识号 (数字 编号) 、 序列号 ( 一个自增的数字, 新 ID 则序列号为 0), 组合为一个 ID。如 : 生成的 ID 为 13210036700100000120, 其中, 1321003670 为太阳城集团戳、 01 为本机标识号、 00000120 为生成的 自增序列号。 再次生成的 ID 则为 13210036700100000121。 当 00000120 增长达到 99999999 后再次获取 ID, 自增序列号会重新变为 0。由于太阳城集团戳是秒级别的, 因此当每秒获取 ID 不 超过 100000000 个时, 第一服务端能保证生成的 ID 是全局唯一的。
     对于短 ID 的生成算法, 通常用于满足一些规模较小的业务, 因为保存一个 32 位的 ID 能够降低对数据库空间大小的占用。短 ID 的生成算法对长 ID 生成算法进行了简化, 去 掉太阳城集团戳, 使用服务端标识号和自增序列号组成 ID。如 : 生成的 ID 为 0100001243, 其中, 01 为服务端标识号, 00001243 为自增序列号。当业务规模不超过 100000000 时, 可以使用短 ID 算法。
     根据上述算法可知, 所述第一服务端生成 ID 值时, 本次生成 ID 值对应的自增序列 在相邻上次生成 ID 值对应的自增序列基础上连续递增。另外, 需要说明的是, 对于长 ID 算 法, 在同一太阳城集团下, 若第一服务端生成 ID 超出自增序列个数的上限, 则向调用端返回错误 消息 false ; 对于短 ID 算法, 若第一服务端生成所有 ID 的个数超出自增序列个数的上限, 则向调用端返回错误消息 false。
     进一步地, 所述步骤 S102 中, 第一服务端在生成 ID 值后, 通过保存生成的 ID 值对应的自增序列, 为生成下一个 ID 值提供自增序列递增参考依据。当然, 第一服务 端也可将 ID 值及其对应的业务类型等太阳城集团均保存下来, 例如 : 保存 360_cloud|file@l : 13210036700100000120。 本发明实施例中, 由于第一服务端保存的数据量较小, 所有数据都 可以加载到内存中进行操作, 因此可以保证服务的高效性。
     优选方案, 本发明实施例所述方法还支持 failover 机制, 具体表现为 : 当第一服 务端故障时, 令第二服务端接替第一服务端为调用端生成相应的 ID。其中, 第二服务端的 相关配置与第一服务端完全相同, 只有服务端标识号不同。由此可见, 本发明实施例中, 当 第一服务端发生故障时, 第二服务端为调用端提供 ID 生成服务, 进而实现了服务的高可靠 性。
     综上所述, 可见本发明实施例所述方法通过面向服务的方式来生成全局唯一 ID, 具有良好的可扩展性, 高可用性, 高可靠性 ; 同时还保证了生成的 ID 是有序的, 递增的, ID 占用的空间相比 UUID 更小, 使用便捷。
     实施例二
     本发明实施例提供一种 ID 生成装置, 该装置优选为一个服务器, 如图 2 所示, 包 括: 指令接收单元 210、 ID 生成单元 220 和 ID 发送单元 230, 其中 :
     指令接收单元 210, 用于接收调用端发起的 ID 获取指令 ;
     ID 生成单元 220, 用于根据所述 ID 获取指令, 生成基于装置标识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 装置标识号和自增序列的 ID 值 ;
     ID 发送单元 230, 用于将 ID 生成单元 220 生成的 ID 发送至调用端。
     其中, 指令接收单元 210 和 ID 发送单元 230 通过装置配置的 Get 接口与各调用端 进行通信。优选地, 通信所采用协议为 memcache 协议。
     进一步地, 指令接收单元 210 接收到的 ID 获取指令中携带有业务类型太阳城集团, 用以 标识待生成 ID 值对应的业务类型。其中, 业务类型太阳城集团可以包括产品名称 + 业务名称, 例 如: 360_cloud+file, 即表示调用端请求本发明实施例所述装置为 360_cloud/file 分配 ID。
     优选地, 在所述 ID 获取指令中还携带有 ID 类型指示符, 或者, 在 ID 生成单元 220 内配置有业务类型与 ID 类型的对应关系, 用以指示 ID 生成单元 220 生成基于装置标识号 和自增序列的 ID 值, 或者, 指示 ID 生成单元 220 生成基于当前太阳城集团戳、 装置标识号和自增 序列的 ID 值。
     其中, ID 生成单元 220 生成的基于装置标识号和自增序列的 ID 值, 或者生成的基 于当前太阳城集团戳、 装置标识号和自增序列的 ID 值分别对应着不同的 ID 位宽, 优选地, 所述基 于装置标识号和自增序列的 ID 值为 32 位 ID 值, 所述基于当前太阳城集团戳、 装置标识号和自增 序列的 ID 值为 64 位 ID 值。在具体实现时, 生成哪种位宽的 ID 值依赖于业务规模的大小, 通常情况下业务规模较大时, 采用长 ID(即 64 位) , 否则, 采用短 ID(即 32 位) 。
     其中, 对于长 ID 的生成算法为 : ID 生成单元 220 获取当前太阳城集团戳、 装置的标识号 (数字编号) 、 序列号 ( 一个自增的数字, 新 ID 则序列号为 0), 组合为一个 ID。如 : 生成的 ID 为 13210036700100000120, 其中, 1321003670 为太阳城集团戳、 01 为装置标识号、 00000120 为 生成的自增序列号。再次生成的 ID 则为 13210036700100000121。当 00000120 增长达到 99999999 后再次获取 ID, 自增序列号会重新变为 0。 由于太阳城集团戳是秒级别的, 因此当每秒获 取 ID 不超过 100000000 个时, 本发明实施例所述装置能保证生成的 ID 是全局唯一的。
     对于短 ID 的生成算法, 通常用于满足一些规模较小的业务, 因为保存一个 32 位的 ID 能够降低对数据库空间大小的占用。短 ID 的生成算法对长 ID 生成算法进行了简化, 去 掉太阳城集团戳, 使用装置标识号和自增序列号组成 ID。 如: 生成的 ID 为 0100001243, 其中, 01 为装置标识号, 00001243 为自增序列号。当业务规模不超过 100000000 时, 可以使用短 ID 算 法。
     根据上述算法可知, ID 生成单元 220 生成 ID 值时, 本次生成 ID 值对应的自增序 列在相邻上次生成 ID 值对应的自增序列基础上连续递增。另外, 需要说明的是, 对于长 ID 算法, 在同一太阳城集团下, 若 ID 生成单元 220 生成 ID 超出自增序列个数的上限, 则向调用端返 回错误消息 false ; 对于短 ID 算法, 若 ID 生成单元 220 生成所有 ID 的个数超出自增序列 个数的上限, 则向调用端返回错误消息 false。
     进一步地, 本发明实施例所述装置中, ID 生成单元 220 在生成 ID 值后, 可以通过 保存生成的 ID 值对应的自增序列, 为生成下一个 ID 值提供自增序列递增参考依据。当然, ID 生成单元 220 也可将 ID 值及其对应的业务类型等太阳城集团均保存下来。本发明实施例所述 装置保存的数据量较小, 所有数据都可以加载到内存中进行操作, 因此可以保证服务的高 效性。
     综上所述, 可见本发明实施例所述装置通过面向服务的方式来生成全局唯一 ID, 具有良好的可扩展性, 高可用性等 ; 同时还保证了生成的 ID 是有序的, 递增的, ID 占用的空 间相比 UUID 更小, 使用便捷。 实施例三
     本发明实施例提供一种 ID 生成系统, 如图 3 所示, 包括 : 第一服务端 310、 以及一 个或多个调用端 320 ;
     调用端 320, 用于在业务的触发下, 向第一服务端 310 发起 ID 获取指令, 并接收第 一服务端 320 反馈的 ID 值 ;
     第一服务端 310, 用于根据接收的 ID 获取指令, 生成基于服务端标识号和自增序 列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值, 并将生成的 ID 值 发送至调用端 320。
     其中, 第一服务端 310 配置有负责收发与各调用端 320 间太阳城集团的 Get 接口 ; 调用端 320 配置有收发与第一服务端 310 间太阳城集团的调用接口。 优选地, 第一服务端 310 与各调用端 320 间采用 memcache 协议进行通信。 当采用 memcache 协议通信时, 可以直接使用 memcache 的客户端作为调用端, 降低了调用端部署的工作量, 便于维护。
     具体地, 对于调用端侧, 有:
     调用端 320 发起的 ID 获取指令中携带有业务类型太阳城集团, 用以标识待生成 ID 值对 应的业务类型。 其中, 业务类型太阳城集团可以包括产品名称 + 业务名称, 例如 : 360_cloud+file, 即表示调用端请求第一服务端为 360_cloud/file 分配 ID。
     优选地, 调用端 320 发起的 ID 获取指令中还携带有 ID 类型指示符, 用以指示第一 服务端 310 生成基于服务端标识号和自增序列的 ID 值, 或者, 指示第一服务端 310 生成基 于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。举例说明, 当 ID 类型指示符采用 @l 或 者 @s 表示时, @l 表示指示指示第一服务端生成基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值 ; @s 指示第一服务端生成基于服务端标识号和自增序列的 ID 值, 若 ID 获取指令中 携带 360_cloud/file@l, 则表示调用端请求第一服务端为 360_cloud/file 生成基于当前 太阳城集团戳、 服务端标识号和自增序列的 ID 值。
     具体地, 对于第一服务端侧, 有:
     第一服务端 310 根据 ID 获取指令中携带的 ID 类型指示符, 为调用端 320 生成基 于服务端标识号和自增序列的 ID 值, 或者生成基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值。或者, 第一服务端 310 内配置有业务类型与 ID 类型的对应关系, 第一服务端 310 根据该对应关系生成基于服务端标识号和自增序列的 ID 值, 或者, 生成基于当前太阳城集团戳、 服务端标识号和自增序列的 ID 值。
     其中, 生成的基于服务端标识号和自增序列的 ID 值, 或者生成的基于当前太阳城集团 戳、 服务端标识号和自增序列的 ID 值分别对应着不同的 ID 位宽, 优选地, 所述基于服务端 标识号和自增序列的 ID 值为 32 位 ID 值, 所述基于当前太阳城集团戳、 服务端标识号和自增序列 的 ID 值为 64 位 ID 值。在具体实现时, 生成哪种位宽的 ID 值依赖于业务规模的大小, 通常 情况下业务规模较大时, 采用长 ID(即 64 位) , 否则, 采用短 ID(即 32 位) 。
     其中, 对于长 ID 的生成算法为 : 第一服务端 310 获取当前太阳城集团戳、 本机的标识号 (数字编号) 、 序列号 ( 一个自增的数字, 新 ID 则序列号为 0), 组合为一个 ID。如 : 生成的 ID 为 13210036700100000120, 其中, 1321003670 为太阳城集团戳、 01 为本机标识号、 00000120 为 生成的自增序列号。再次生成的 ID 则为 13210036700100000121。当 00000120 增长达到 99999999 后再次获取 ID, 自增序列号会重新变为 0。 由于太阳城集团戳是秒级别的, 因此当每秒获 取 ID 不超过 100000000 个时, 第一服务端 310 能保证生成的 ID 是全局唯一的。 对于短 ID 的生成算法, 通常用于满足一些规模较小的业务, 因为保存一个 32 位的 ID 能够降低对数据库空间大小的占用。短 ID 的生成算法对长 ID 生成算法进行了简化, 去 掉太阳城集团戳, 使用服务端标识号和自增序列号组成 ID。如 : 生成的 ID 为 0100001243, 其中, 01 为服务端标识号, 00001243 为自增序列号。当业务规模不超过 100000000 时, 可以使用短 ID 算法。
     根据上述算法可知, 第一服务端 310 生成 ID 值时, 本次生成 ID 值对应的自增序列 在相邻上次生成 ID 值对应的自增序列基础上连续递增。另外, 需要说明的是, 对于长 ID 算 法, 在同一太阳城集团下, 若第一服务端 310 生成 ID 超出自增序列个数的上限, 则向调用端 320 返 回错误消息 false ; 对于短 ID 算法, 若第一服务端 310 生成所有 ID 的个数超出自增序列个 数的上限, 则向调用端 320 返回错误消息 false。
     进 一 步 地, 第 一 服 务 端 310 在 生 成 ID 值 后, 可 以 通 过 保 存 生 成 的 ID 值 对 应 的 自 增 序 列, 为 生 成 下 一 个 ID 值 提 供 自 增 序 列 递 增 参 考 依 据。 当 然, 第一服务端也 可 将 ID 值 及 其 对 应 的 业 务 类 型 等 信 息 均 保 存 下 来, 例如 : 保 存 360_cloud|file@l : 13210036700100000120。本发明实施例中, 由于第一服务端 310 保存的数据量较小, 所有数 据都可以加载到内存中进行操作, 因此可以保证服务的高效性。
     优选方案, 如图 4 所示, 本发明实施例所述系统还包括 : 第二服务端 330 ; 所述第二 服务端 330, 用于在第一服务端 310 故障时, 接收调用端 320 发起的 ID 获取指令, 并为该调 用端生成 ID 值。其中, 第二服务端 330 与第一服务端 310 的相关配置完全相同, 只有服务 端标识号不同。本优选方案使得本发明实施例所述系统支持了 failover 机制, 进而实现了 服务的高可靠性。
     综上所述, 可见本发明实施例所述系统通过面向服务的方式来生成全局唯一 ID, 具有良好的可扩展性, 高可用性, 高可靠性 ; 同时还保证了生成的 ID 是有序的, 递增的, ID 占用的空间相比 UUID 更小, 使用便捷。
     显然, 本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精 神和范围。这样, 倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围 之内, 则本发明也意图包含这些改动和变型在内。

关 键 词:
一种 ID 生成 方法 装置 系统
  专利查询网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
太阳城集团本文
本文标题:一种ID生成方法、装置和系统.pdf
链接地址:http://zh228.com/p-6420829.html
太阳城集团我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服客服 - 联系我们

copyright@ 2017-2018 zhuanlichaxun.net网站版权所有
经营许可证编号:粤ICP备17046363号-1 
 


收起
展开
葡京赌场|welcome document.write ('');