snowflake分布式唯一id c#实现

snowflake算法

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

刚刚看到一篇讨论snowflake的文章,之前也看过一些介绍分布式ID生成的算法.但是一直没有用c#实现过.这次正好实现以下.代码的话基本上是翻译了一下那篇文章里的java代码

核心代码如下

var timestamp = TimeGen();

//如果当前时间小于上一次ID生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
if (timestamp < _lastTimestamp)
{
    throw new Exception($"Clock moved backwards.  Refusing to generate id for {_lastTimestamp - timestamp} milliseconds");
}

//如果是同一时间生成的,则进行毫秒内序列
if (_lastTimestamp == timestamp)
{
    _sequence = (_sequence + 1) & _sequenceMask;
    //毫秒内序列溢出
    if (_sequence == 0)
    {
        //阻塞到下一个毫秒,获得新的时间戳
        timestamp = TilNextMillis(_lastTimestamp);
    }
}
//时间戳改变,毫秒内序列重置
else
{
    _sequence = 0L;
}

//上次生成ID的时间截
_lastTimestamp = timestamp;

//移位并通过或运算拼到一起组成64位的ID
return ((timestamp - Twepoch) << _timestampLeftShift)
       | (DataCenterId << _datacenterIdShift)
       | (WorkerId << _workerIdShift)
       | _sequence;

由于c#和java的语法还是比较像的,代码几乎就是复制粘贴.更多的讨论请看上面的文章.

github

原文地址:https://www.cnblogs.com/huaface/p/8440929.html

时间: 2024-08-30 09:38:41

snowflake分布式唯一id c#实现的相关文章

分布式唯一id:snowflake算法思考

匠心零度 转载请注明原创出处,谢谢! 缘起 为什么会突然谈到分布式唯一id呢?原因是最近在准备使用RocketMQ,看看官网介绍: 一句话,消息可能会重复,所以消费端需要做幂等.为什么消息会重复后续RocketMQ章节进行详细介绍,本节重点不在这里. 为了达到业务的幂等,必须要有这样一个id存在,需要满足下面几个条件: 同一业务场景要全局唯一. 该id必须是在消息的发送方进行产生发送到MQ. 消费端根据该id进行判断是否重复,确保幂等. 在那里产生,和消费端进行判断等和这个id没有关系,这个id

分布式唯一id生成器的想法

0x01 起因 前端时间遇到一个问题,怎么快速生成唯一的id,后来采用了hashid的方法.最近在网上读到了美团关于分布式唯一id生成器的解决方案, 其中提到了三种生成法:(建议看一下这篇文章,写得很详细,分析到位) UUID 数据库生成 类snowflake方案 0x02 问题 文中提到了如下几个问题 1.全局唯一性:不能出现重复的ID号,既然是唯一标识,这是最基本的要求. 2.趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数

Java秒杀系统实战系列~分布式唯一ID生成订单编号

摘要: 本篇博文是"Java秒杀系统实战系列文章"的第七篇,在本博文中我们将重点介绍 "在高并发,如秒杀的业务场景下如何生成全局唯一.趋势递增的订单编号",我们将介绍两种方法,一种是传统的采用随机数生成的方式,另外一种是采用当前比较流行的"分布式唯一ID生成算法-雪花算法"来实现. 内容: 在上一篇博文,我们完成了商品秒杀业务逻辑的代码实战,在该代码中,我们还实现了"当用户秒杀成功后,需要在数据库表中为其生成一笔秒杀成功的订单记录&qu

分布式唯一ID生成算法-雪花算法

在我们的工作中,数据库某些表的字段会用到唯一的,趋势递增的订单编号,我们将介绍两种方法,一种是传统的采用随机数生成的方式,另外一种是采用当前比较流行的“分布式唯一ID生成算法-雪花算法”来实现. 一.时间戳随机数生成唯一ID 我们写一个for循环,用RandomUtil.generateOrderCode()生成1000个唯一ID,执行结果我们会发现出现重复的ID. /** * 随机数生成util **/ public class RandomUtil { private static fina

分布式唯一ID生成器Twitter

分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的. 有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成. /** * Twitter_Snowflake<br> * SnowFlake的结构如下(每部分用-分开):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 -

一文读懂分布式唯一ID生成

很多大的互联网公司数据量很大,都采用分库分表,那么分库后就需要统一的唯一ID进行存储.这个ID可以是数字递增的,也可以是UUID类型的. 如果是递增的话,那么拆分了数据库后,可以按照id的hash,均匀的分配到数据库中,并且mysql数据库如果将递增的字段作为主键存储的话会大大提高存储速度.但是如果把订单ID按照数字递增的话,别人能够很容易猜到你有多少订单了,这种情况就可以需要一种非数字递增的方式进行ID的生成. 想到分布式ID的生成,大家可能想到采用Redis进行生成ID,使用Redis的IN

【系统设计】分布式唯一ID生成方案总结

目录 分布式系统中唯一ID生成方案 1. 唯一ID简介 2. 全局ID常见生成方案 2.1 UUID生成 2.2 数据库生成 2.3 Redis生成 2.4 利用zookeeper生成 2.5 雪花算法生成 2.6 其他生成方式 分布式系统中唯一ID生成方案 在系统设计中,我们经常需要一个全局唯一的ID来标识一条数据,比如订单表,商品表的主键ID.这个ID往往能影响到数据存储.索引和查询等操作的效率.因此这个全局唯一的ID对系统的可用性和性能至关重要. 1. 唯一ID简介 在系统设计中,我们经常

分布式唯一ID的几种生成方案

前言 在互联网的业务系统中,涉及到各种各样的ID,如在支付系统中就会有支付ID.退款ID等.那一般生成ID都有哪些解决方案呢?特别是在复杂的分布式系统业务场景中,我们应该采用哪种适合自己的解决方案是十分重要的.下面我们一一来列举一下,不一定全部适合,这些解决方案仅供你参考,或许对你有用. 正文 分布式ID的特性 唯一性:确保生成的ID是全网唯一的. 有序递增性:确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的. 高可用性:确保任何时候都能正确的生成ID. 带时间:ID里面包含时间,一

分布式全局ID生成方案

传统的单体架构的时候,我们基本是单库然后业务单表的结构.每个业务表的ID一般我们都是从1增,通过AUTO_INCREMENT=1设置自增起始值,但是在分布式服务架构模式下分库分表的设计,使得多个库或多个表存储相同的业务数据.这种情况根据数据库的自增ID就会产生相同ID的情况,不能保证主键的唯一性. 如上图,如果第一个订单存储在 DB1 上则订单 ID 为1,当一个新订单又入库了存储在 DB2 上订单 ID 也为1.我们系统的架构虽然是分布式的,但是在用户层应是无感知的,重复的订单主键显而易见是不