解决方案：分布式ID生成

关键词

UUID，32位
数据库自增ID
中间件（redis，原子操作 INCR和INCRBY）
Snowflake，64 bit，自增排序（强依赖机器时钟）

一个ID一般来说有下面几种要素：

全局唯一：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
趋势递增：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。
高可用性：确保任何时候都能正确的生成ID。
带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。

一、UUID

Java自带的生成UUID的方式就能生成一串唯一随机32（32个16进制数字）位长度数据，而且够我们用N亿年，全球唯一。

优点：

简单，代码方便。
生成ID性能非常高：本地生成，没有网络消耗。
全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点：

不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：
① MySQL官方有明确的建议主键要尽量越短越好[4]，36个字符长度的UUID不符合要求。

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.* If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key*.

② 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。

这是一种简单的生成方式，简单，高效，但在一般业务系统中我还没见过有这种生成方式。

二、数据库自增ID

数据库主键设置自增序号，以一定的趋势自增，以保证主键ID的唯一性。

以MySQL举例，利用给字段设置 auto_increment_increment 和auto_increment_offset 来保证ID自增，每次业务使用下列SQL读写MySQL得到ID号。

优点：

非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。
ID号单调自增，可以实现一些对ID有特殊要求的业务。

缺点：

强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。
ID发号性能瓶颈限制在单台MySQL的读写性能。

三、中间件

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

可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis A,B,C,D,E。可以初始化每台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

使用Redis集群也可以防止单点故障的问题。使用Redis来生成每天从0开始
的流水号比较适合。比如订单号=日期+当日自增长号。可以每天在Redis中
生成一个Key，使用INCR进行累加。

优点：

不依赖于数据库，灵活方便，且性能优于数据库。
数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
即使已经有了Redis组件，但生成ID的高频率访问对单线程的Redis性能势必也会造成影响。
网络传输造成性能下降。

还可以利用像Zookeeper中的znode数据版本来生成序列号，及MongoDB的ObjectId等，这种利用中间件的做法不是很推荐。

四、开源算法Snowflake

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

Snowflake算法描述：指定机器 & 同一时刻 & 某一并发序列，是唯一的，据此可生成一个64 bits的唯一ID（long）。
组成：

第一部分：1bit 符号位，由于都是生成 ID 都是正数，所以第一位统一为0；
第二部分：41 bit 时间戳，单位是毫秒，41 位可以表示的数字多达2^41 - 1，换算成年就是 69 年；
第三部分：5 bit 机房 ID，代表最多支持 32 个机房；
第四部分：5 bit 机器 ID，代表每个机房最多支持 32 台机器；
第五部分：12 bit，记录同一时间（毫秒）内产生的不同 id，也就是说同一毫秒内可以产生4096个不同 id（有序）。

SnowFlake 生成的 ID 整体上按照时间自增排序，并且整个分布式系统不会产生 ID 碰撞（由 DataCenterID 和 WorkerID 区分），并且效率较高。内部测试每秒生成 ID 的数量，基本上每秒可以生成 900000~1100000左右。

优点：

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

缺点：

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

这种方案性能好，在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。而且这个该项目在2010就停止维护了，但这个设计思路还是应用于其他各个ID生成器及变种。

使用Snowflake算法：

（1）创建工具类IdWorker.java

