分布式架构会波及到分布式全局惟一ID的生成，明天我就来详解分布式全局惟一ID，以及分布式全局惟一ID的实现计划@mikechen

什么是分布式系统惟一ID

在简单分布式系统中，往往须要对大量的数据和音讯进行惟一标识。

如在金融、电商、领取、等产品的零碎中，数据日渐增长，对数据分库分表后须要有一个惟一ID来标识一条数据或音讯，数据库的自增ID显然不能满足需要，此时一个可能生成全局惟一ID的零碎是十分必要的。

分布式系统惟一ID的特点

  1. 全局唯一性：不能呈现反复的ID号，既然是惟一标识，这是最根本的要求。
  2. 趋势递增：在MySQL InnoDB引擎中应用的是汇集索引，因为少数RDBMS应用B-tree的数据结构来存储索引数据，在主键的抉择下面咱们应该尽量应用有序的主键保障写入性能。
  3. 枯燥递增：保障下一个ID肯定大于上一个ID，例如事务版本号、IM增量音讯、排序等非凡需要。
  4. 信息安全：如果ID是间断的，歹意用户的扒取工作就非常容易做了，间接依照程序下载指定URL即可；如果是订单号就更危险了，竞对能够间接晓得咱们一天的单量。所以在一些利用场景下，会须要ID无规则、不规则。

同时除了对ID号码本身的要求，业务还对ID号生成零碎的可用性要求极高，设想一下，如果ID生成零碎瘫痪，这就会带来一场劫难。

由此总结下一个ID生成零碎应该做到如下几点：

  1. 均匀提早和TP999提早都要尽可能低；
  2. 可用性5个9；
  3. 高QPS

\

分布式系统惟一ID的实现计划

1.UUID

UUID(Universally Unique Identifier)的规范型式蕴含32个16进制数字，以连字号分为五段，模式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种形式生成UUID，详情见IETF公布的UUID标准 A Universally Unique IDentifier (UUID) URN Namespace。

UUID长处：

  • 性能十分高：本地生成，没有网络耗费。

UUID毛病：

  • 不易于存储：UUID太长，16字节128位，通常以36长度的字符串示意，很多场景不实用;
  • 信息不平安：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个破绽曾被用于寻找梅丽莎病毒的制作者地位;
  • ID作为主键时在特定的环境会存在一些问题，比方做DB主键的场景下，UUID就十分不实用。

\

2.数据库生成ID

以MySQL举例，利用给字段设置auto_increment_increment和auto_increment_offset来保障ID自增，每次业务应用下列SQL读写MySQL失去ID号。

数据库生成ID长处：

  • 非常简单，利用现有数据库系统的性能实现，老本小，有DBA业余保护。
  • ID号枯燥自增，能够实现一些对ID有特殊要求的业务。

数据库生成ID毛病：

  • 强依赖DB，当DB异样时整个零碎不可用，属于致命问题。配置主从复制能够尽可能的减少可用性，然而数据一致性在非凡状况下难以保障。主从切换时的不统一可能会导致反复发号。
  • ID发号性能瓶颈限度在单台MySQL的读写性能。

\

3.Redis生成ID

当应用数据库来生成ID性能不够要求的时候，咱们能够尝试应用Redis来生成ID。

这次要依赖于Redis是单线程的，所以也能够用生成全局惟一的ID。能够用Redis的原子操作 INCR和INCRBY来实现。

比拟适宜应用Redis来生成每天从0开始的流水号。比方订单号=日期+当日自增长号。能够每天在Redis中生成一个Key，应用INCR进行累加。

Redis生成ID长处：

1）不依赖于数据库，灵便不便，且性能优于数据库。

2）数字ID人造排序，对分页或者须要排序的后果很有帮忙。

\

Redis生成ID毛病：

1）如果零碎中没有Redis，还须要引入新的组件，减少零碎复杂度。

2）须要编码和配置的工作量比拟大。

4.利用zookeeper生成惟一ID

zookeeper次要通过其znode数据版本来生成序列号，能够生成32位和64位的数据版本号，客户端能够应用这个版本号来作为惟一的序列号。

很少会应用zookeeper来生成惟一ID。次要是因为须要依赖zookeeper，并且是多步调用API，如果在竞争较大的状况下，须要思考应用分布式锁。因而，性能在高并发的分布式环境下，也不甚现实。

5.snowflake雪花算法生成ID

这种计划大抵来说是一种以划分命名空间（UUID也算，因为比拟常见，所以独自剖析）来生成ID的一种算法，这种计划把64-bit别离划分成多段，离开来标示机器、工夫等，比方在snowflake中的64-bit别离示意如下图（图片来自网络）所示：

41-bit的工夫能够示意（1L<<41）/(1000L360024*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都是趋势递增的。
  • 不依赖数据库等第三方零碎，以服务的形式部署，稳定性更高，生成ID的性能也是十分高的。
  • 能够依据本身业务个性调配bit位，非常灵活。

雪花算法ID毛病：

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

以上

作者简介

陈睿|mikechen,10年+大厂架构教训,《BAT架构技术500期》系列文章作者，专一于互联网架构技术。

浏览mikechen的互联网架构更多技术文章合集

Java并发|JVM|MySQL|Spring|Redis|分布式|高并发

关注「mikechen 的互联网架构」公众号，回复 【架构】 支付《Java进阶架构思维导图&Java进阶架构文章合集》