IM消息ID技术专题(七)：网易严选分布式ID的技术选型、优化、落地实践

1、引言

在《IM动静ID手艺专题》系列文章的前几篇中，我们已经深切体味到动静ID在散布式IM聊天系统中的重要性以及手艺实现难度，各类动静ID生成算法及实现固然各有优势，但受造于详细的应用场景，也其实不能一招吃遍全国，所以实正在IM系统中该若何落地动静ID算法和实现逻辑，仍是要因地致宜，根据自已系统的设想逻辑和产物定义取其精华，综合应用之。

本文将基于网易严选的订单ID利用现状，分享我们是若何连系业内常用的散布式ID处理计划，从而在此根底之长进行ID特征丰硕，其实不断提拔系统可用性和不变性保障。同时，也对ID生成算法的落地理论过程中碰到坑停止了深切分析。

本篇中的订单ID固然差别于IM系统中的动静ID，但其手艺理论仍然相通，希望能给你的IM系统动静ID手艺选型也来更多的启发。

进修交换：

- 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》

- 开源IM框架源码：（备用地址点此）

（本文已同步发布于：）

2、关于做者

西狂：办事端研发工程师, 早期参与严选采购、严选财政、严选合伙人以及报警平台等系统后端建立，目前次要努力于严选交易域手艺演进以及营业研发工做。

3、系列文章

本文是系列文章中的第7篇，本系列总目次如下：

《IM动静ID手艺专题(一)：微信的海量IM聊天动静序列号生成理论（算法原理篇）》

《IM动静ID手艺专题(二)：微信的海量IM聊天动静序列号生成理论（容灾计划篇）》

《IM动静ID手艺专题(三)：解密融云IM产物的聊天动静ID生成战略》

《IM动静ID手艺专题(四)：深度解密美团的散布式ID生成算法》

《IM动静ID手艺专题(五)：开源散布式ID生成器UidGenerator的手艺实现》

《IM动静ID手艺专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》

《IM动静ID手艺专题(七)：网易严选散布式ID的手艺选型、优化、落地理论》（* 本文）

4、为什么需要散布式ID？

4.1 营业布景

如上图所示，关于网易严选的主站、分销和tob城市生成各自的订单ID，在同步订单数据到订单中心的时候，订单中心会生成一个订单中心内部的一个订单号，只是推送给到下流仓配时利用的订单ID略有差别。

展开全文

4.2 带来的问题

因为订单ID利用的紊乱，招致了一系列问题的产生，例如: 沟通壁垒 、管控困难以及代码堕落等等。

4.3 手艺目的

我们希望通过火布式ID来搀扶帮助生成订单ID，在营业规则上必需全局独一、平安性高，在性能上要高可用、低延迟。

5、我们的散布式ID架构原理

5.1 手艺选型

下表是业内常见的散布式ID处理计划：

综合考虑能否撑持程度扩展以及可以显示指定ID长度，最末选择的是Leaf的Segment形式（详见《深度解密美团的散布式ID生成算法》）。

5.2 架构简介

Leaf接纳了预分发的体例来生成ID（如下图所示），在DB之上搭载若干个Server，每个Server在启动的时候，城市去DB中拿固定长度的ID列表，存放于内存中，因为ID是基于内存分发的，所以能够做到很高效。

在数据耐久化方面，每次去DB拿固定长度的ID列表，只是把更大的ID耐久化。

整体架构实现比力简单，次要是为了尽快处理营业层DB压力的问题，但是在消费情况中也表露出一些问题。

好比：

1）TP999数据颠簸大，当号段利用完之后仍是会hang在更新数据库的I/O上，tp999数据会呈现间或的尖刺；

2）当更新DB号段的时候，若是DB宕机或者发作主从切换，会招致一段时间的办事不成用。

5.3 可用性优化

为领会决上面提到那个两个问题，引入双Buffer机造和异步更新战略，当一个Buffer消耗到某个临界点时，就会异步的触发使命，把下一个号段加载到内存中。

包管无论何时DB呈现问题，都能有一个Buffer的号段能够一般对外供给办事，只要DB在一个Buffer的下发的周期内恢复，就不会影响整个Leaf的可用性。

5.4 步长动态调整

号段长度在固定稳定的前提下，流量的突增和锐减城市使得一般流量下维持原有号段一般工做的时间缩短和提拔。

能够测验考试利用以下关系表达式来描述：

Q * T = L

(Q：办事qps L：号段长度 T：号段更新周期)

但是Leaf的素质是希望T固定，若是Q和L能够正相关，T就能够趋于一个定值。

所以在Leaf每次更新号段的时候，会根据上一次号段更新的周期T和号段长度step，来决定下一次号段长度nextStep。

如下所示：

T 15min，nextStep = step * 2

15min T 30min，nextStep = step

T 30min，nextStep = step / 2

(初始指定step = nextStep = 更大值(自定义：100W))

6、我们做了什么改良？

6.1 特征丰硕

通过连系严选的现实营业场景，停止了特征化撑持，例如撑持批量ID获取、大促提早扩容以及提早跳段处置。

6.2 可用性保障

1）针对DB：