package com.dabing.utils;import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.NetworkInterface;/*** <p>名称：IdWorker.java</p>* <p>描述：分布式自增长ID</p>* <pre>*     Twitter的 Snowflake　JAVA实现方案* </pre>* 核心代码为其IdWorker这个类实现，其原理结构如下，我分别用一个0表示一位，用—分割开部分的作用：* 1||0---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000* 在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，* 然后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），* 然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。* 这样的好处是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），* 并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。* <p>* 64位ID (42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加))**/
public class IdWorker {// 时间起始标记点，作为基准，一般取系统的最近时间（一旦确定不能变动）private final static long twepoch = 1288834974657L;// 机器标识位数private final static long workerIdBits = 5L;// 数据中心标识位数private final static long datacenterIdBits = 5L;// 机器ID最大值private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);// 数据中心ID最大值private final static long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);// 毫秒内自增位private final static long sequenceBits = 12L;// 机器ID偏左移12位private final static long workerIdShift = sequenceBits;// 数据中心ID左移17位private final static long datacenterIdShift = sequenceBits + workerIdBits;// 时间毫秒左移22位private final static long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;private final static long sequenceMask = -1L ^ (-1L << sequenceBits);/* 上次生产id时间戳 */private static long lastTimestamp = -1L;// 0，并发控制private long sequence = 0L;private final long workerId;// 数据标识id部分private final long datacenterId;public IdWorker(){this.datacenterId = getDatacenterId(maxDatacenterId);this.workerId = getMaxWorkerId(datacenterId, maxWorkerId);}/*** @param workerId*            工作机器ID* @param datacenterId*            机房ID*/public IdWorker(long workerId, long datacenterId) {if (workerId > maxWorkerId || workerId < 0) {throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));}if (datacenterId > maxDatacenterId || datacenterId < 0) {throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));}this.workerId = workerId;this.datacenterId = datacenterId;}/*** 获取下一个ID** @return*/public synchronized long nextId() {long timestamp = timeGen();if (timestamp < lastTimestamp) {throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));}if (lastTimestamp == timestamp) {// 当前毫秒内，则+1sequence = (sequence + 1) & sequenceMask;if (sequence == 0) {// 当前毫秒内计数满了，则等待下一秒timestamp = tilNextMillis(lastTimestamp);}} else {sequence = 0L;}lastTimestamp = timestamp;// ID偏移组合生成最终的ID，并返回IDlong nextId = ((timestamp - twepoch) << timestampLeftShift)| (datacenterId << datacenterIdShift)| (workerId << workerIdShift) | sequence;return nextId;}/*** 阻塞直到下一毫秒* @param lastTimestamp* @return*/private long tilNextMillis(final long lastTimestamp) {long timestamp = this.timeGen();while (timestamp <= lastTimestamp) {timestamp = this.timeGen();}return timestamp;}/*** 生成当前毫秒时间戳* @return*/private long timeGen() {return System.currentTimeMillis();}/*** <p>* 获取 maxWorkerId* </p>*/protected static long getMaxWorkerId(long datacenterId, long maxWorkerId) {StringBuffer mpid = new StringBuffer();mpid.append(datacenterId);String name = ManagementFactory.getRuntimeMXBean().getName();if (!name.isEmpty()) {/** GET jvmPid*/mpid.append(name.split("@")[0]);}/** MAC + PID 的 hashcode 获取16个低位*/return (mpid.toString().hashCode() & 0xffff) % (maxWorkerId + 1);}/*** <p>* 数据标识id部分* </p>*/protected static long getDatacenterId(long maxDatacenterId) {long id = 0L;try {InetAddress ip = InetAddress.getLocalHost();NetworkInterface network = NetworkInterface.getByInetAddress(ip);if (network == null) {id = 1L;} else {byte[] mac = network.getHardwareAddress();id = ((0x000000FF & (long) mac[mac.length - 1])| (0x0000FF00 & (((long) mac[mac.length - 2]) << 8))) >> 6;id = id % (maxDatacenterId + 1);}} catch (Exception e) {System.out.println("异常/ getDatacenterId: " + e.getMessage());}return id;}public static void main(String[] args) {/*IdWorker idWorker=new IdWorker(0,0);for(int i=0;i<10000;i++){long nextId = idWorker.nextId();System.out.println(nextId);}*/}
}

（2）编写测试代码

IdWorker idWorker=new IdWorker(1,1);for(int i=0;i<10000;i++){long id = idWorker.nextId();System.out.println(id);
}

配置分布式ID生成器：
（1）IdWorker.java拷贝到项目中
（2）项目的application.yml添加配置

workerId: 1
datacenterId: 1

（3）修改项目企叮咚类，增加代码

@Value("${workerId}")
private Integer workerId;@Value("${datacenterId}")
private Integer datacenterId;@Bean
public IdWorker idWorker(){return new IdWorker(workerId,datacenterId);
}

（4）在任意Controller类中注入IdWorker，即可直接使用