精华内容
下载资源
问答
  • 数据库唯一序列号生成方案

    千次阅读 2017-12-22 14:49:23
    首先,我们得知道为什么需要制定数据库唯一序列号生成方案,难道MySQL的主键自增长不好用吗?当然不是。由于现在的业务数据量越来越大,有时候将数据放在一张表里,压力非常大,所以要进行分库分表。一旦进行了分库...

      首先,我们得知道为什么需要制定数据库唯一序列号生成方案,难道MySQL的主键自增长不好用吗?当然不是。由于现在的业务数据量越来越大,有时候将数据放在一张表里,压力非常大,所以要进行分库分表。一旦进行了分库分表,用MySQL自带的自增长主键就会有问题了。如何保证生成一个唯一的不重复的主键,这是一个严肃的问题。
      我今天介绍一种方案,也是我公司的实现方案之一。几个模块如下:
    1. 先定义一张表,结构如下:
    序列信息表
    biz_code:表示业务表的编码
    max_id:当下可以达到的最大的id
    offset:偏移量,即每次库里的id达到最大值后的偏移量
    2. 再定义一个执行过程,代码如下:

    CREATE DEFINER=`sequ`@`%` PROCEDURE `PROC_SEQUENCE_ID`(IN bizCode varchar(50))
    BEGIN
      DECLARE t_error INTEGER DEFAULT 0;  
      DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET t_error=1;  
    
       START TRANSACTION;  
       UPDATE sequence SET max_id=max_id+offset WHERE biz_code= bizCode;
       SELECT max_id, offset,biz_code FROM sequence WHERE biz_code=bizCode;
    
       IF t_error = 1 THEN  
        ROLLBACK;  
       ELSE  
        COMMIT;  
       END IF;  
         END

    执行过程逻辑很简单,就是将max_id加上(偏移)offset大小。
    3. 最后定义一个双缓冲队列,以生产者-消费者模型分发id。

    也许单纯看模块,大家一头雾水,也不知道这讲的是啥。我再说明一下过程:
    1. 项目启动前,先将表的序列信息入库。如:
    biz_code = ‘USER’
    max_id = 10
    offset = 100
    2. 初始化双缓冲队列,用一个ConcurrentHashMap来维护。
    3. 第一次获取id时,由于读队列为空,则读写队列交换身份,运行数据库执行过程(max_id变成110),往写队列里放入值(如在USER表中,就是11-100这个区间的值)。由于是第一次,则之前的写队列也是空的,则重复这个过程,然后获取到id。
    4. 在以后获取id的过程中,每当读队列为空时,则读写队列交换身份,运行数据库执行过程,往写队列里放入值。

      这个方案简单但管用,其中用到了一种数据结构,叫双缓冲队列,这里简单介绍一下。双缓冲队列的核心思想就是读写分离,传统队列是生产者线程和消费者线程从同一个队列中存取数据,必然需要互斥访问,在互相同步等待中浪费了宝贵的时间,使队列吞吐量受影响。双缓冲队使用两个队列,将读写分离,一个队列专门用来读,另一个专门用来写,当读队列空或写 队列满时将两个队列互换。这里为了保证队列的读写顺序,当读队列为空且写队列不为空时候才允许两个队列互换。

      当然,很多时候会再生成一个字符串作为code。这个时候只要定好位数,然后给每一段标注意义,如:8位年月日 | 2位系统编号 | 2位业务单号 | 序列号10位不足前面补0 | 2位分库号。这个过程依旧可以用到上面生成序列号的方式。

    展开全文
  • 数据库唯一id生成策略

    千次阅读 2019-03-24 00:03:55
    分布式,高并发下id生成要求 全局唯一 趋势递增 效率高(生成.使用....控制并发 一 . Uuid(uuid/guid[通用唯一识别码]) ...全局唯一的ieee机器识别号(如果有网卡,从网卡获取,没有网卡以其他方式获取) ...

    分布式,高并发下id生成要求

    全局唯一
    趋势递增
    效率高(生成.使用.索引)
    控制并发
    

    一 . Uuid(uuid/guid[通用唯一识别码])

    Uuid是按照开放软件基金会(osf)制定的标准计算
    用到了以太网开地址(MAC),纳米级时间,芯片id码和许多可能的数字
    

    由一下几部分的组成

    当前日期和时间
    时钟序列
    全局唯一的ieee机器识别号(如果有网卡,从网卡获取,没有网卡以其他方式获取) 
    生成长度为36的字符串
    

    优缺点:

    优点:
    	使用简单
    	不依赖其他组件
    	不影响数据库拓展
    
    缺点:
    	数据库索引效率低
    	太过于无意义.用户不友好
    	长度36的字符串,空间占用大
    	应用集群环境,机器多的时候,重复几率大
    

    二 . Mysql整型自增

    Mysql 整型自增索引之所以快是因为mysql 采用b+树对整型进行了加速
    Mysql使用auto_increment, oracle使用sequence序列
    集群环境下,不同的库,设置不同的初始值,每次自增加 100
    Mysql下修改起点和步长的方式
         设置起点
         	Set @@auto_increment_offset=1   // 设置起点为1
         设置步长
         	Set@@auto_increment_increment=100  // 设置步长为100
         查看参数
         	show VARIABLES like 'auto_%'  // 查看参数
    

    以上主要用于分表的时候

    在这里插入图片描述

    优缺点:

    优点:
        无需编码
        性能也过得去
    	索引友好
    
    缺点:
       	大表不能做水平分表,否则插入删除易出现问题(已经存在很大数据的时候再分表,容易出现问题)
       	依赖前期规划,拓展麻烦
       	依赖mysql内部维护自增锁,高并发下插入数据影响性能
       	在业务操作父,子(关联表)插入时,要先父表 后子表
    

    相对于uuid 其实 数据库自增表的效率稍低

    特点是 : 互斥 排他 可重入

    三 . 雪花算法(twitter 的 snowflake算法)

    Snowfake算法是twitter’开源的分布式id生成算法,结果就是long长整型的id
    

    在这里插入图片描述

    Twitter 的雪花算法 产生的是一个 64位的长整型
    	第一位未使用,固定为0
       	接下来41位为毫秒级时间,41位的长度可以使用69年
      	然后是10位节点id,最多支持部署1024个节点,(一般是数据中心编号和机器编号组成)
      	最后12位是毫秒内单位的算法调用计数,(意味着每个节点每毫秒产生4096个id序号)
       	上面4部分加起来是64比特位 = 8 字节 =Long(转换成字符串后长度最多为19)
    

    优缺点:

    优点:
    	性能较优,速度快
    	无需第三方依赖,实现也简单
    	可以根据实际情况调整和拓展算法,方便灵活  (开源)
    缺点:
    	依赖时间机器,如果发生回拨会导致生成id重复,业界使用一般是根据雪花算法进行拓展的(可以把这个服务单独做成一个服务用于生成id,但是会连累生成效率)
    

    四 . Redis

    Java 中 基本类型所占的字节
    Oracle 产生序列号的方式
    

    思路:

    利用增长计数api,业务系统在自增长的基础上,配合其他信息组成一个唯一id
    Redis的incr(key) api用于将key的值进行递增,并返回增长数值
    如果key不存在,则创建并赋值为0
    
    利用redis的特性: 单线程原子操作,自增计数api,数据有效机制ex
    

    实例:

    业务编码+地区+自增数值
    

    key的命名规范:

    系统名:+ 模块:+ 功能: + key  例如: 163:study:order:id
    

    优缺点:

    优点:
    	拓展性强,可以方便的结合业务进行处理
    	利用redis操作原子性的特征,可以保证在并发的时候不会重复
    
    缺点:
    	引入redis就意味着引入其他三方依赖
    	增加一侧网络开销
    	需要对reids服务实现高可用
    

    高可用:

    自动分片
    哨兵模式
    

    注意: 集群并不能做高可用,因为redis集群中没有选举机制,所以需要采用哨兵(选举的机制)的机制配置高可用

    各方案对比:

    方式 优点 缺点
    Uuid 实现简单,不占带宽 无序,占空间,可读性差,索引不友好
    数据库自增 无代码调整,递增 db单点故障,扩展性瓶颈
    雪花算法 性能优,不占带宽,趋势递增 依赖服务器时间
    基于redis自研 无单点故障(高可用后),性能优于db,低于uuid和雪花算法,递增,扩展性强 占用带宽,redis集群维护

    遵循 cap base 理论

    在这里插入图片描述
    在这里插入图片描述

    五 . 总结

    Id的无序:

    Id已经给你了 ,现在只要找到一种方式打乱,然后打乱后又可以复原,就ok 了
    
    展开全文
  • 唯一编号算法:生成GUID

    千次阅读 2019-05-02 22:04:20
    你有过生成不重复编号的想法吗?比如做一个自动保存网页图片的工具,要保证保存的图片不互相覆盖,一个想法是使用一个计数器从1开始递增,但是这样还有问题,比如我们无法保证磁盘中以前没有可能造成重复的图片文件...

    你有过生成不重复编号的想法吗?比如做一个自动保存网页图片的工具,要保证保存的图片不互相覆盖,一个想法是使用一个计数器从1开始递增,但是这样还有问题,比如我们无法保证磁盘中以前没有可能造成重复的图片文件。

    那么就来看看GUID算法吧。
    GUID(全局统一标识符)是指在一台机器上生成的数字,它保证对在同一时空中的所有机器都是唯一的。它使用网卡MAC、地址、纳秒级时间、芯片ID码和许多可能的数字,这样保证每次生成的GUID永远不会重复,无论是同一个计算机上还是不同的计算机。
    GUID长什么样呢?
    {C7B1AFCC-810E-46d0-8157-09FC488D4C71}
    看起来挺古怪的吧。在 Windows 平台上,GUID 应用非常广泛:注册表、类及接口标识、数据库、甚至自动生成的机器名、目录名等。
    不用担心GUID的性能问题,因为它生成过程是采用MAC地址、机器时钟等计算的,没有并发问题,所以它一点都不比自增计数器的慢,有时候甚至更快。

    讲了一大堆理论,在程序中怎么生成GUID呢?
    非常简单,调用CoCreateGuid函数即可,它定义在objbase.h这个头文件中。
    核心调用代码:

    //--生成GUID
    void generate_guid(TCHAR* guid_string)
    {
     GUID guid;
     strcpy(guid_string,"");
     
     if( CoCreateGuid(&guid) == S_OK)
     {    
       _stprintf(guid_string, TEXT("{%08X-%04X-%04x-%02X%02X-%02X%02X%02X%02X%02X%02X}"), 
        guid.Data1, 
        guid.Data2, 
        guid.Data3, 
        guid.Data4[0], 
        guid.Data4[1], 
        guid.Data4[2], 
        guid.Data4[3], 
        guid.Data4[4], 
        guid.Data4[5], 
        guid.Data4[6], 
        guid.Data4[7]);

     }
     return ;
    }

     

    CoCreateGuid需要一个GUID结构体指针作为参数,GUID中有很多域,按照我给的方法把GUID打印成字符串即可。
    GUID 可以用在很多的场合下,比如防止网站文章被小偷程序采集,比如一个查看文章的页面是 article.aspx?id=1,那么我可以写一个循环,就能够把所有的文章都采集过来。而如果使用GUID的话article.aspx?id=xxxx-xxxxxxxx-xxxx-xxxx,那么简单的循环就不行了,因为我无法预测下一个GUID是什么。

     

    Guid全局唯一性算法

    下面以Lua为例实现guid的生成,再对比nginx服务器的MD5算法进行比对效率
    
    function guid()
        local seed = {
                '0','1','2','3','4','5','6','7','8','9',
                'a','b','c','d','e','f','g','h','i','j',
                'k','l','m','n','o','p','q','r','s','t',
                'u','v','w','x','y','z'
        }
    
        local sid = ""
        for i=1, 32 do
            sid = sid .. seed[math.random(1,36)]
        end
    
        return string.format('%s-%s-%s-%s-%s',
            string.sub(sid, 1, 8),
            string.sub(sid, 9, 12),
            string.sub(sid, 13, 16),
            string.sub(sid, 17, 20),
            string.sub(sid, 21, 32)
        )
    end
    local s = 0
    local start = socket.gettime()
    
    while s < 100000 do
        s=s+1
        --ngx.print(ngx.md5(math.random(1,36)) .. '\r\n')
        ngx.print(guid() .. '\r\n')
    end
    
    ngx.print("execute time:" .. socket.gettime()-start .. '\r\n')
    ngx.exit(200)

    代码

    上面guid方法中seed读者可以自己自行扩展,比如再加入'A-Z'大写字符,guid我以32位的字符进行输出,

    在实际测试过程中, 10万级的数据生成速度不考虑写文件的IO时间,远远低于0.4秒,而同等数量使用ngx.md5()时则足足多了一倍的时间;

    再从唯一性上进行分析,10万级的生成串中,测试了10次,没有发现任何一次有重复的字符串,说明自配的guid算法足以满足实际生产使用;

    展开全文
  • 分布式服务中经常会遇到这样的业务场景: l 一些服务发送消息到队列,另一些服务从队列消费消息,消息可能会重复,消费端需要做幂等,为了达到业务的幂等,希望有...工作中有很多方式可以生成唯一且趋势递增的id编...

    个人博客请访问 http://www.x0100.top  

    分布式服务中经常会遇到这样的业务场景:

    l  一些服务发送消息到队列,另一些服务从队列消费消息,消息可能会重复,消费端需要做幂等,为了达到业务的幂等,希望有一个不能重复且趋势递增的编号存在;

    l  分库分表中需要生成不能重复且趋势递增的产品编号或者订单编号;

    为此,生成编号的机制需要满足如下条件:

    l  局部、全局唯一。

    l  趋势递增。

    工作中有很多方式可以生成唯一且趋势递增的id编号, 适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。

    一、数据库自增长序列或字段

    最常见的方式。利用数据库,全数据库唯一。

    优点:

    1)简单,代码方便,性能可以接受。

    2)数字ID天然排序,对分页或者需要排序的结果很有帮助。

    缺点:

    1)不同数据库语法和实现不同,数据库迁移的时候或多数据库版本支持的时候需要处理。

    2)在单个数据库或读写分离或一主多从的情况下,只有一个主库可以生成。有单点故障的风险。

    3)在性能达不到要求的情况下,比较难于扩展。

    4)如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。

    5)分表分库的时候会有麻烦。

    优化方案:

    针对主库单点,如果有多个Master库,则每个Master库设置的起始数字不一样,步长一样,可以是Master的个数。比如:Master1 生成的是 1,4,7,10,Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID,也可以大大降低ID生成数据库操作的负载。

    封装成单个服务,一次生成一定数量的编号存储到数据库表或者缓存中,需要id编号的服务调用生成服务挨个获取。

    二、UUID

    常见的方式。可以利用数据库也可以利用程序生成,一般来说全球唯一。

    优点:

    1)简单,代码方便。

    2)生成ID性能非常好,基本不会有性能问题。

    3)全球唯一,在遇见数据迁移,系统数据合并,或者数据库变更等情况下,可以从容应对。

    缺点:

    1)没有排序,无法保证趋势递增。

    2)UUID往往是使用字符串存储,查询的效率比较低。

    3)存储空间比较大,如果是海量数据库,就需要考虑存储量的问题。

    4)传输数据量大

    5)不可读。

     三、 UUID的变种

    1)为了解决UUID不可读,可以使用UUID to Int64的方法。

    2)为了解决UUID无序的问题,NHibernate在其主键生成方式中提供了Comb算法(combined guid/timestamp)。保留GUID的10个字节,用另6个字节表示GUID生成的时间(DateTime)。

    用上面的算法测试一下,得到如下的结果:作为比较,前面3个是使用COMB算法得出的结果,最后12个字符串是时间序(统一毫秒生成的3个UUID),过段时间如果再次生成,则12个字符串会比图示的要大。后面3个是直接生成的GUID。

    如果想把时间序放在前面,可以生成后改变12个字符串的位置,也可以修改算法类的最后两个Array.Copy。

    四. Redis生成ID

    当使用数据库来生成ID性能不够要求的时候,我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的,所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

    可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5,然后步长都是5。各个Redis生成的ID为:

    A:1,6,11,16,21

    B:2,7,12,17,22

    C:3,8,13,18,23

    D:4,9,14,19,24

    E:5,10,15,20,25

    这个,随便负载到哪个机确定好,未来很难做修改。但是3-5台服务器基本能够满足器上,都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以方式单点故障的问题。

    另外,比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key,使用INCR进行累加。

    优点:

    1)不依赖于数据库,灵活方便,且性能优于数据库。

    2)数字ID天然排序,对分页或者需要排序的结果很有帮助。

    缺点:

    1)如果系统中没有Redis,还需要引入新的组件,增加系统复杂度。

    2)需要编码和配置的工作量比较大。

    五. Twitter的snowflake算法

    snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是0。具体实现的代码可以参看(https://github.com/twitter/snowflake)

    测试代码如下:

    snowflake算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数,每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的bit数。

    优点:

    1)不依赖于数据库,灵活方便,且性能优于数据库。

    2)ID按照时间在单机上是递增的。

    缺点:

    1)在单机上是递增的,但是由于涉及到分布式环境,每台机器上的时钟不可能完全同步,也许有时候也会出现不是全局递增的情况。

    六. 利用zookeeper生成唯一ID 

    zookeeper主要通过其znode数据版本来生成序列号,可以生成32位和64位的数据版本号,客户端可以使用这个版本号来作为唯一的序列号。

    很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper,并且是多步调用API,如果在竞争较大的情况下,需要考虑使用分布式锁。因此,性能在高并发的分布式环境下,也不甚理想。

    七. MongoDB的ObjectId

    MongoDB的ObjectId和snowflake算法类似。它设计成轻量型的,不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库,处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。

    其格式如下:

    前4 个字节是从标准纪元开始的时间戳,单位为秒。时间戳,与随后的5 个字节组合起来,提供了秒级别的唯一性。由于时间戳在前,这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用,如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。 

    接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId,不产生冲突。 

    为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的,接下来的两字节来自产生ObjectId 的进程标识符(PID)。 

    前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。后3 字节就是一个自动增加的计数器,确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563(16 777 216)个不同的ObjectId。

    关注微信公众号和今日头条,精彩文章持续更新中。。。。。

     

     

    展开全文
  • D作为业务的唯一标识,在数据设计中屡见不鲜,例如: •商品 —— product_id •订单 —— order_id •消息 —— message_id 这些标识往往就是数据库的主键,MySQL会在主键是建立聚簇索引,这个...
  • oracle创建视图与生成唯一编号

    千次阅读 2018-09-23 08:44:58
    Oracle的数据库对象分为五种:表,视图,序列,索引和同义词。 一、视图 视图是基于一个表或多个表或视图的逻辑表,本身不包含数据,通过它可以对表里面的数据进行查询和修改。视图基于的表称为基表。 视图的优点...
  • 本篇博文是“Java秒杀系统实战系列文章”的第七篇,在本博文中我们将重点介绍 “在高并发,如秒杀的业务场景下如何生成全局唯一、趋势递增的订单编号”,我们将介绍两种方法,一种是传统的采用随机数生成方式,...
  • 生成唯一编号的方法

    千次阅读 2019-02-21 09:39:51
    作者:杨裙 本次任务完成时间:2019年2...1、在数据库查询出最后一条数据,自动生成有序编号,控制器的代码: 2、页面的代码(用post的方法提交,然后给需要生成的文本框赋值): 3、效果图: 二、第二种方法(获...
  • 在系统开发中,保证数据的唯一性是至关重要的一件事,目前开发中常用的方式有使用数据库的自增序列、UUID生成唯一编号、时间戳或者时间戳+随机数等。 在某些特定业务场景中,可能会要求我们使用特定格式的唯一编号...
  • 记录下实际开发中遇到生成唯一有序的编号需求如ZZ190500001末尾自增,一开始想到数据库生成但是过于麻烦就直接把这个想法给干掉,之后想了一圈 想到想到了Redis incr命令。 一、了解Redis Incr 命令 Redis Incr ...
  • 创建配置表:CREATE TABLE `sys_seq_ctrl` ( `seq_type` varchar(50) NOT NULL COMMENT '类型', `seq_title` varchar(50) NOT NULL COMMENT '描述', `seq_by` char(1) NOT NULL COMMENT '编号产生方式:S顺序号,...
  • 用volatile生成自动唯一编号代码public class OrderNoUtils { /** * 时间格式化 */ protected static final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd"); /** 基金订单编号 */ ...
  • 生成订单编号的功能。 网友指点了一下可以简单的使用 uuid 来做,但是 uuid 产生的是一个不重复的字符串。用来当做订单编号,显然不太合适。但是我们可以换个底版,来让它变成一组数字。 原理其实很简单,就是...
  • 如何根据当前时间生成唯一编号

    万次阅读 2015-08-26 09:32:10
    是当前时间的唯一编号……     System.currentTimeMillis() 只是获取当前的时间戳,单位是毫秒,但是这并不是唯一的.  如果你在1毫秒中进行了两次操作,那么这两个ID就是相等的.  问题的解决看你...
  • 属性并没有保证所生成的序列值是唯一的。但是, PRIMARY KEY 约束保证了表中行的唯一性。为了确保只将自动生成的值插入标识列,他们指定了 GENERATED ALWAYS 子句。在每个季度结束时,Widget 公司使用最后一个...
  • SQLServer中自动生成唯一订单编号

    千次阅读 2012-06-17 03:47:30
    项目开发中,需要订单功能,本来想前台使用c#自动生成订单编号,但是功力尚浅不敢保证在高并发的情况下不重复,无奈转到数据库使用存储过程自动生成订单编号,如下 创建表 TBL_OrderNumber create table TBL_...
  • 生成列(包括标识列)是 DB2 的一个重要的特性,用来自动生成列值。一个生成列的值不是由 INSERT 或者 UPDATE 操作派生,而是根据预定义由 DB2 自动生成。在应用程序中,用户可以根据不同的需求选择不同的生成列从而...
  • 分布式锁实现生成唯一订单编号

    千次阅读 2018-12-14 12:30:35
    使用CountDownLatch测试生产分布式锁唯一订单编号 import com . al . lock . service . ILock ; import com . al . lock . service . impl . OrderFactory ; import com . al . lock . service . impl ....
  • 全局唯一id的4种生成策略:UUID、数据库递增、snowflake、Redis 全局唯一性id保证的4个要求:全局唯一、数据递增、信息安全、高并发高可用 ---a.全局唯一:不能出现重复的id号; ---b.数据递增:保证下一个id一定...
  • Java生成唯一标识码的三种方式

    万次阅读 2018-09-17 17:06:50
    需要生成一个唯一的序列号来表明某一个数据的唯一性,在单节点的应用中我们可以简单地使用一个自增的整型来实现实现,但是在分布式情况下这个方式却存在冲突的可能性,那么有什么办法我们可以生成一个唯一的序列号呢...
  • 1. 当保存一个入库单据时,如何让单据号(带有字母和数字的字符串)自动生成唯一; 2. 当单据号和服装编号相同,怎么让两行的数据合并,且入库数量相加; 3. 问题1和2不知道可否在powerdesigner进行设置? 对...
  • 数据库中,唯一ID一般是用来作为一个数据的主键。看过前面介绍MySQL索引原理的文章的朋友应该知道,主键对于数据库的重要性不言而喻。 在单机场景下,要得到一个全局唯一的ID是非常容易的,你可以使用数据库的...
  • 导读: 今天再搞exchagne的时候,发现一个 guid ,上网查了下,原来如此 GUID(全局统一标识符)是指在一台机器上生成的数字,它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成GUID的API。生成算法很...
  • 浅谈分布式唯一ID生成策略

    千次阅读 2019-03-27 18:19:54
    背景 ...有序性,通常都需要保证生成的 ID 是有序递增的。例如,在数据库存储等场景中,有序 ID 便于确定数据位置,往往更加高效。 从上面的场景中我们不由想到线程安全的问题,很多人想到...
  • 使用auto_increment的字段可能生成唯一的标识。大家都经常用到,只知道mysql可以保证这个字段在多进程操作时的原子性,具体原理又是什么呢? 使用规范 AUTO_INCREMENT是数据列的一种属性,只适用于整数类型数据列。...
  • 唯一id生成算法

    千次阅读 2019-05-11 21:37:19
    文章目录UUID 和 GUID数据库自增主键数据库自增主键优化数据库自增主键再优化时间戳snowflake算法为递增的优势 ​ 我们在很多情况下都需要用到一个唯一标识,比如一个用户id,一个订单号等等。因此,我们需要设计一...
  • 《分布式数据库中全局唯一主键生成策略的设计与实现》 《activiti5.10解决分布式集群部署的主键问题》 《分布式环境下数据库主键方案》 《如何在高并发分布式系统中生成全局唯一Id》 《分布式环境下ID生成方法总结》...
  • ASP.NET 生成唯一不重复的订单号 支持多用户并发、持多数据库的实现参考(C#.NET通用权限管理系统组件源码组成部分) 我们在日常开发项目过程中往往需要各种订单单号的产生方法,而且是支持多用户并发、支持多种...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,152
精华内容 18,460
关键字:

数据库唯一编号生成方式