【数据库】总结常用分布式ID生成策略

1. SequenceID

数据库自增列,最常见的方式。由数据库维护,数据库唯一。

优点:

1)简单,代码方便,性能可以接受。
2)数字ID天然排序,对分页或者需要排序的结果很有帮助。

缺点:

1)数据迁移或者合库麻烦。
2)分表分库的时候麻烦。

改进方案:

通过设置各数据库的步长,或者通过HASH进行分表。

2. GUID

微软对UUID这个标准的实现。UUID(Universally Unique Identifier)的标准型式包含32个16进制数字,以连字号分为五段,形式为8-4-4-4-12的36个字符。

优点:

1)性能非常高:本地生成,没有网络消耗。
2)全球唯一,在数据迁移,合并,变更等情况下,可以从容应对。

缺点:

1)无序,无法保证趋势递增.。
2)往往是使用字符串存储,查询的效率比较低.。
3)存储空间比较大,如果是海量数据库,就需要考虑存储量的问题。
4)无含义,不可读。

改进方案:

1)增加时间戳,使GUID有序。
2)增加数据库描述,使GUID可读。

3. Twitter的snowflake算法

优点:

1)不依赖于数据库,灵活方便,且性能优于数据库。
2)ID按照时间在单机上是递增的。

缺点:

1)强依赖机器时钟,如果机器上时钟回拨,会导致发号重复或者服务会处于不可用状态。
2)在单机上是递增的,但是由于涉及到分布式环境,每台机器上的时钟不可能完全同步,也许有时候也会出现不是全局递增的情况。

4. Leaf 美团点评的分布式ID生成系统

原文地址:https://www.cnblogs.com/tWX173908/p/9934302.html

时间: 2024-08-30 04:10:51

【数据库】总结常用分布式ID生成策略的相关文章

分布式ID生成策略 · fossi

分布式环境下如何保证ID的不重复呢?一般我们可能会想到用UUID来实现嘛.但是UUID一般可以获取当前时间的毫秒数再加点随机数,但是在高并发下仍然可能重复.最重要的是,如果我要用这种UUID来生成分表的唯一ID的话,重复不谈,这种随机的字符串对于我们的innodb存储引擎的插入效率是很低的.所以我们生成的ID如果作为主键,最好有两种特性:分布式唯一和有序. 唯一性就不用说了,有序保证了对索引字段的插入的高效性.我们来具体看看ShardingJDBC的分布式ID生成策略是如何保证. snowfla

Disruptor分布式id生成策略

需要的pom文件: <!-- 顺序UUID --> <dependency> <groupId>com.fasterxml.uuid</groupId> <artifactId>java-uuid-generator</artifactId> <version>3.1.4</version> </dependency> 有时间顺序: import com.fasterxml.uuid.Etherne

业务ID 生成策略

业务ID 生成策略,从技术上说,基本要借助一个集中式的引擎来帮忙实现. 为了扩大业务ID生成策略的并发问题,还有更为技巧性的提升. 先来介绍普遍的分布式ID生成策略: 1. 利用DB的自增主键 这里又有两种做法,一种是 单独创建一个只有自增主键的表,来负责主键自增,业务表从这里取得自增的主键返回给业务主键生成组件使用. 另外一种: 业务中不使用DB的自增主键, 自增主键仅存在DB层面,并增加业务主键字段,并加以约束.这种比较常见. 通常的步骤为: A. Create table `tbl_biz

常见分布式全局唯一ID生成策略

全局唯一的 ID 几乎是所有系统都会遇到的刚需.这个 id 在搜索, 存储数据, 加快检索速度 等等很多方面都有着重要的意义.工业上有多种策略来获取这个全局唯一的id,针对常见的几种场景,我在这里进行简单的总结和对比. 简单分析一下需求 [1] 所谓全局唯一的 id 其实往往对应是生成唯一记录标识的业务需求. 这个 id 常常是数据库的主键,数据库上会建立聚集索引(cluster index),即在物理存储上以这个字段排序.这个记录标识上的查询,往往又有分页或者排序的业务需求.所以往往要有一个t

hibernate 中mysql的id生成策略

数据库的规划和操作号码大全中,咱们一般会给表建立长尾关键词挖掘工具的主键. 主键,可以分为天然主键和署理主键. 天然主键表明:选用具有事务逻辑意义的字段作为表的主键.比方在用户信息表中,选用用户的身份证号码作为主键.可是这样一来,跟着事务逻辑的变化,主键就有可能要更改.比方,假定哪天身份证号码升级成19,2位,那....... 署理主键:在表中人为的添加一个字段,该字段并没有表明任何的事务逻辑,仅仅用来标识一行数据.比方说在用户信息表中,添加一个用户ID的字段.用来表明该条用户信息的记录. 一般

分布式ID生成方案

分布式ID生成方案(分布式数据库) 背景:在互联网应用中,应用需要为每一个用户分配一个id,在使用分布式数据库情况下,已经不能依靠自增主键来生成唯一性id了... 根据特定算法生成唯一ID 可重现的id生成方案:使用用户提供的特定的数据源(登录凭证),通过某种算法生成id,这个过程是可重现的,只要用户提供的数据源是唯一的,那么生成的id也是唯一的. 例如通过用户注册的email+salt,使用摘要算法(md5/sha)生成128bit的数据,然后通过混合因子转变为一个long类型的数据是64bi

Hibernate中ID生成策略

四.ID生成策略 第一种:XML配置ID 通过为<id>元素增加<generator>子元素,该子元素拥有class属性.常用的class属性有: (1)increment:用于为long.short.或者int类型生成唯一标识.只有在没有其他进程往同一张表中插入数据的时候才能使用.在集群不要使用.(极少使用) (2)native:让数据库自动选择identity,sequence,或者其他. (3)uuid:128位的UUID算法,产生String类型ID (4)identity

数据库主键ID生成策略

前言: 系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,下面介绍一些常见的ID生成策略. Sequence ID UUID GUID COMB Snowflake 最开始的自增ID为了实现分库分别的需求,会在自增的前提下,使用不同起点,但需要做数据库拓展时,极其麻烦. 比如刚开始时,我们设计某个系统的数据库时,这个数据库中会有10个表,那么我们对于每个表的内容都需要不同的ID我们就可以使用不同不长自增的形式,比如,第一张表的是1.11.21.31... 第二张表是2.12.22.32..

Hibernate系列之ID生成策略

一.概述 hibernate中使用两种方式实现主键生成策略,分别是XML生成id和注解方式(@GeneratedValue),下面逐一进行总结. 二.XML配置方法 这种方式是在XX.hbm.xml文件中对generator进行配置,eg: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" &qu