不得不知的几个互联网ID生成器方案

转载 2018年04月17日 14:00:47

服务化、分布式已成为当下系统开发的首选,高并发操作在数据存储时,需要一套id生成器服务,来保证分布式情况下全局唯一性,以确保系统的订单创建、交易支付等场景下数据的唯一性,否则将造成不可估量的损失。

基于时间戳

比如流水号规则如下:XX-YYYYMMDD-N位随机数,这也是企业级应用开发常用的规则。此流水号对人比较友好,可识别性高,但容量受后面随机数的限制,且数据量越大,生成时难度越高。前三部分每天的流水号基本固定,后面的N位随机数生成后,需要校验此前不存在,可依赖redis的set机制,每天的随机数都写到一个set集合中[set容易达42亿之多,完全够用],重新生成后要与set集合作比对,以确保其唯一性。一天内不重复,再结合确定日期来保证其唯一性。

N位随机数生成时,可基于系统时间戳,再与一个大数取模生成。

UUID/GUID

最简单直接暴力的方式,虽然能够保证ID的唯一性,但是,它无法满足业务系统需要的很多其他特性,例如:时间粗略有序性,可反解和可制造型。另外,UUID产生的时候使用完全的时间数据,性能比较差,并且UUID比较长,占用空间大,间接导致数据库性能下降,更重要的是,UUID并不具有有序性。系统容量较小的时候可以采用,变大后不建议采用此方式。

Vesta

GitHub 地址:https://github.com/robertleepeak/vesta-id-generator

Vesta是一款通用的ID产生器,互联网俗称统一发号器,它具有全局唯一、粗略有序、可反解和可制造等特性,它支持三种发布模式:嵌入发布模式、中心服务器发布模式、REST发布模式,根据业务的性能需求,它可以产生最大峰值型和最小粒度型两种类型的ID,它的实现架构使其具有高性能,高可用和可伸缩等互联网产品需要的质量属性,是一款通用的高性能的发号器产品。 提供4种应用部署方式,具体使用依场景而定:

  • REST发布模式(Netty)
  • REST发布模式(Tomcat)
  • 中心服务器发布模式
  • 嵌入式发布模式

Twitter-Snowflake

GitHub 地址:https://github.com/twitter/snowflake

Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同。

snowflake的结构如下(用-分开):

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

第一位为未使用,接下来的41位为毫秒级时间(41位的长度可以使用69年),然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点) ,最后12位是毫秒内的计数(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)

一共加起来刚好64位,为一个Long型。(转换成字符串长度为18)

snowflake生成的ID整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由datacenter和workerId作区分),并且效率较高。据说:snowflake每秒能够产生26万个ID。

基于redis的分布式ID生成器

GitHub 地址:https://github.com/hengyunabc/redis-id-generator

依赖redis的EVAL,EVALSHA两个命令,利用redis的lua脚本执行功能,在每个节点上通过lua脚本生成唯一ID。 生成的ID是64位的:

  • 使用41 bit来存放时间,精确到毫秒,可以使用41年。
  • 使用12 bit来存放逻辑分片ID,最大分片ID是4095
  • 使用10 bit来存放自增长ID,意味着每个节点,每毫秒最多可以生成1024个ID

Redis提供了TIME命令,可以取得redis服务器上的秒数和微秒数。因些lua脚本返回的是一个四元组。

second, microSecond, partition, seq

客户端要自己处理,生成最终ID。

((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;

在redis-id-generator-java目录下,有example和benchmark代码,提供了 Java客户端生成模式,其它语言只要支持redis evalsha命令就可以了。

MongoDB的ObjectId

Mongodb集合中的每个document中都必须有一个"_id"键,这个键的值可以是任何类型的,在默认的情况下是个Objectid对象。mongodb的ObejctId生产思想在很多方面挺值得我们借鉴的,特别是在大型分布式的开发,如何构建轻量级的生产,如何将生产的负载进行转移,如何以空间换取时间提高生产的最大优化等等。

网上有篇文章分析的还可以推荐给大家http://www.blogjava.net/dongbule/archive/2011/06/12/352138.html

你不得不知的几个互联网ID生成器方案

服务化、分布式已成为当下系统开发的首选,高并发操作在数据存储时,需要一套id生成器服务,来保证分布式情况下全局唯一性,以确保系统的订单创建、交易支付等场景下数据的唯一性,否则将造成不可估量的损失。 ...
  • hero272285642
  • hero272285642
  • 2018-01-26 09:17:11
  • 179

区块链,你不得不知的真相

  • 2018年02月27日 11:49
  • 2.13MB
  • 下载

男人应该学会的100句话【实用】

男人应该学会的100句话【实用】1。我想在五十年之后我一定还是像现在一样爱你 2。我不要短暂的温存, 只要你一世的陪伴 3。只因你太美好令我无法坦白说出我爱你 4。我的猫很皮,可不可以帮我管它… 5。...
  • ahpo
  • ahpo
  • 2006-04-12 16:19:00
  • 714

小知识 | 机器学习:不得不知的概念(2)

本文通过一个例子说明什么是机器学习的泛化能力,理解它有助于你了解机器学习为什么要解决过拟合问题。泛化能力泛化能力(generalization),学得的模型适用于新样本的能力,是非常重要的能力。举个例...
  • yc733uIz
  • yc733uIz
  • 2017-12-21 00:00:00
  • 148

(转)Android之你不可不知道的小知识

Android之你不可不知道的小知识 本文转自:http://www.jianshu.com/p/6ee1fe779fc8 打开软件安装页面一般下载完APK文件之后,都要打开软件安装页面,提示...
  • qq_27650777
  • qq_27650777
  • 2016-07-21 15:08:45
  • 652

职场上不得不知的六大潜规则

  潜规则1 不要苛求百分百的公平  显规则告诉我们要在公平公正的原则下做事,潜规则却说不能苛求上司一碗水端平,尤其是老板更有特权。  孙小明刚进公司做计划部主管时,除了工资,就没享受过另类待遇。一个...
  • Yangcg
  • Yangcg
  • 2007-01-31 10:11:00
  • 628

闪存浪潮下不得不知的知识(3)-技术篇

闪存最明显特点就是稳定/低时延,高IOPS,在评估性能时,我们也会关注90% IO落入规定的时延范围(性能是一个线性范围,而不是某一个点),性能提升、数据保护等追求所有软件特性都基于inline实现。...
  • swingwang
  • swingwang
  • 2016-01-06 23:21:33
  • 949

分布式ID生成器解决方案

一、分布式系统带来ID生成挑战 在复杂的系统中,往往需要对大量的数据如订单,账户进行标识,以一个有意义的有序的序列号来作为全局唯一的ID; 而分布式系统中我们对ID生成器要求又有哪些呢? ...
  • m0_37041378
  • m0_37041378
  • 2017-09-28 17:02:57
  • 1187

分布式系统唯一ID生成方案

分布式系统唯一ID生成方案汇总 系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结。生成ID的方法有很多,适应不同的场景、需求以及性能要求。所以有些比较复杂的系统...
  • lr131425
  • lr131425
  • 2017-05-03 10:08:09
  • 639
收藏助手
不良信息举报
您举报文章:不得不知的几个互联网ID生成器方案
举报原因:
原因补充:

(最多只允许输入30个字)