业内方案简介

1. UUID方案

优点：

能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响。

保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。

缺点：

1. 性能为题：UUID太长，通常以36长度的字符串表示,对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能

2. UUID无业务含义：很多需要ID能标识业务含义的地方不使用

3.不满足递增要求

2. snowflake方案

snowflake是twitter开源的分布式ID生成系统。 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的缺点是:

强依赖时钟,如果主机时间回拨,则会造成重复ID,会产生
ID虽然有序,但是不连续

snowflake现在有较好的改良方案,比如美团点评开源的分布式ID框架：leaf，通过使用ZooKeeper解决了时钟依赖问题。

详细见源码：SnowflakeIdWorker

3. 基于数据库方案

利用数据库生成ID是最常见的方案。能够确保ID全数据库唯一。其优缺点如下：

优点：

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

缺点:

不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
在性能达不到要求的情况下，比较难于扩展。
如果涉及多个系统需要合并或者数据迁移会比较麻烦。
分表分库的时候会有麻烦。

4.其他方案简介

通过Redis生成ID(主要通过redis的自增函数)、ZooKeeper生成ID、MongoDB的ObjectID等均可实现唯一性的要求

三、我们在实际应用中经历的方案

1. 方案简介

实际业务中，除了分布式ID全局唯一之外，还有是否趋势/连续递增的要求。根据具体业务需求的不同，有两种可选方案。

一是只保证全局唯一，不保证连续递增。二是既保证全局唯一，又保证连续递增。

2. 基于ZooKeeper和本地缓存的方案

基于zookeeper分布式ID实现方案有很多种,本方案只使用ZooKeeper作为分段节点协调工具。每台服务器首先从zookeeper缓存一段,如1-1000的id,

此时zk上保存最大值1000,每次获取的时候都会进行判断,如果id<=1000,则更新本地的当前值,如果为1001,则会将zk上的最大值更新至2000,本地缓存

段更新为1001-2000,更新的时候使用curator的分布式锁来实现。

由于ID是从本机获取，因此本方案的优点是性能非常好。缺点是如果多主机负载均衡,则会出现不连续的id,当然将递增区段设置为1也能保证连续的id,

3.利用zk的永久自增节点策略实现持续递增ID

使用zk的永久sequence策略创建节点,并获取返回值,然后删除前一个节点,这样既防止zk服务器存在过多的节点,又提高了效率;节点删除采用线程池来统一处理,提高响应速度

优点:能创建连续递增的ID,又能降低ZK消耗。

测试结果如下,生成10000个ID消耗=9443ms(两个线程耗时较长者), 平均每个ID=0.9ms

这还只是单zk连接的情况下,如果使用连接池来维护多个zk的链接,效率将成倍的提升

感谢分享，原链接：

https://blog.csdn.net/m0_37041378/article/details/78125747

细聊分布式ID生成方法-2相关推荐

细聊分布式ID生成方法
2019独角兽企业重金招聘Python工程师标准>>> 一.需求缘起几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:o ...
细聊分布式ID生成方法-1
一.需求缘起几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:order-id (3)帖子标识:tiezi-id 这个记录标识往往就是数据 ...
.Net 互联网技术（一）分布式ID生成方法生成演变
.Net 互联网技术(一)分布式ID生成方法生成演变一.需求缘起转载至几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:order-id ...
全局唯一递增的id_分布式ID生成方法－趋势有序的全局唯一ID
一.需求缘起几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:order-id (3)帖子标识:tiezi-id 这个记录标识往往就是数据 ...
分布式ID | 这六种分布式ID生成方法，总有一款适合你
Hi!我是小小,我们又见面了,我们今天的话题是六种分布式ID生成算法. 分布式ID简介什么是分布式ID 在数据量不大的时候,单库单表完全可以支撑现有业务,数据量再大一点搞个MySql主从同步也可以. ...
分布式ID生成的9种方法，特好用！
前言业务量小于500W或数据容量小于2G的时候单独一个mysql即可提供服务,再大点的时候就进行读写分离也可以应付过来.但当主从同步也扛不住的是就需要分表分库了,但分库分表后需要有一个唯一ID来标识 ...
美团技术分享：深度解密美团的分布式ID生成算法
本文来自美团技术团队"照东"的分享,原题<Leaf--美团点评分布式ID生成系统>,收录时有勘误.修订并重新排版,感谢原作者的分享. 1.引言鉴于IM系统中聊天消息I ...
分布式id生成策略，我和面试官扯了一个半小时
面试官:小伙子,你还记得我吗?我是上次面试你的那个面试官. 我心想:我去,怎么会不记得,我又不是青年痴呆,上次害我画了那么多图,还使劲敲了一个多钟的电脑,满脑子都是你的阴影. 我:记得记得,您好,很高 ...
滴滴开源的分布式id生成系统
ID Generator id生成器分布式id生成系统,简单易用.高性能.高可用的id生成系统简介 Tinyid是用Java开发的一款分布式id生成系统,基于数据库号段算法实现,关于这个算法可以参 ...

细聊分布式ID生成方法-2