snowflake算法解决分布式ID自动生成

nodejs版本实现 

https://www.npmjs.com/package/node-snowflake#see-examplesexamplejs

//only run simple http server
require('node-snowflake').Server(3001);

//request url example:GET http://localhost:3001/next_id?worker_id={optional}&data_center_id={optional}&sequence={optional}

//response : {"id":"439658373735124992"}
//only run snowflake nextId
var snowflake = require('node-snowflake').Snowflake;
var id = snowflake.nextId(); // use default set
//or
//snowflake.init({worker_id : 1, data_center_id : 1, sequence : 0});
//var id = snowflake.nextId();
console.log(id);

实现方式

• 完全依赖数据源方式

ID的生成规则，读取控制完全由数据源控制，常见的如数据库的自增长ID，序列号等，或Redis的INCR/INCRBY原子操作产生顺序号等。

• 半依赖数据源方式

ID的生成规则，有部分生成因子需要由数据源（或配置信息）控制，如snowflake算法。

• 不依赖数据源方式

ID的生成规则完全由机器信息独立计算，不依赖任何配置信息和数据记录，如常见的UUID，GUID等

实践方案

实践方案适用于以上提及的三种实现方式，可作为这三种实现方式的一种补充，旨在提升系统吞吐量，但原有实现方式的局限性依然存在。

• 实时获取方案

顾名思义，每次要获取ID时，实时生成。
简单快捷，ID都是连续不间断的，但吞吐量可能不是最高。

• 预生成方案

预先生成一批ID放在数据池里，可简单自增长生成，也可以设置步长，分批生成，需要将这些预先生成的数据，放在存储容器里（JVM内存，Redis，数据库表均可）。
可以较大幅度地提升吞吐量，但需要开辟临时存储空间，断电宕机后可能会丢失已有ID，ID可能有间断。

方案简介

以下对目前流行的分布式ID方案做简单介绍

1. 数据库自增长ID

属于完全依赖数据源的方式，所有的ID存储在数据库里，是最常用的ID生成办法，在单体应用时期得到了最广泛的使用，建立数据表时利用数据库自带的auto_increment作主键，或是使用序列完成其他场景的一些自增长ID的需求。

• 优点：非常简单，有序递增，方便分页和排序。
• 缺点：分库分表后，同一数据表的自增ID容易重复，无法直接使用（可以设置步长，但局限性很明显）；性能吞吐量整个较低，如果设计一个单独的数据库来实现 分布式应用的数据唯一性，即使使用预生成方案，也会因为事务锁的问题，高并发场景容易出现单点瓶颈。
• 适用场景：单数据库实例的表ID（包含主从同步场景），部分按天计数的流水号等；分库分表场景、全系统唯一性ID场景不适用。

1. Redis生成ID

也属于完全依赖数据源的方式，通过Redis的INCR/INCRBY自增原子操作命令，能保证生成的ID肯定是唯一有序的，本质上实现方式与数据库一致。

• 优点：整体吞吐量比数据库要高。
• 缺点：Redis实例或集群宕机后，找回最新的ID值有点困难。
• 适用场景：比较适合计数场景，如用户访问量，订单流水号（日期+流水号）等。

1. UUID、GUID生成ID

UUID：按照OSF制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号（如果有网卡，从网卡获得，没有网卡以其他方式获得）

GUID：微软对UUID这个标准的实现。UUID还有其它各种实现，不止GUID一种，不一一列举了。

这两种属于不依赖数据源方式，真正的全球唯一性ID

• 优点：不依赖任何数据源，自行计算，没有网络ID，速度超快，并且全球唯一。
• 缺点：没有顺序性，并且比较长（128bit），作为数据库主键、索引会导致索引效率下降，空间占用较多。
• 适用场景：只要对存储空间没有苛刻要求的都能够适用，比如各种链路追踪、日志存储等。

4、snowflake算法（雪花算法）生成ID

属于半依赖数据源方式，原理是使用Long类型（64位），按照一定的规则进行填充：时间（毫秒级）+集群ID+机器ID+序列号，每部分占用的位数可以根据实际需要分配，其中集群ID和机器ID这两部分，在实际应用场景中要依赖外部参数配置或数据库记录。

• 优点：高性能、低延迟、去中心化、按时间有序
• 缺点：要求机器时钟同步（到秒级即可）
• 适用场景：分布式应用环境的数据主键

雪花ID算法听起来是不是特别适用分布式架构场景？照目前来看是的，接下来我们重点讲解它的原理和最佳实践。

snowflake算法实现原理

snowflake算法来源于Twitter，使用scala语言实现，利用Thrift框架实现RPC接口调用，最初的项目起因是数据库从mysql迁移到Cassandra，Cassandra没有现成可用 的ID生成机制，就催生了这个项目，现有的github源码有兴趣可以去看看。