DB（MySql）接纳主从形式（读写别离、降低主库压力），一主两从的设置装备摆设体例，Master和Slave之间接纳的是半同步复造（数据一致性要求，后期可考虑利用MySql Group Replication）。同时还添加了双1设置装备摆设，包管不丢数据。

2）引入SDK：

通过引入SDK能够降低各个营业方的接入成本、降低Leaf办事端压力以及在Leaf办事不成用时，客户端起到短暂降级的效果。

SDK的实现原理和Leaf类似，在项目启动之初会加载营业关切参数设置装备摆设信息，在应用构建当地缓存，同样接纳了双Buffer存储形式。

6.3 不变性保障

1）运维方面：

次要分为3个方面：

1）日记监控：能够搀扶帮助发现预期之外的异常情状；

2）流量监控：流有助于号段长度的评估范畴，预防号段被快速消费的极端场景；

3）线上巡检：能够时刻对办事停止存活校验。

2）SLA高可用方面：

除了运维之外还做了SLA的接入，凡是用SLA来权衡系统的不变性，除此之外我们还根据接口维度设定了SLO目的规则，目前的目标项比力单一只要恳求延迟和错误率那两项。

7、我们碰到的坑

7.1 问题发现

如下图所示，我们发现每次办事启动上线接口的rt（响应时间）都要比日常平凡高的多，但是过了一段时间之后却又恢复成一般程度。

7.2 问题探究

在阐发之前，我们能够先简单的回忆下java虚拟机是若何运行Java字节码的。

虚拟机视角下Java字节码若何被虚拟机运行：

Java虚拟机将class文件加载到虚拟机中，然后将字节码翻译成机器码给底层硬件施行，而那里的翻译有两种形式，阐明施行和编译施行。前者的优势在于无需期待编译，后者的优势在于现实运行速度更快。HotSpot默认接纳混合形式，它会先阐明施行字节码，然后将此中频频施行的热点代码，以办法为单元停止立即编译，JVM是根据办法的挪用次数以及轮回回边的施行次数来触发JIT编译的。

在Java7之前我们能够根据法式的特征选择对应的立即编译器。Java7起头引入分层编译机造（-XX:+TieredCompilation）：综合了C1的启动性能优势和C2的峰值性能优势。

分层编译将JVM的施行形态分为了5个条理：

L0：阐明施行（也会profiling）；

L1：施行不带profiling的C1代码；

L2：施行仅带办法挪用次数和轮回回边施行次数profiling的C1代码；

L3：施行带所有profiling的C1代码；

L4：施行C2代码。

关于C1编译的三个条理，按施行效率从高至低：L1 L2 L3, 那是因为profiling越多，额外的性能开销越大。凡是情状下，C2代码的施行效率比C1代码超出跨越30%以上。（那里需要留意的是Java8默认开启了分层编译）

那张图列出了常见的分层编译的编译途径：

1）凡是情状下，热点办法会被第三层的C1编译器编译，再被C2编译器编译(0- 3- 4)；

2）若是办法的字节数目比力少而且第三层的profilling没有可搜集的数据，jvm会断定该办法关于C1和C2的施行效率不异，在颠末3层的C1编译事后，间接回到1层的C1(0- 3- 1)；

3）在C1繁忙的情状下，JVM在阐明施行过程中对法式停止profiling，然后间接由4层的C2编译(0- 4)；

4）在C2繁忙的情状下，办法会被2层的C1编译，然后再被3层的C1编译，以削减办法在3层的施行时间(0- 2- 3- 4)。

上图是项目启动时的分层编译日记以及整个过程接口响应RT。

从图中能够看到先是施行了C1编译，再施行C2编译（日记文件中的3和4别离打标L3和L4），称心 0-3-4 编译挨次。

发现从C1编译到C2编译耗时过程比力长，那契合我们一起头提出的疑问，为什么项目启动需要颠末一段时间接口RT才气趋于不变。

7.3 处理计划

为了能在项目启动之初，快速到达接口RT峰值，因而只要尽更大程度缩短阐明施行那个中间过程即可。

响应的处理计划：

计划 1：封闭分层编译，降低编译阈值；

计划 2：Mock接口数据, 快速触发JIT编译以及C2编译；

计划 3：Java9 AOT提早编译。

针对计划3：Java9中撑持新特征AOT提早编译，比拟较于JIT立即编译而言，AOT在运行前就已经编译好了，制止 JIT 编译器的运行时性能消耗，同时制止阐明法式的早期性能开销，能够极大进步java代码性能。

8、落地利用概略

Leaf已经在线上情况投入利用，各个营业方（包罗主站、渠道、tob）也响应接入停止同一整改，自此严选订单ID生成得到同一收拢。

在整个严选的落地情状，根据营业维度，目前累计接入3个营业，别离是订单ID、订单快照ID、订单商品快照ID，都禁受住了双十一和双十二考验。

9、参考材料

[1] 微信的海量IM聊天动静序列号生成理论（算法原理篇）

[2] 解密融云IM产物的聊天动静ID生成战略

[3] 深度解密美团的散布式ID生成算法

[4] 深度解密滴滴的高性能ID生成器(Tinyid)

（本文已同步发布于：）