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.EthernetAddress;
import com.fasterxml.uuid.Generators;
import com.fasterxml.uuid.impl.TimeBasedGenerator;

public class KeyUtil {

	public static String generatorUUID(){
		TimeBasedGenerator timeBasedGenerator = Generators.timeBasedGenerator(EthernetAddress.fromInterface());
		return timeBasedGenerator.generate().toString();
	}

	public static void main(String[] args) {
		System.err.println(KeyUtil.generatorUUID());
		System.err.println(KeyUtil.generatorUUID());
	}
}

  

以下两种方式都不合适:

原文地址:https://www.cnblogs.com/sunliyuan/p/11110018.html

时间: 2024-07-30 08:43:19

Disruptor分布式id生成策略的相关文章

分布式ID生成策略 &middot; fossi

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

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

1. SequenceID 数据库自增列,最常见的方式.由数据库维护,数据库唯一. 优点: 1)简单,代码方便,性能可以接受. 2)数字ID天然排序,对分页或者需要排序的结果很有帮助. 缺点: 1)数据迁移或者合库麻烦. 2)分表分库的时候麻烦. 改进方案: 通过设置各数据库的步长,或者通过HASH进行分表. 2. GUID 微软对UUID这个标准的实现.UUID(Universally Unique Identifier)的标准型式包含32个16进制数字,以连字号分为五段,形式为8-4-4-4

业务ID 生成策略

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

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

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

分布式ID生成方案

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

数据库主键ID生成策略

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

分布式ID生成

在看代码的时候遇到一个snowflake算法,查了一下发现是Twitter的一个分布式ID生成算法,能够在分布式环境中生成一个全局唯一的ID,然后上网找了一些业界的做法,目前看到了携程和美团的方案,做一下笔记. 背景1 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识.如在美团点评的金融.支付.餐饮.酒店.猫眼电影等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的自增ID显然不能满足需求:特别一点的如订单.骑手.优惠券也都需要有唯一ID做标识

详解分布式系统中的唯一id生成策略

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,也常常为这个问题而纠结.生成ID的方法有很多,适应不同的场景.需求以及性能要求.所以有些比较复杂的系统会有多个ID生成的策略.下面就介绍一些常见的ID生成策略. 平常应用中方式很多 1. 数据库自增长序列或字段 2. UUID 3.uuid的变种 4.redis生成 5. Twitter的snowflake算法 snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID.其核心思想是:使用41bit作为毫秒数,1

融云技术分享:解密融云IM产品的聊天消息ID生成策略

本文来自融云技术团队原创分享,原文发布于“融云全球互联网通信云”公众号,原题<如何实现分布式场景下唯一 ID 生成?>,即时通讯网收录时有部分改动. 1.引言 对于IM应用来说,消息ID(或称序列号)是个看似不起眼,但非常重要的东西之一. 消息ID的使用贯穿了IM技术逻辑的方方面面,比如: 1)聊天消息的顺序保证: 2)聊天消息QoS送达保证机制时的去重: 3)特定聊天消息的精确查找和匹配: 4)聊天消息的已读未读处理: 5)聊天消息的送达回执: 6)群聊消息的扩散读拉取标记: 7)... .