snowflake算法的特性是有序、唯一，并且要求高性能，低延迟（每台机器每秒至少生成10k条数据，并且响应时间在2ms以内），要在分布式环境（多集群，跨机房）下使用，因此snowflake算法得到的ID是分段组成的：

• 与指定日期的时间差（毫秒级），41位，够用69年
• 集群ID + 机器ID， 10位，最多支持1024台机器
• 序列，12位，每台机器每毫秒内最多产生4096个序列号

如图所示：

• 1bit：符号位，固定是0，表示全部ID都是正整数
• 41bit：毫秒数时间差，从指定的日期算起，够用69年，我们知道用Long类型表示的时间戳是从1970-01-01 00:00:00开始算起的，咱们这里的时间戳可以指定日期，如2019-10-23 00:00:00
• 10bit：机器ID，有异地部署，多集群的也可以配置，需要线下规划好各地机房，各集群，各实例ID的编号
• 12bit：序列ID，前面都相同的话，最多可以支持到4096个

以上的位数分配只是官方建议的，我们可以根据实际需要自行分配，比如说我们的应用机器数量最多也就几十台，但并发数很大，我们就可以将10bit减少到8bit，序列部分从12bit增加到14bit等等

当然每部分的含义也可以自由替换，如中间部分的机器ID，如果是云计算、容器化的部署环境，随时有扩容，缩减机器的操作，通过线下规划去配置实例的ID不太现实，就可以替换为实例每重启一次，拿一次自增长的ID作为该部分的内容，下文会讲解。

github上也有大神用Java做了snowflake最基本的实现，这里直接查看源码：
snowflake java版源码

/**
 * twitter的snowflake算法 -- java实现
 * 
 * @author beyond
 * @date 2016/11/26
 */
public class SnowFlake {

    /**
     * 起始的时间戳
     */
    private final static long START_STMP = 1480166465631L;

    /**
     * 每一部分占用的位数
     */
    private final static long SEQUENCE_BIT = 12; //序列号占用的位数
    private final static long MACHINE_BIT = 5;   //机器标识占用的位数
    private final static long DATACENTER_BIT = 5;//数据中心占用的位数

    /**
     * 每一部分的最大值
     */
    private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;

    private long datacenterId;  //数据中心
    private long machineId;     //机器标识
    private long sequence = 0L; //序列号
    private long lastStmp = -1L;//上一次时间戳

    public SnowFlake(long datacenterId, long machineId) {
        if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {
            throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");
        }
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {
            throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");
        }
        this.datacenterId = datacenterId;
        this.machineId = machineId;
    }

    /**
     * 产生下一个ID
     *
     * @return
     */
    public synchronized long nextId() {
        long currStmp = getNewstmp();
        if (currStmp < lastStmp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currStmp == lastStmp) {
            //相同毫秒内，序列号自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列数已经达到最大
            if (sequence == 0L) {
                currStmp = getNextMill();
            }
        } else {
            //不同毫秒内，序列号置为0
            sequence = 0L;
        }

        lastStmp = currStmp;

        return (currStmp - START_STMP) << TIMESTMP_LEFT //时间戳部分
                | datacenterId << DATACENTER_LEFT       //数据中心部分
                | machineId << MACHINE_LEFT             //机器标识部分
                | sequence;                             //序列号部分
    }

    private long getNextMill() {
        long mill = getNewstmp();
        while (mill <= lastStmp) {
            mill = getNewstmp();
        }
        return mill;
    }

    private long getNewstmp() {
        return System.currentTimeMillis();
    }

    public static void main(String[] args) {
        SnowFlake snowFlake = new SnowFlake(2, 3);

        for (int i = 0; i < (1 << 12); i++) {
            System.out.println(snowFlake.nextId());
        }

    }
}

基本上通过位移操作，将每段含义的数值，移到相应的位置上，如机器ID这里由数据中心+机器标识组成，所以，机器标识向左移12位，就是它的位置，数据中心的编号向左移17位，时间戳的值向左移22位，每部分占据自己的位置，各不干涉，由此组成一个完整的ID值。

这里就是snowflake最基础的实现原理，如果有些java基础知识不记得了建议查一下资料，如二进制-1的表示是0xffff(里面全是1)，<<表示左移操作，-1<<5等于-32，异或操作-1 ^ (-1 << 5)为31等等。

了解snowflake的基本实现原理，可以通过提前规划好机器标识来实现，但目前的分布式生产环境，借用了多种云计算、容器化技术，实例的个数随时有变化，还需要处理服务器实例时钟回拨的问题，固定规划ID然后通过配置来使用snowflake的场景可行性不高，一般是自动启停，增减机器，这样就需要对snowflake进行一些改造才能更好地应用到生产环境中。