snowflake 雪花算法 分布式实现全局id生成

snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。

这种方案大致来说是一种以划分命名空间(UUID也算,由于比较常见,所以单独分析)来生成ID的一种算法,这种方案把64-bit分别划分成多段,分开来标示机器、时间等。

其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号,最后还有一个符号位,永远是0。

比如在snowflake中的64-bit分别表示如下图(图片来自网络)所示:

整个结构是64位,所以我们在Java中可以使用long来进行存储。 该算法实现基本就是二进制操作,单机每秒内理论上最多可以生成1024*(2^12),也就是409.6万个ID(1024 X 4096 = 4194304)

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

  1位标识,由于long基本类型在Java中是带符号的,最高位是符号位,正数是0,负数是1,所以id一般是正数,最高位是0
    41位时间截(毫秒级),注意,41位时间截不是存储当前时间的时间截,而是存储时间截的差值(当前时间截 - 开始时间截) 得到的值),这里的的开始时间截,一般是我们的id生成器开始使用的时间,由我们程序来指定的(如下下面程序IdWorker类的startTime属性)。41位的时间截,可以使用69年,年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69
    10位的数据机器位,可以部署在1024个节点,包括5位datacenterId和5位workerId。10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求,还可以将10-bit分5-bit给IDC,分5-bit给工作机器。这样就可以表示32个IDC,每个IDC下可以有32台机器,可以根据自身需求定义。
   12位序列,毫秒内的计数,12位的计数顺序号支持每个节点每毫秒(同一机器,同一时间截)产生4096个ID序号。12个自增序列号可以表示2^12个ID,理论上snowflake方案的QPS约为409.6w/s,这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
   加起来刚好64位,为一个Long型。

优点:

  整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分),并且效率较高,经测试,SnowFlake每秒能够产生26万ID左右。

  • 毫秒数在高位,自增序列在低位,整个ID都是趋势递增的。
  • 不依赖数据库等第三方系统,以服务的方式部署,稳定性更高,生成ID的性能也是非常高的。
  • 可以根据自身业务特性分配bit位,非常灵活

缺点:

  • 强依赖机器时钟,如果机器上时钟回拨,会导致发号重复或者服务会处于不可用状态。

Go实现

  sonyflake

 

下载 

go get github.com/sony/sonyflake

Demo

package main

import (
	"fmt"
	"github.com/sony/sonyflake"
)

var (
	LSonyFlake *sonyflake.Sonyflake
	machineId  uint16 // 真正的分布式环境下必须zookeeper或etcd中获取
)

func getMachineID() (uint16, error) {
	return machineId, nil
}
func Init(mid uint16) (err error) {
	machineId = mid
	st := sonyflake.Settings{}
	st.MachineID = getMachineID
	LSonyFlake = sonyflake.NewSonyflake(st)
	return
}
func GetID()(id uint64,err error)  {
	if LSonyFlake == nil{
		err = fmt.Errorf("No Init\n")
		return
	}
	return LSonyFlake.NextID()
}

func main()  {
	Init(0)
	id,err:=GetID()
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println(id)
}

  

 

 

 

原文地址:https://www.cnblogs.com/binHome/p/12072433.html

时间: 2024-11-25 15:29:41

snowflake 雪花算法 分布式实现全局id生成的相关文章

分布式高并发下全局ID生成策略

数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求:   1 不能有单点故障.   2 以时间为序,或者ID里包含时间.这样一是可以少一个索引,二是冷热数据容易分离.   3 可以控制ShardingId.比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易.   4 不要太长,最好64bit.使用long比较好操作,如果是96bit,那就要各种移位相当的不方便,还有可能有些组件不能支持这么大的ID.

分片(Sharding)的全局ID生成

前言数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求: 不能有单点故障.以时间为序,或者ID里包含时间.这样一是可以少一个索引,二是冷热数据容易分离.可以控制ShardingId.比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易.不要太长,最好64bit.使用long比较好操作,如果是96bit,那就要各种移位相当的不方便,还有可能有些组件不能支持这么大的ID.先来看看老外的做法,以时间顺序:

【转】MySQL分库分表环境下全局ID生成方案

转载一篇博客,里面有很多的知识和思想值得我们去思考. —————————————————————————————————————————————————————————————————————— 在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作.在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象.但是当我们对数据库进行了分库分表后,就不能依赖于每个表的自增ID来全局唯一标识这些数据了.因此,我们需要提供一个全局唯一的ID号生成

【php】mysql全局ID生成方案

生产系统随着业务增长总会经历一个业务量由小变大的过程,可扩展性是考量数据库系统高可用性的一个重要指标;在单表/数据库数据量过大,更新量不断飙涨时,MySQL DBA往往会对业务系统提出sharding的方案.既然要sharding,那么不可避免的要讨论到sharding key问题,在有些业务系统中,必须保证sharding key全局唯一,比如存放商品的数据库等,那么如何生成全局唯一的ID呢,下文将从DBA的角度介绍几种常见的方案. 1.使用CAS思想 什么是CAS协议 Memcached于1

一个类似 Twitter 雪花算法 的 连续序号 ID 产生器 SeqIDGenerator

项目地址 :     https://github.com/kelin-xycs/SeqIDGenerator 今天 QQ 群 里有网友问起产生唯一 ID 的方法 有哪些,  讨论了各种方法 . 有网友提到 Twitter 的 雪花算法 :       https://blog.csdn.net/w200221626/article/details/52064976 我觉得 GUID 的 优点 是 简单 高效, 缺点 是 可读性 比较差 . 高效 是指 相比起 要到 数据库 读取 种子(当前最大

Java中SnowFlake 雪花算法生成全局唯一id中的问题,时间不连续全为偶数解决

package com.example.springbootshardingjdbc.util; import java.io.FileOutputStream; /** * 描述: Twitter的分布式自增ID雪花算法snowflake (Java版) * * @author * @create 2018-03-13 12:37 **/ public class SnowFlake { /** * 起始的时间戳 */ private final static long START_STMP

分布式全局ID生成方案

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

snowflake 雪花算法 唯一ID

package snowflake; /** * Twitter_Snowflake<br> * SnowFlake的结构如下(每部分用-分开):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br> * 1位标识,由于long基本类型在Java中是带符号的,最高位是符号位,正数是0,负数是1,所以id一般是正数,最高位是0<br>

我爱java系列之---【分布式ID生成解决方案:UUID、Redis生成id、snowflake】

唯一id生成方案: a. 使用UUID生成唯一主键: 优点: 全局唯一. 缺点: 因为生成的内容是字符串, 不能排序, 不能按照时间先后排序,因为生成的是字符串类型的id, 可读性差. b. 使用redis来生成全局唯一主键: 优点: redis是内存操作, 速度快, 生成的是数字, 可读性好, 并且可以按照生成的时间先后排序. 缺点: 如果整个系统没有用到redis技术, 那么这里使用redis会增加系统的技术复杂度.   应用服务器到redis服务器获取唯一id, 增加网络io. c. sn