分布式全局唯一ID的实现
分布式全局唯一ID的实现
前言
上周末考完试，这周正好把工作整理整理，然后也把之前的一些素材，整理一番，也当自己再学习一番。
一方面正好最近看到几篇这方面的文章，另一方面也是正好工作上有所涉及，所以决定写一篇这样的文章。
先是简单介绍概念和现有解决方案，然后是我对这些方案的总结，最后是我自己项目的解决思路。
概念
在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。
如在金融、电商、支付、等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求，此时一个能够生成全局唯一ID的系统是非常必要的。
特点：
- 全局唯一性（核心）：作为唯一标识，不可以出现重复ID
- 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
- 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
- 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
同时除了对ID号码自身的要求，业务还对ID号生成系统的可用性要求极高，想象一下，如果ID生成系统瘫痪，这就会带来一场灾难。
运用场景：
分布式全局唯一ID（数据库的分库分表后需要有一个唯一ID来标识一条数据或消息；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识；MQ中消息的高可用性（确认消息是否发送成功，是否已发送等）等）
其实分布式全局ID是一个比较复杂，重要的分布式问题（什么问题涉及真正的分布式，高并发后都会比较复杂）。常见解决方案有UUID，Snowflake，Flicker，Redis，Zookeeper，Leaf等。
实现方案：
UUID（此处用的Version1：共五个版本，Version1是基于时间的）
生成一个32位16进制字符串（16字节的128位数据，通常以32位长度的字符串表示）（结合机器识别码（全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得），当前时间，一个随机数）。
优点：
- 性能好；
- 扩展性高；
- 本地生成；
- 无网络消耗；
- 不需要考虑性能瓶颈；
- 不需要提前商定，各自为政，但绝对不会冲突
缺点：
- 无法保证趋势递增（由于数据库MySQL的InnoDB采用聚簇索引，有序的ID可以保证写入速度）；
- UUID过长（消耗内存，带宽等。更重要的是如果存储在数据库中，作为主键建立索引效率低）
适用场景：
不需要考虑空间占用，不需要生成有递增趋势的ID，且不在MySQL中存储。
Snowflake
Twitter开源，生成一个64bit（0和1）字符串（1bit不用，41bit表示存储时间戳，10bit表示工作机器id（5位数据标示位，5位机器标识位），12bit序列号）
结构：
- 首位符号位：因为ID一般为正数，该值为0.
- 41位时间戳（毫秒级）：时间戳并不是当前时间戳，而是存储时间戳的差值（当前时间戳-起始时间戳（起始时间戳需要程序指定），理论可以适用(1<<41)/(1000x60x60x24x365)，69年。
- 10位数据机器位（说白了就是逻辑分片ID，具体实现和机器本身无关系）：包括5位数据标识位和5位机器标识位（比如5位机房ID，5位机器ID），理论最多可以部署节点位：1<<10=1024。
- 12位毫秒内的序列：同一节点，同一时刻（同一毫秒内）最多生成ID数1<<12=4096。
最后生成64位Long型数值（这里指，一般Long数据就是64位bit的）。
优点：
- 趋势递增，且按照时间有序；
- 性能高，稳定性高，不依赖数据库等第三方系统；
- 可以按照自身业务特性灵活分配bit位（比如机器位改为15bit，序列位改为7bit）。
缺点：
- 依赖机器时钟（虽然UUID也根据当前时间，但其非时间部分波动太大了（重新组织措辞）），时钟回拨会造成暂不可用或重复发号（分布式系统中，每台机器上的时钟不可能完全同步。在同步各个服务器的时间时，有一定几率发生时钟回拨（时间超了，往回拨））
适用场景：
要求高性能，可以不连续，数据类型为long型。
Flicker
主要思路是涉及单独的库表，利用数据库的自增ID+replace_into，来生成全局ID。
前置补充：
replace into跟insert功能类似，不同点在于：replace into首先尝试插入数据列表中，如果发现表中已经有此行数据（根据主键或唯一索引判断）则先删除，再插入。否则直接插入新数据。
建表：
create table t_global_id(
id bigint(20) unsigned not null auto_increment,
stub char(1) not null default '',
primary key (id),
unique key stub (stub)
) engine=MyISAM;
（stub：票根，对应需要生成ID的业务方编码，可以是项目名，表名，甚至是服务器IP地址。
MyISAM（MYSQL5.5.8前默认数据库存储引擎，5.5.8及之后默认存储引擎为InnoDB）：（此处应当有MyISAM与InnoDB引擎的区别，乃至其他引擎）基于ISAM类型。不是事务安全（没有事务隔离？？），不支持外键，没有行级锁。如果执行大量的select，建议MyISAM。
获取数据：
# 每次业务可以使用以下SQL读写MySQL得到ID号
replace into t_golbal_id(stub) values('a');
select last_insert_id();
扩展：为解决单点问题，启用多台服务器，如MySQL，利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增（如通过设置起始值与步长，生成奇偶数ID）
优点：
- 非常简单，充分利用了数据库系统的功能实现，成本小，有DBA专业维护；
- ID号单调自增，可以实现一些对ID有特殊要求的业务。
缺点：
- 强依赖DB，当DB异常时，整个系统不可用，属于致命问题（配置主从复制可以尽可能地增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能导致重复发号）；
- 水平扩展困难（定义好了起始值，步长和机器台数之后，如果要添加机器就比较麻烦（为什么我想到了REDIS的哈希一致原理））；
- ID发号性能瓶颈限制在单台MySQL的读写性能。
适用场景：
数据量不大，并发量不大。
Redis
由于Redis的所有命令是单线程的，所以可以利用Redis的原子操作INCR和INCRBY，来生成全局唯一的ID。
扩展：
可以通过集群来提升吞吐量（可以通过为不同Redis节点设置不同的初始值并同意步长，从而利用Redis生成唯一且趋势递增的ID）（其实这个方法和Flicker一致，只是利用到了Redis的一些特性，如原子操作，内存数据库读写快等）（Incrby:将key中储存的数字加上指定的增量值。这是一个“INCR AND GET”的原子操作，业务方可以定义一个自己的key值，通过INCR命令来获取对应的ID）
优点：
不依赖数据库，灵活方便，且性能优于基于数据库的Flicker方案。
缺点：
- 扩展性低，Redis集群需要设置号初始值与步长（与Flicker方案一样）；
- Redis宕机可能生成重复的ID；如果系统中没有Redis，还需要引入新的组件，增加系统复杂度；
- 需要编码和配置的工作量比较大。
适用场景：
Redis集群高可用，并发量高。
举例：
利用Redis来生成每天从0开始的流水号。如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，适用INCR进行累加。
zookeeper
通过其znode数据版本来生成序列号，可以生成32位和64位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。
小结：很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper，并且是多步调用API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想。
Leaf
美团的Leaf分布式ID生成系统，在Flicker策略与Snowflake算法的基础上做了两套优化的方案：Leaf-segment数据库方案（相比Flicker方案每次都要读取数据库，该方案改用proxy server批量获取，且做了双buffer的优化）与Leaf-snowflake方案（主要针对时钟回拨问题做了特殊处理。若发生时钟回拨则拒绝发号，并进行告警）。
MongDB objectID
ObjectID可以算作和snowflake类似方法，通过”时间+机器码+pid+inc”共12个字节，通过4+3+2+3的方式，最终标识一个24长度的十六进制字符。
理论总结
其实除了上述方案外，还有ins等的方案，但总的来看，方案主要分为两种：第一有中心（如数据库，包括MYSQL，REDIS等），其中可以会利用事先的预约来实现集群（起始步长）。第二种就是无中心，通过生成足够散落的数据，来确保无冲突（如UUID等）。站在这两个方向上，来看上述方案的利弊就方便多了。
中心化方案：
优点：
- 数据长度相对小一些；
- 数据可以实现自增趋势等。
缺点：
- 并发瓶颈处理；
- 集群需要实现约定；横向扩展困难（当然有的方案看起来后两者没有那么问题，是因为，这些方案利用其技术特性，早就一定程度上解决了这些问题，如Redis的横向扩展等）。
非中心化方案：
优点：
- 实现简单（因为不需要与其他节点存在这方面的约定，耦合）；
- 不会出现中心节点带来的性能瓶颈；
- 扩展性较高（扩展的局限往往集中于数据的离散问题）。
缺点：
- 数据长度较长（毕竟就是通过这一特性来实现无冲突的）；
- 无法实现数据的自增长（毕竟是随机的）；
- 依赖数据生成方案的优劣（数据生成方案的优劣会全盘接收，但可以推成出新）。
体悟：
技术是无穷无尽的，我们不仅需要看到其中体现的思想与原则，在学习新技术或方案时，需要明确其中一些特性，优缺点的来源，从而进行有效的总结归纳。
应用角度来说：（一方面想要标示符短，便于处理与存储，另一方面想要足够大，而不会产生冲突。呵呵）。最理想就是追求从0开始，每个标示符都被使用，且不重复，而且不用担心并发。呵呵。完全应该根据当前业务场景来选择，毕竟业务场景在当前是确定的。如果业务变动较大（比如发展初期，业务增长很快），那就需要考虑扩展性，便于日后进行该模块的更新与技术方案的替换实现（避免一个系统开发一年，用不到一年，那就尴尬了））。
个人经验
我曾经做过一个“工业物联网”系统，该系统系统是分为三个子系统：终端服务器（用于收集终端传感器数据）；企业中控服务器（接收来自多个终端服务器的数据，进行综合查看与控制）；云平台服务器（提供上云）。其中就涉及多个终端服务器的传感器数据辨识问题，这里以倾斜传感器数据为例。简述不同终端服务器的倾斜数据的如何实现全局唯一标识。
以企业中控服务器的数据库作为统一的数据标识来源
简单说，就是终端服务器发送一个数据到企业中控室，企业中控服务器就将该数据保存到数据库中，那么每个数据在企业中控服务器数据库中都有唯一的ID，并且保持了自增。
优点是实现简单，只需要做好数据收发，与数据的插入工作即可。唯一需要注意的是数据库插入时注意资源互斥，防止出现数据插入异常问题（Springframework生成的Bean默认时单例的）。
缺点是需要实时收发数据，防止数据丢失，数据积压，数据的create_time异常等问题。
以UUID等方式生成数据的全局唯一标识
简单说，就是终端服务器要发送的数据赋予UUID这样的ID，来确保全局唯一。这样终端服务器就可以和中控服务器保持同样且不冲突的ID了。数据的生成是实现在终端服务器的，而中控服务器只是作为数据的保存与调用（通过统一ID调用）。
优点是不需要数据的实时收发，避免系统在弱网络情况下出现各类异常。
缺点是数据的ID过长，并且无法保持自增。并且在某种程度上带来了数据复杂度，从而提高了系统复杂度。
落地方案
由于实际业务的需求，如弱网络，数据交互频率跨度大等情况。最终我的实现是先由终端服务器在启动之初，在企业中控服务器注册TerminalId，作为不同终端服务器的标识。不同终端服务器接收与保存数据时，都会在每条数据中插入TerminalId，便于企业中控服务器的识别。当然，具体实现当中还有一些细节。如终端服务器在注册时由于网络等情况注册失败，会先建立一个类似UUID的TerminalId来先保存监测数据。当注册成功时（系统会根据TerminalId的长度等特性来判断是否注册失败，是否需要重新注册），会重新修改所有数据的TerminalId，再允许数据上传。
优点是确保了数据在弱网络情况下的正确性，并且实现了自动注册等通用模块的实现。
缺点是最终数据插入企业中控服务器数据库时，并没有严格实现数据符合实际时间的增长（如某终端服务器由于网络等情况没法发送数据，等待一段时间后发送了这段时间堆积的数据），但保持了总体增长的趋势。
总结
IT没有银弹，我们要做的是多去了解现有的技术方案，再产生符合自己需求的技术方案。因为不同的技术方案都因为其使用场景有着各自的特点，而我们需要了解各种特点的技术来源（是什么技术造就了这一特点，或者说是什么架构造就了这一特点等），从而构建出最符合自己需求的技术方案。
没有最好，只有最适合。
