leaf -segment分布式ID获取方式源码图解

# 一、背景介绍
首先先来介绍本期的故事主人公Leaf,他呢，是一个证件办理员。
可以理解为他主要功能是发号功能。并且必须保证每次发号是唯一的。
就像每张钞票，编号都是唯一的。
我虽然不在意钞票的序号是否唯一，但是我真的对它又爱又恨呐~

 # 二、工作内容：
1.首先作为一个证件办理员，专门给我们进行办理证件的,对于证件的话,类似我们每人的身份证号一样不会重复，并且永远是往上递增的。
这就是我们说的第一特性全局唯一。

 
2.第二他呢是个证件号码库存比较多，所以即使在他窗口办理身份证可能一段时间内，数据库不可用了，没关系，他也还有剩余的号码可以提供使用，只需要保证在这个数据库不可用期间，号码段没有使用完即可，如下图所示。

目前一共有100000个号码可以使用，仅仅只有号码段使用完了，或者达到了预定的阈值（默认90%）使用量，才会申请下一个号段的号码进行预先存储。

这就是我们的第二特性 高可用，可以容忍一段时间数据库不可用的问题。

3.第三呢，在他这里办理证件的速度的非常快，且可以一次性给很多人进行办理证件，神仙级别的，基本上每秒可以处理5万人，你知道原因是什么吗？很简单呀，他是提前把号码段使用内存对外提供服务了，这里赞一下解决并发无敌的神奇-纯内存。
这就是他的第三特性，高并发，低延迟。

4.第四呢，他这个人比较简单，不需要复杂的操作，只需要告诉他你的基本资料就可以办理。
这就是他的第四特性，接入简单，RPC或者HTTP调用即可。

 

然后介绍一下Leaf的工作流程是怎么样的？
 

首先是这样的，每个办理窗口呢 就是一个Leaf, 为了让三个办理窗口之间不发生重复呢，他们想了一个办法，分段进行拿取。
一号办证窗口： 获取号段1001 ~ 2000
二号办证窗口： 获取号段2001 ~ 3000
三号办证窗口： 获取号段3001 ~ 4000
 

如下图所示：

这样就可以保证每个客户不管到任意一个窗口进行办理，那么他都不会使得办证的号码发生重复的情况。
A客户 一号窗口 从1 开始 一直自增到1900的时候号段使用的差不多，大约使用到90% 就可以让生产进行进行做好提前准备，准备下一批号段的生产，防止客户突然增多来不及更新使用。

以上的运行是不是非常完美呢？
但是大家试想一下有没有可能会出现这种情况。

一号办证窗口去获取号段的同时三号办证窗口刚好也没有了也去获取号段，这个时候可能就会造成两个人拿的相同的号段了，这不就导致了数据冲突了么？

 

如上图所示，可以清楚的看到，当出现并发的时候，是会导致获取相同号段的，所以这里的解决办法是什么呢？如下图所示

 

 

所以在这里解决的办法是只能有一个人先去更新号段，其他人先不要动， 等会 ，等机器分配完一个号段给一个窗口了，在去分配另外一个窗口。

你是不是觉得嗯，确实只要号段每次一人处理，就没有啥问题了，大家都在不同号段区间，嗯,完美了，可以安心使用了。

这个时候突然办证厅突然涌入一堆人，都要办理证件， 2000个的号段瞬间的发完了，这个时候怎么办，客户们等着着急了，

可是生产证件的机器处理时间有限呀，可能还在生产中呢，但是我们的leaf职员只知道机器在生产号码段，并不知道啥时候已经生产好了，这时候怎么办呢？

 

 这时候，数据库一直在忙这个生产号段，但是前方的客户过多，导致各个办证窗口刚获取的号段就使用完了，这个时候很明显我们就应该主动去询问数据库,但是为了防止并发访问造成的冲突，我们只需要喊一个人去询问即可。
哎呀老大哥，你的数据生成好了没有啊？ 我这边急着要呀。
机器老大哥说：可以了，可以了，拿去吧。 然后通知leaf的员工，马上切换号段，进行发号。

 

好啦，以上就是整体leaf的使用场景及其相关的原理，希望可以帮到你们。

有兴趣的小伙伴可以参考下图的源码，查看详细的处理过程。