访问：:8080/api/segment/get/leaf-segment-test，结果正常返回，感觉没毛病，但当查了一下数据库表中数据时发现了一个问题。
通常在用号段模式的时候，取号段的时机是在前一个号段消耗完的时候进行的，可刚刚才取了一个ID，数据库中却已经更新了max_id，也就是说leaf已经多获取了一个号段，这是什么鬼操作？
Leaf为啥要这么设计呢？
Leaf 希望能在DB中取号段的过程中做到无阻塞！
当号段耗尽时再去DB中取下一个号段，如果此时网络发生抖动，或者DB发生慢查询，业务系统拿不到号段，就会导致整个系统的响应时间变慢，对流量巨大的业务，这是不可容忍的。
所以Leaf在当前号段消费到某个点时，就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做很大程度上的降低了系统的风险。
那么某个点到底是什么时候呢？
这里做了一个实验，号段设置长度为step=10，max_id=1，
当我拿第一个ID时，看到号段增加了，1/10
当我拿第三个Id时，看到号段又增加了，3/10
Leaf采用双buffer的方式，它的服务内部有两个号段缓存区segment。当前号段已消耗10%时，还没能拿到下一个号段，则会另启一个更新线程去更新下一个号段。
简而言之就是Leaf保证了总是会多缓存两个号段，即便哪一时刻数据库挂了，也会保证发号服务可以正常工作一段时间。
通常推荐号段（segment）长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
优点：
Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。
缺点：
ID号码不够随机，能够泄露发号数量的信息，不太安全。
DB宕机会造成整个系统不可用（用到数据库的都有可能）。
二、Leaf-snowflakeLeaf-snowflake基本上就是沿用了snowflake的设计，ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 机房ID（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。
Leaf-snowflake不同于原始snowflake算法地方，主要是在workId的生成上，Leaf-snowflake依靠Zookeeper生成workId，也就是上边的机器ID（占5比特）+ 机房ID（占5比特）。Leaf中workId是基于ZooKeeper的顺序Id来生成的，每个应用在使用Leaf-snowflake时，启动时都会都在Zookeeper中生成一个顺序Id，相当于一台机器对应一个顺序节点，也就是一个workId。
Leaf-snowflake启动服务的过程大致如下：
启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。
但Leaf-snowflake对Zookeeper是一种弱依赖关系，除了每次会去ZK拿数据以外，也会在本机文件系统上缓存一个workerID文件。一旦ZooKeeper出现问题，恰好机器出现故障需重启时，依然能够保证服务正常启动。