共计 4095 个字符，预计需要花费 11 分钟才能阅读完成。
1、引言
在《IM 音讯 ID 技术专题》系列文章的前几篇中，咱们曾经深切体会到音讯 ID 在分布式 IM 聊天零碎中的重要性以及技术实现难度，各种音讯 ID 生成算法及实现尽管各有劣势，但受制于具体的利用场景，也并不能一招吃遍天下，所以真正在 IM 零碎中该如何落地音讯 ID 算法和实现逻辑，还是要因地致宜，依据自已零碎的设计逻辑和产品定义取其精华，综合利用之。本文将基于网易严选的订单 ID 应用现状，分享咱们是如何联合业内罕用的分布式 ID 解决方案，从而在此基础之上进行 ID 个性丰盛，并一直晋升零碎可用性和稳定性保障。同时，也对 ID 生成算法的落地实际过程中遇到坑进行了深刻分析。本篇中的订单 ID 尽管不同于 IM 零碎中的音讯 ID，但其技术实际依然相通，心愿能给你的 IM 零碎音讯 ID 技术选型也来更多的启发。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40…）
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 215min < T < 30min，nextStep = stepT > 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)
（本文已同步公布于：http://www.52im.net/thread-40…）
