关于分布式:分布式ID生成服务的技术原理和项目实战

作者 | 文库 App

导读
ID 在咱们的开发工作和日常生活中应用的十分频繁，简直只有是在开发就会天天打交道，它的利用场景非常宽泛，比方：身份证号，下单生成的订单号，购买的联结会员商品的兑换券码。不同场景对 ID 生成服务的要求不同，以下咱们一一剖析。

全文 6863 字，预计浏览工夫 18 分钟。

在业务开发中，大量场景须要惟一 ID 来进行标识：用户举世无双的身份认证、超市售卖的商品、微信的即时消息，它们都须要标识来确定唯一性。须要在特定范畴内保障 ID 具备唯一性，这是 ID 生成服务最根本的要求。

生成 ID 的形式多种多样，能够应用 Redis 键自增，UUID，或者基于雪花算法实现的 ID 生成服务。最常见的基于数据库 ID 自增的形式，在业务数据量不大的时候，单库单表能够撑持，数据再大一点搞个 MySQL 主从同步、读写拆散也能凑合。但随着数据日渐增长，主从同步也扛不住了，就须要对数据库进行分库分表，但分库分表后须要有一个惟一 ID 来标识一条数据，数据库的自增 ID 显然不能满足需要。

随同着业务疾速迭代，很多业务都须要生成 ID，各自为政会陷入 ” 反复造轮子 ” 的低效劳动中，同时造成服务治理上的凌乱，此时一个可能生成全局惟一 ID 的服务是十分必要的。那么这个全局惟一 ID 就叫分布式 ID 生成服务。

① 唯一性：生成的 ID 惟一，特定范畴不抵触；

② 有序性：生成的 ID 按某种规定有序，趋势递增，便于入库和查问，但不严格要求；

③ 高可用、高性能：高并发下的具备高可用，确保任何状况能容灾，稳固提供服务；

④ 自主性：分布式环境下不依赖核心认证即可自行生成 ID；

⑤ 安全性：脱敏，不裸露零碎和业务的信息，如：订单数，用户数。

技术归根到底是为业务服务，要在业务中体现技术的价值。

网上绝大多数的分布式 id 生成服务，个别着重于技术原理分析，很少见到依据具体的业务场景去选型 ID 生成服务的文章。

本文联合一些应用场景，进一步探讨业务场景中对 ID 有哪些具体的要求。

咱们在商场买货色一码付二维码，下单生成的订单号，应用到的优惠券码，联结商品兑换券码，这些是在网上购物常常应用到的单号，那么为什么有些单号那么长，有些只有几位数？有些单号一看就晓得年月日的信息，有些却看不出任何意义？上面开展剖析下订单零碎中不同场景的 id 服务的具体实现。

1、一码付

咱们常见的一码付，指的是一个二维码能够应用支付宝或者微信进行扫码领取。

二维码的实质是一个字符串。聚合码的实质就是一个链接地址。用户应用支付宝微信间接扫一个码付钱，不必放心拿支付宝扫了微信的收款码或者用微信扫了支付宝的收款码，这极大缩小了用户扫码领取的工夫。

实现原理是当客户用 APP 扫码后，网站后盾就会判断客户的扫码环境。（微信、支付宝、QQ 钱包、京东领取、云闪付等）。

判断扫码环境的原理就是依据关上链接浏览器的 HTTP header。任何浏览器关上 http 链接时，申请的 header 都会有 User-Agent(UA、用户代理) 信息。

UA 是一个非凡字符串头，服务器顺次能够辨认出客户应用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等很多信息。

各渠道对应领取产品的名称不一样，肯定要认真看各领取产品的 API 介绍。

微信领取：JSAPI 领取领取
支付宝：手机网站领取
QQ 钱包：公众号领取

其本质均为在 APP 内置浏览器中实现 HTML5 领取。

文库的研发同学在这个思路上，做了优化迭代。动静生成一码付的二维码事后绑定用户所选的商品信息和价格，依据用户所选的商品动静更新。这样不仅反对一码多平台调起领取，而且不必用户抉择商品输出金额，即可实现订单领取的性能，很丝滑。用户在真正扫码后，服务端才通过前端获取用户 UID，联合二维码绑定的商品信息，真正的生成订单，发送领取信息到第三方（qq、微信、支付宝），第三方生成领取订单推给用户设施，从而调起领取。

