常见分布式系统 ID调研

介绍：

根据ID业务需求，在网上找了一些文章和解决方案的优缺点，redis、snowflake 有第三方提供的方法，可根据公司业务需求进行定制，供大家分析：

【常见方法一：使用的 auto_increment 来生成全局唯一递增ID】【可以服务及SDK实现】

优点：

（1）简单，使用已有的功能

（2）能够保证唯一性

（3）能够保证递增性

（4）步长固定

缺点：

（1）可用性难以保证：常见架构是一主多从+读写分离，生成自增ID是写请求，主库挂了就玩不转了

（2）扩展性差，性能有上限：因为写入是单点，主库的写性能决定ID的生成性能上限，并且难以扩展

改进方法：

（1）增加主库，避免写入单点

（2）数据水平切分，保证各主库生成的ID不重复

如上图所述，由1个写库变成3个写库，每个写库设置不同的auto_increment初始值，以及相同的增长步长，以保证每个生成的ID是不同的（上图中库0生成0,3,6,9…，库1生成1,4,7,10，库2生成2,5,8,11…）改进后的架构保证了可用性，但缺点是：

（1）丧失了ID生成的“绝对递增性”：先访问库0生成0,3，再访问库1生成1，可能导致在非常短的时间内，ID生成不是绝对递增的（这个问题不大，我们的目标是趋势递增，不是绝对递增）

（2）的写压力依然很大，每次生成ID都要访问

为了解决上述两个问题，引出了第二个常见的方案

【常见方法二：单点批量ID生成服务】【可以服务及SDK实现】

分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”，要想保证绝对的时序，还是只能使用单点服务，用本地时钟保证“绝对时序”。写压力大，是因为每次生成ID都访问了，可以使用批量的方式降低写压力。

如上图所述，使用双master保证可用性，中只存储当前ID的最大值，例如0。ID生成服务假设每次批量拉取6个ID，服务访问，将当前ID的最大值修改为5，这样应用访问ID生成服务索要ID，ID生成服务不需要每次访问，就能依次派发0,1,2,3,4,5这些ID了，当ID发完后，再将ID的最大值修改为11，就能再次派发6,7,8,9,10,11这些ID了，于是的压力就降低到原来的1/6了。

优点：

（1）保证了ID生成的绝对递增有序

（2）大大的降低了的压力，ID生成可以做到每秒生成几万几十万个

缺点：

（1）服务仍然是单点

（2）如果服务挂了，服务重启起来之后，继续生成ID可能会不连续，中间出现空洞（服务内存是保存着0,1,2,3,4,5，中max-id是5，分配到3时，服务重启了，下次会从6开始分配，4和5就成了空洞，不过这个问题也不大）

（3）虽然每秒可以生成几万几十万个ID，但毕竟还是有性能上限，无法进行水平扩展

改进方法：

单点服务的常用高可用优化方案是“备用服务”，也叫“影子服务”，所以我们能用以下方法优化上述缺点（1）：

如上图，对外提供的服务是主服务，有一个影子服务时刻处于备用状态，当主服务挂了的时候影子服务顶上。这个切换的过程对调用方是透明的，可以自动完成，常用的技术是vip+keepalived，具体就不在这里展开。

【常见方法三：uuid】

上述方案来生成ID，虽然性能大增，但由于是单点系统，总还是存在性能上限的。同时，上述两种方案，不管是还是服务来生成ID，业务方Application都需要进行一次远程调用，比较耗时。有没有一种本地生成ID的方法，即高性能，又时延低呢？

uuid是一种常见的方案：string ID =GenUUID();

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-86180-1.html