浅谈几种常见的分布式ID
在分布式环境下，如何对某对象做唯一标识是个很常规的问题。本文讨论几种常见做法，供大家参考。1.UUIDUUID是可以生成时间、空间上都独一无二的值，其本质是随机+规则组合而成的。即使在两个独立的服务器上生成UUID，其预期值也是不同的。以MySQL为例，说明下UUID。❖格式
在MySQL中，UUID值是一个128位的数字，表示为以下格式的十六进制数字的utf8字符串：aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee。其得到的随机值由5个部分组成，且分隔符位为：中划线。其各部分含义如下：
前三组值是时间戳换算过来的；第四组值是暂时性保持时间戳的唯一性。例如，使用夏令时；第五组值是一个IEE802的节点标识值，它是空间上唯一的。若后者不可用，则用一个随机数字替换。假如主机没有网卡，或者我们不知道如何在某系统下获得机器地址，则空间唯一性就不能得到保证，即使这样出现重复值的几率还是非常小的。
在MySQL环境中多次调用或执行得到的后两组值相同，若把mysqld服务器关闭，重新启动之后，会发现第四组的组与未重启前的值发生变化，然后一直不变化，只要重新启动mysqld服务就会发生变化。另外，对于同一台机器，第五组值始终不会发生变化。❖优点使用UUID作为主键具有以下优点：UUID值在表，数据库甚至在服务器上都是唯一的，允许您从不同数据库合并行或跨服务器分发数据库。UUID值不会公开有关数据的信息，因此在URL中使用更安全。可以在避免往返数据库服务器的任何地方生成UUID值。它也简化了应用程序中的逻辑。❖缺点除了优势之外，UUID值也存在一些缺点：存储UUID值(16字节)比整数(4字节)或甚至大整数(8字节)占用更多的存储空间。调试似乎更加困难，想象一下WHEREid=’9d6212cf-72fc-11e7-bdf0-f0def1e6646c’和WHEREid=10哪个舒服一点？使用UUID值可能会导致性能问题，因为它们的大小和没有被排序。❖数据库案例：MySQL在MySQL中，就内置了对UUID的支持。在使用上需注意若干问题。作为主键问题UUID()函数产生的值，并不适合作为InnoDB引擎表的主键。因为格式无序，作为索引组织表存储会带来管理上的不小开销。格式问题在MySQL中，可以使用UUID()来生成主键，但是用MySQL的UUID()函数，生成的UUID是36位的，其中包含32个字符以及4个分隔符（-），往往这个分隔符对我们来说是没有用的，可以使用MySQL自带的REPLACE函数去掉分隔符。内置函数支持在MySQL中，可以以紧凑格式(BINARY)存储UUID值，并通过以下功能显示人机可读格式(VARCHAR)：UUID_TO_BIN、BIN_TO_UUID、IS_UUID。需要注意，UUID_TO_BIN()，BIN_TO_UUID()和IS_UUID()函数仅在MySQL8.0或更高版本中可用。-UUID_TO_BIN()函数将UUID从人类可读格式(VARCHAR)转换成用于存储的紧凑格式(BINARY)格式-BIN_TO_UUID()函数将UUID从紧凑格式(BINARY)转换为人类可读格式(VARCHAR)-IS_UUID()函数则可用来判断参数是有效的字符串格式UUID。2.NanoIDUUID是软件开发中最常用的通用标识符之一。然而，在过去的几年里，其他的竞品挑战了它的存在。其中，NanoID是UUID的主要竞争对手之一。但是，这两者之间的主要区别很简单。它归结为键所使用的字母表。由于NanoID使用比UUID更大的字母表，因此较短的ID可以用于与较长的UUID相同的目的。❖优点更小NanoID只有108个字节那么大。与UUID不同，NanoID的大小要小4.5倍，并且没有任何依赖关系。此外，大小限制已用于将大小从另外35%减小。大小减少直接影响数据的大小。例如，使用NanoID的对象小而紧凑，能够用于数据传输和存储。随着应用程序的增长，这些数字变得明显起来。更安全在大多数随机生成器中，它们使用不安全的Math.random()。但是，NanoID使用cryptomodule和WebCryptoAPI，意味着NanoID更安全。此外，NanoID在ID生成器的实现过程中使用了自己的算法，称为统一算法，而不是使用“随机%字母表”random%alphabet。更快NanoID既快速又紧凑，NanoID比UUID快60%。与UUID字母表中的36个字符不同，NanoID只有21个字符。更多语言NanoID支持14种不同的编程语言，它们分别是：C#、C++、Clojure和ClojureScript、Crystal、Dart&Flutter、Deno、Go、Elixir、Haskell、Janet、Java、Nim、Perl、PHP、带字典的Python、Ruby、Rust、Swift。更好兼容性它还支持PouchDB、CouchDBWebWorkers、Rollup以及React和Reach-Native等库。我们可以使用npxnanoid在终端中获得唯一ID。在JavaScript中使用NanoID唯一的要求是要先安装NodeJS。自定义字母NanoID的另一个现有功能是它允许开发人员使用自定义字母表。我们可以更改文字或id的大小。在下面的示例中，我将自定义字母表定义为ABCDEF1234567890，并将Id的大小定义为12。import{customAlphabet}from’nanoid’;constnanoid=customAlphabet(‘ABCDEF1234567890’,12);model.id=nanoid();没有第三方依赖由于NanoID不依赖任何第三方依赖，随着时间的推移，它能够变得更加稳定自治。从长远来看，这有利于优化包的大小，并使其不太容易出现依赖项带来的问题。❖数据库案例-ShardingSphere原生数据库产品，大多没有支持NanoID，但可通过外部方式引用进来。例如在开源项目ApacheShardingSphere中可通过规则的配置，在其分片表中使用NanoID作为主键生成器。参考如下配置CREATESHARDINGTABLERULEt_order(RESOURCES(ds_3307,ds_3308),SHARDING_COLUMN=order_id,TYPE(NAME=hash_mod,PROPERTIES(“sharding-count”=4)),KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=NanoID,PROPERTIES(“worker-id”=123))));CREATETABLEt_order(user_idintNOTNULL,statusvarchar(50)DEFAULTNULL,PRIMARYKEY(order_id))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;3.SnowFlake分布式系统中ID生成方案，比较简单的是UUID（UniversallyUniqueIdentifier，通用唯一识别码），但是其存在两个明显的弊端：一、UUID是128位的，长度过长；二、UUID是完全随机的，无法生成递增有序的UUID。而现在流行的基于Snowflake雪花算法的ID生成方案就可以很好地解决了UUID存在的这两个问题。❖原理Snowflake雪花算法，由Twitter提出并开源，可在分布式环境下用于生成唯一ID的算法。该算法生成的是一个64位的ID。在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。例如MySQL的Innodb存储引擎的主键。❖格式使用雪花算法生成的主键，二进制表示形式包含4部分，从高位到低位分表为：1bit符号位、41bit时间戳位、10bit工作进程位以及12bit序列号位。符号位（1bit）预留的符号位，恒为零。时间戳位（41bit）41位的时间戳可以容纳的毫秒数是2的41次幂，一年所使用的毫秒数是：365*24*60*60*1000。通过计算可知：Math.pow(2,41)/(365*24*60*60*1000L);结果约等于69.73年。ApacheShardingSphere的雪花算法的时间纪元从2016年11月1日零点开始，可以使用到2086年，相信能满足绝大部分系统的要求。工作进程位（10bit）该标志在Java进程内是唯一的，如果是分布式应用部署应保证每个工作进程的id是不同的。该值默认为0，可通过属性设置。序列号位（12bit）该序列是用来在同一个毫秒内生成不同的ID。如果在这个毫秒内生成的数量超过4096(2的12次幂)，那么生成器会等待到下个毫秒继续生成。❖优点使用SnowFlake的优点是其空间占用更小，且具备一定有序性，这对于类似MySQL数据库是比较友好的。❖缺点因为其生成策略需参考当前时间，当服务器时钟回拨会导致产生重复序列，因此默认分布式主键生成器提供了一个最大容忍的时钟回拨毫秒数。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内，默认分布式主键生成器会等待时钟同步到最后一次主键生成的时间后再继续工作。最大容忍的时钟回拨毫秒数的默认值为0，可通过属性设置。❖数据库案例-ShardingSphere原生数据库产品，大多没有支持SnowFlake，但可通过外部方式引用进来。例如在开源项目ApacheShardingSphere中可通过规则的配置，在其分片表中使用SnowFlake作为主键生成器。参考如下配置CREATESHARDINGTABLERULEt_order(RESOURCES(ds_3307,ds_3308),SHARDING_COLUMN=order_id,TYPE(NAME=hash_mod,PROPERTIES(“sharding-count”=4)),KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=Snowflake,PROPERTIES(“worker-id”=123))));CREATETABLEt_order(order_idvarchar(50)NOTNULL,user_idintNOTNULL,statusvarchar(50)DEFAULTNULL,PRIMARYKEY(order_id))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;
主题测试文章，只做测试使用。发布者：最新稳定辅助网，转转请注明出处：https://www.744broad.com/13589.html