区别于固定的一码付，在文库的利用中，应用到了动静二维码，二维码实质是一个短网址，ID 服务提供短网址的惟一标记参数。惟一的短网址映射的 ID 绑定了商品的订单信息，技术和业务的深度联合，缩短了领取流程，晋升用户的领取体验。

2、订单号

订单号在理论的业务过程中作为一个订单的惟一标识码存在，个别实现以下业务场景：

用户订单遇到问题，须要找客服进行帮助；
对订单进行操作，如线下收款，订单核销；
下单，改单，成单，退单，售后等零碎外部的订单流程解决和跟进。

很多时候搜寻订单相干信息的时候都是以订单 ID 作为惟一标识符，这是因为订单号的生成规定的唯一性决定的。从技术角度看，除了 ID 服务必要的个性之外，在订单号的设计上须要体现几个个性：

（1）信息安全

编号不能走漏公司的经营状况，比方日销、公司流水号等信息，以及商业信息和用户手机号，身份证等隐衷信息。并且不能有显著的整体法则（能够有部分法则），任意批改一个字符就能查问到另一个订单信息，这也是不容许的。

类比于咱们高考时候的考生编号的生成规定，肯定不能是连号的，否则只须要依据程序往下查问就能搜寻到别的考生的问题，这是相对不可容许。

（2）局部可读

位数要便于操作，因而要求订单号的位数适中，且部分有法则。这样能够不便在订单异样，或者退货时客服查问。

过长的订单号或易读性差的订单号会导致客服输出艰难且易错率较高，影响用户体验的售后体验。因而在理论的业务场景中，订单号的设计通常都会适当携带一些容许公开的对应用场景有帮忙的信息，如工夫，星期，类型等等，这个次要依据所波及的编号对应的应用场景来。

而且像工夫、星期这些自增长的属于作为订单号的设计的一部分元素，有助于解决业务累积而导致的订单号反复的问题。

（3）查问效率

常见的电商平台订单号大多是纯数字组成，兼具可读性的同时，int 类型绝对 varchar 类型的查问效率更高，对在线业务更加敌对。

3、优惠券和兑换券

优惠券、兑换券是经营推广最罕用的促销工具之一，正当应用它们，能够让买家失去实惠，商家晋升商品销量。常见场景有：

在文库购买【文库 VIP+QQ 音乐年卡】联结商品，领取胜利后会失去 QQ 音乐年卡的兑换码，能够去 QQ 音乐 App 兑换音乐会员年卡；
疫情期间，局部中央政府发放的生产券；
瓶装饮料常常会呈现输出优惠编码兑换奖品。

从技术角度看，有些场景适宜 ID 即时生成，比方电商平台购物支付的优惠券，只须要在用户支付时调配优惠券信息即可。有些线上线下联合的场景，比方疫情优惠券，瓶盖开奖，京东卡，超市卡这种，则须要事后生成，事后生成的券码具备以下个性：

1. 事后生成，在流动正式开始前提供进去进行流动预热；

2. 优惠券体量大，以万为单位，通常在 10 万级别以上；

3. 不可破解、仿造券码；

4. 反对用后核销；

5. 优惠券、兑换券属于广撒网的策略，所以利用率低，也就不适宜应用数据。

库进行存储（占空间，无效的数据有少）

设计思路上，须要设计一种无效的兑换码生成策略，反对事后生成，反对校验，内容简洁，生成的兑换码都具备唯一性，那么这种策略就是一种非凡的编解码策略，依照约定的编解码规定撑持上述需要。

既然是一种编解码规定，那么须要约定编码空间 (也就是用户看到的组成兑换码的字符)，编码空间由字符 a -z,A-Z, 数字 0 - 9 组成，为了加强兑换码的可辨认度，剔除大写字母 O 以及 I, 可用字符如下所示，共 60 个字符：

abcdefghijklmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXZY0123456789

之前说过，兑换码要求近可能简洁，那么设计时就须要思考兑换码的字符数，假如下限为 12 位，而字符空间有 60 位，那么能够示意的空间范畴为 60^12=130606940160000000000000(也就是能够 12 位的兑换码能够生成天量, 应该够经营同学挥霍了)，转换成 2 进制：1001000100000000101110011001101101110011000000000000000000000(61 位)

兑换码组成成分剖析

