分布式系统全局唯一ID简介、特点、生成方式、各自的优劣势
背景
在分布式系统中，经常需要对大量的数据、消息、http请求等进行唯一标识，例如：在分布式系统之间http请求需要唯一标识，调用链路分析的时候需要使用这个唯一标识。这个时候数据库自增主键已经不能满足需求，需要一个能够生成全局唯一ID的系统，这个系统需要满足以下需求：
- 全局唯一：不能出现重复ID。
- 高可用：ID生成系统是基础系统，被许多关键系统调用，如果ID生成系统瘫痪，一旦宕机，会造成严重影响。
- 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
- 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
- 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
经典方案介绍
1. UUID
UUID是Universally Unique Identifier的缩写，它是在一定的范围内(从特定的名字空间到全球)唯一的机器生成的标识符，UUID是16字节128位长的数字，通常以36字节的字符串表示，比如：3F2504E0-4F89-11D3-9A0C-0305E82C3301。
UUID经由一定的算法机器生成，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。UUID的复杂特性在保证了其唯一性的同时，意味着只能由计算机生成。
优点：
- 代码实现简单。
- 本机生成，没有性能问题，不需要进行远程调用，时延低，性能高。
- 因为是全球唯一的ID，所以迁移数据容易
缺点：
- 每次生成的ID是无序的，无法保证趋势递增
- UUID的字符串存储，查询效率慢
- 存储空间大，UUID过长，16字节128位，通常以36长度的字符串表示
- ID本事无业务含义，不可读
- 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
应用场景：
- 类似生成token令牌的场景
- 不适用一些要求有趋势递增的ID场景
此UUID方案是不适用老顾的需求。
2.MySql数据库生成，MySQL主键自增
以MySQL举例，利用给字段设置auto_increment和auto_increment_offset来保证ID自增，每次业务使用下列SQL读写MySQL得到ID号。这个方案就是利用了MySQL的主键自增auto_increment，默认每次ID加1。
--数据表
CREATE TABLE Tickets64 (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(1) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
)ENGINE=MyISAM;
--每次业务使用下列SQL读写MySQL得到ID号
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();replace into 跟 insert 功能类似，不同点在于：replace into 首先尝试插入数据到表中，如果发现表中已经有此行数据(根据主键或者唯-索引判断)则先删除此行数据，然后插入新的数据， 否则直接插入新数据。
为了避免单点故障，最少需要两个数据库实例，通过区分auto_increment的起始值和步长来生成奇偶数的ID。
Server1：
auto-increment-increment = 2
auto-increment-offset = 1
Server2：
auto-increment-increment = 2
auto-increment-offset = 2优点：
- 数字化，id递增，有序的ID。
- 查询效率高
- 具有一定的业务可读
缺点：
- 存在单点问题，如果mysql挂了，就没法生成iD了，依赖数据库，当数据库异常时整个系统不可用。
- 数据库压力大，高并发抗不住，ID生成性能依赖单台数据库读写性能
3. 使用redis实现
当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。
这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。
我们可以使用redis的原子操作** INCR和INCRBY**来实现，redis性能也比较高，若单机存在性能瓶颈，无法满足业务需求，可以采用集群的方式来实现。
比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加。
利用redis的incr原子性操作自增，一般算法为：年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增
多个集群之间增加步长来避免生成id重复的问题，如有5台redis：
第1台生成：1、6、11、16
第2台生成：2、7、12、17
第3台生成：3、8、13、18
第4台生成：4、9、14、19
第5台生成：5、10、15、20
redis重启的时候，数据可能会丢失，可以在生成的id前面加上一个时间戳来做到唯一性。
优点：
- 有序递增，可读性强
- 性能比较高,不依赖于数据库，灵活方便，且性能优于数据库。
缺点：
- 占用带宽，每次要向redis进行请求，依赖于redis，需要系统引进redis组件，增加了系统的复杂性
5.snowflake（雪花算法）方案
这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：
41-bit的时间可以表示（1L<<41）/(1000L*3600*24*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
这种方式的优缺点是：
优点：
- 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
- 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
- 可以根据自身业务特性分配bit位，非常灵活。
缺点：
- 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
应用举例Mongdb objectID
MongoDB官方文档 ObjectID可以算作是和snowflake类似方法，通过“时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式最终标识成一个24长度的十六进制字符。
public class SnowflakeIdWorker
一线大厂的设计思路其实和小伙伴们思路差不多，只是多想了1～2层，设计上面多了1～2个环节。
3.1、改造数据库主键自增
上述我们介绍了利用数据库的自增主键的特性，可以实现分布式ID；这个ID比较简短明了，适合做userId，正好符合如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)文章中的ID的需求。但这个方案有严重的问题：
- 一旦步长定下来，不容易扩容
- 数据库压力山大
小伙伴们看看怎么优化这个方案。先看数据库压力大，为什么压力大？是因为我们每次获取ID的时候，都要去数据库请求一次。那我们可以不可以不要每次去取？
思路我们可以请求数据库得到ID的时候，可设计成获得的ID是一个ID区间段。
我们看上图，有张ID规则表：
1、id表示为主键，无业务含义。2、biz_tag为了表示业务，因为整体系统中会有很多业务需要生成ID，这样可以共用一张表维护3、max_id表示现在整体系统中已经分配的最大ID4、desc描述5、update_time表示每次取的ID时间
我们再来看看整体流程：
1、【用户服务】在注册一个用户时，需要一个用户ID；会请求【生成ID服务(是独立的应用)】的接口2、【生成ID服务】会去查询数据库，找到user_tag的id，现在的max_id为0，step=10003、【生成ID服务】把max_id和step返回给【用户服务】；并且把max_id更新为max_id = max_id + step，即更新为10004、【用户服务】获得max_id=0，step=1000；5、 这个用户服务可以用ID=【max_id + 1，max_id+step】区间的ID，即为【1，1000】6、【用户服务】会把这个区间保存到jvm中7、【用户服务】需要用到ID的时候，在区间【1，1000】中依次获取id，可采用AtomicLong中的getAndIncrement方法。8、如果把区间的值用完了，再去请求【生产ID服务】接口，获取到max_id为1000，即可以用【max_id + 1，max_id+step】区间的ID，即为【1001，2000】
这个方案就非常完美的解决了数据库自增的问题，而且可以自行定义max_id的起点，和step步长，非常方便扩容。
而且也解决了数据库压力的问题，因为在一段区间内，是在jvm内存中获取的，而不需要每次请求数据库。即使数据库宕机了，系统也不受影响，ID还能维持一段时间。
3.2、竞争问题
以上方案中，如果是多个用户服务，同时获取ID，同时去请求【ID服务】，在获取max_id的时候会存在并发问题。
如用户服务A，取到的max_id=1000 ;用户服务B取到的也是max_id=1000，那就出现了问题，Id重复了。那怎么解决？
其实方案很多，加分布式锁，保证同一时刻只有一个用户服务获取max_id。当然也可以用数据库自身的锁去解决。
利用事务方式加行锁，上面的语句，在没有执行完之前，是不允许第二个用户服务请求过来的，第二个请求只能阻塞。
3.3、突发阻塞问题
上图中，多个用户服务获取到了各自的ID区间，在高并发场景下，ID用的很快，如果3个用户服务在某一时刻都用完了，同时去请求【ID服务】。因为上面提到的竞争问题，所有只有一个用户服务去操作数据库，其他二个会被阻塞。
小伙伴就会问，有这么巧吗？同时ID用完。我们这里举的是3个用户服务，感觉概率不大；如果是100个用户服务呢？概率是不是一下子大了。
出现的现象就是一会儿突然系统耗时变长，一会儿好了，就是这个原因导致的，怎么去解决？
3.4、双buffer方案
在一般的系统设计中，双buffer会经常看到，怎么去解决上面的问题也可以采用双buffer方案。
在设计的时候，采用双buffer方案，上图的流程：
1、当前获取ID在buffer1中，每次获取ID在buffer1中获取2、当buffer1中的Id已经使用到了100，也就是达到区间的10%3、达到了10%，先判断buffer2中有没有去获取过，如果没有就立即发起请求获取ID线程，此线程把获取到的ID，设置到buffer2中。4、如果buffer1用完了，会自动切换到buffer25、buffer2用到10%了，也会启动线程再次获取，设置到buffer1中6、依次往返
双buffer的方案，小伙伴们有没有感觉很酷，这样就达到了业务场景用的ID，都是在jvm内存中获得的，从此不需要到数据库中获取了。允许数据库宕机时间更长了。
因为会有一个线程，会观察什么时候去自动获取。两个buffer之间自行切换使用。就解决了突发阻塞的问题。
四、总结
此方案是某团使用的分布式ID算法，小伙伴们如果想了解更深，可以去网上搜下，这里应该介绍了比较详细了。
当然此方案美团还做了一些别的优化，监控ID使用频率，自动设置步长step，从而达到对ID节省使用。