兑换码能够事后生成，并且不须要额定的存储空间保留这些信息，每一个优惠计划都有独立的一组兑换码 (指经营同学组织的每一场经营流动都有不同的兑换码, 不能混合应用, 例如双 11 兑换码不能应用在双 12 流动上)，每个兑换码有本人的编号，避免反复，为了保障兑换码的有效性，对兑换码的数据须要进行校验，以后兑换码的数据组成如下所示：

优惠计划 ID + 兑换码序列号 i + 校验码

编码方案

兑换码序列号 i，代表以后兑换码是以后流动中第 i 个兑换码，兑换码序列号的空间范畴决定了优惠活动能够发行的兑换码数目，以后采纳 30 位 bit 位示意，可示意范畴：1073741824（10 亿个券码）。
优惠计划 ID, 代表以后优惠计划的 ID 号，优惠计划的空间范畴决定了能够组织的优惠活动次数，以后采纳 15 位示意，能够示意范畴：32768（思考到经营流动的频率，以及 ID 的初始值 10000，15 位足够，365 天每天有经营流动，能够应用 54 年）。
校验码，校验兑换码是否无效，次要为了快捷的校验兑换码信息的是否正确，其次能够起到填充数据的目标，加强数据的散列性，应用 13 位示意校验位，其中分为两局部，前 6 位和后 7 位。

深耕业务还会有辨别通用券和独自券的状况，别离具备以下特点，技术实现须要就地取材地思考。

通用券：多个玩家都能够输出兑换，而后有总量限度，期限限度。
独自券：经营同学能够在后盾设置兑换码的处分物品、期限、个数，而后由后盾生成兑换码的列表，兑换之后核销。

1、日志跟踪

在分布式服务架构下，一个 Web 申请从网关流入，有可能会调用多个服务对申请进行解决，拿到最终后果。这个过程中每个服务之间的通信又是独自的网络申请，无论申请通过的哪个服务出了故障或者解决过慢都会对前端造成影响。

解决一个 Web 申请要调用的多个服务，为了能更不便的查问哪个环节的服务呈现了问题，当初罕用的解决方案是为整个零碎引入分布式链路跟踪。

在分布式链路跟踪中有两个重要的概念：跟踪（trace）和跨度（span）。trace 是申请在分布式系统中的整个链路视图，span 则代表整个链路中不同服务外部的视图，span 组合在一起就是整个 trace 的视图。

在整个申请的调用链中，申请会始终携带 traceid 往上游服务传递，每个服务外部也会生成本人的 spanid 用于生成本人的外部调用视图，并和 traceid 一起传递给上游服务。

2、TraceId 生成规定

这种场景下，生成的 ID 除了要求惟一之外，还要求生成的效率高、吞吐量大。traceid 须要具备接入层的服务器实例自主生成的能力，如果每个 trace 中的 ID 都须要申请公共的 ID 服务生成，纯纯的节约网络带宽资源。且会阻塞用户申请向上游传递，响应耗时回升，减少了没必要的危险。所以须要服务器实例最好能够自行计算 tracid，spanid，防止依赖内部服务。

产生规定：服务器 IP + ID 产生的工夫 + 自增序列 + 以后过程号，比方：

0ad1348f1403169275002100356696

前 8 位 0ad1348f 即产生 TraceId 的机器的 IP，这是一个十六进制的数字，每两位代表 IP 中的一段，咱们把这个数字，按每两位转成 10 进制即可失去常见的 IP 地址示意形式 10.209.52.143，您也能够依据这个法则来查找到申请通过的第一个服务器。

前面的 13 位 1403169275002 是产生 TraceId 的工夫。之后的 4 位 1003 是一个自增的序列，从 1000 涨到 9000，达到 9000 后回到 1000 再开始往上涨。最初的 5 位 56696 是以后的过程 ID，为了避免单机多过程呈现 TraceId 抵触的状况，所以在 TraceId 开端增加了以后的过程 ID。

3、SpanId 生成规定

span 是层的意思，比方在第一个实例算是第一层，申请代理或者分流到下一个实例解决，就是第二层，以此类推。通过层，SpanId 代表本次调用在整个调用链路树中的地位。

假如一个服务器实例 A 接管了一次用户申请，代表是整个调用的根节点，那么 A 层解决这次申请产生的非服务调用日志记录 spanid 的值都是 0，A 层须要通过 RPC 顺次调用 B、C、D 三个服务器实例，那么在 A 的日志中，SpanId 别离是 0.1，0.2 和 0.3，在 B、C、D 中，SpanId 也别离是 0.1，0.2 和 0.3；如果 C 零碎在解决申请的时候又调用了 E，F 两个服务器实例，那么 C 零碎中对应的 spanid 是 0.2.1 和 0.2.2，E、F 两个零碎对应的日志也是 0.2.1 和 0.2.2。

依据下面的形容能够晓得，如果把一次调用中所有的 SpanId 收集起来，能够组成一棵残缺的链路树。

spanid 的生成实质：在跨层传递透传的同时，管制大小版本号的自增来实现的。

短网址次要性能包含网址缩短与还原两大性能。绝对于长网址，短网址能够更不便地在电子邮件，社交网络，微博和手机上流传，例如原来很长的网址通过短网址服务即可生成相应的短网址，防止折行或超出字符限度。

罕用的 ID 生成服务比方：mysql ID 自增、redis 键自增、号段模式，生成的 ID 都是一串数字。短网址服务把客户的长网址转换成短网址，

理论是在 dwz.cn 域名前面拼接新产生的数字类型 ID，间接用数字 ID，网址长度也有些长，服务能够通过数字 ID 转更高进制的形式压缩长度。这种算法在短网址的技术实现上越来越多了起来，它能够进一步压缩网址长度。转进制的压缩算法在生活中有宽泛的利用场景，举例：

客户的长网址：https://wenku.baidu.com/ndbus…\_code=PCoperatebanner

ID 映射的短网址：https://dwz.cn/2047601319t66

转进制后的短网址：https://dwz.cn/2ezwDJ0

长数字转短字符串的压缩算法，以下为具体实现：

/**
 * 10 进制转为 62 进制
 * 
 * @param integer $n 10 进制数值
 * @return string 62 进制
 */
function dec62($n) { 
    $base = 62; 
    $index = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; 
    $ret = ''; 
    for($t = floor(log10($n) / log10($base)); $t >= 0; $t --) {$a = floor($n / pow($base, $t)); 
        $ret .= substr($index, $a, 1); 
        $n -= $a * pow($base, $t); 
    } 
    return $ret; 
}

端字符串同样反对反解，将高位进制转为 10 进制。

/**
 * 62 进制转为 10 进制
 *
 * @param integer $n 62 进制
 * @return string 10 进制
 */
function dec10($s) { 
    $base = 62; 
    $index = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; 
    $ret = 0; 
    $len = strlen($s) - 1; 
    for($t = 0; $t <= $len; $t ++) {$ret += strpos($index, substr($s, $t, 1)) * pow($base, $len - $t); 
    } 
    return $ret;
}

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ 顺次示意 0 -62，大小写示意不同的进制。10 进制的数字采取 62 进位压缩的形式转为字符串，仅须要 6 位就能够满足 500 多亿的网址（568 0023 5583），唯一性失去满足的同时保障长度够短，在具体实现中也可随机跳跃生成，进攻撞库攻打。

在诸多须要 ID 服务的业务中，联结商品须要做好信息加密，兑换码、优惠券须要反对可反解或者可验证，订单号须要反对局部信息可读，能够轻松获取日期信息。

纯数字组成的用户 uid，订单号出于数据安全，要求是非间断的，然而如果是一些须要计数的 ID，则要求严格递增。短 url 服务中的 ID 对长度有很高要求，traceid 则要求 ID 可反解，且反对本地生成，保障部分惟一就行。

由此可见，ID 生成服务除了具备根底个性，局部场景下还须要满足的特定需要。制订适合的技术计划联合场景去实现，施展技术劣势，才能够更好的撑持业务倒退。

———END———

关于分布式:分布式ID生成服务的技术原理和项目实战

01 什么是分布式 ID 生成服务

02 服务个性

03 常见的技术实现形式

04 技术为业务服务

4.1 场景一：订单零碎

4.2 Tracing

4.3 场景三：短网址

05 总结

Just My Socks（注册教程内含优惠码）

关于分布式:分布式ID生成服务的技术原理和项目实战

01 什么是分布式 ID 生成服务

02 服务个性

03 常见的技术实现形式

04 技术为业务服务

4.1 场景一：订单零碎

4.2 Tracing

4.3 场景三：短网址

05 总结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）