有这样一个场景：leaf服务运行一段时间，流量较大，此时的步长很长（假如一直维持在MAX_STEP,即10万）。当某时刻current segment的数据消费10%，系统会异步准备next segment。当current segment消费了10.01%数据时，此时leaf服务挂了。然后又重启服务。你会发现segment浪费很严重。如何去解决这个问题？

if (cache.containsKey(key)) {
            SegmentBuffer buffer = cache.get(key);
            if (!buffer.isInitOk()) {
                synchronized (buffer) {
                    if (!buffer.isInitOk()) {
                        try {
                            updateSegmentFromDb(key, buffer.getCurrent());
                            logger.info("Init buffer. Update leafkey {} {} from db", key, buffer.getCurrent());
                            buffer.setInitOk(true);
                        } catch (Exception e) {
                            logger.warn("Init buffer {} exception", buffer.getCurrent(), e);
                        }
                    }
                }
            }
            return getIdFromSegmentBuffer(cache.get(key));
        }

if containsKey then get

因为Leaf框架是沿用snowflake的位数分配，

最大41位时间差+10位的workID+12位序列化，但是由于snowflake是强制要求第一位为符号位0，否则生成的id转换为十进制后会是复试，但是Leaf项目中没有对时间差进行校验，当时间戳过大或者自定义的twepoch设置不当过小，会导致计算得到的时间差过大，转化为2进制后超过41位，且第一位为1，会导致生成的long类型的id为负数，例如当timestamp = twepoch+2199023255552L时， 此时在生成id时，timestamp - twepoch会等于2199023255552，2199023255552转换为二进制后是1+41个0，此时生成的id由于符号位是1，id会是负数-9223372036854775793

 long id = ((timestamp - twepoch) << timestampLeftShift) | (workerId << workerIdShift) | sequence;

虽然这是很特殊的一种情况，但是我看百度uid-generator也考虑到了这种情况，代码中有对这种情况的判断，所以我觉得还是Leaf也有必要修复一下，所以我提了这个PR https://github.com/Meituan-Dianping/Leaf/pull/105 对这个问题进行了修复，希望美团的朋友们有空可以看一看。

另外美团对于Leaf的介绍文章里面对于snowflake算法介绍用的配图存在错误，序列号的位数分配应该是12位，而不是10位，不然总位数不是63位。

当步长设置为50。然后运行SegmentIDGenImplTest中的测试方法，循环5000次，就会报错： Both two segments in SegmentBuffer{key='leaf-segment-test', segments=[Segment(value:53,max:51,step:50), Segment(value:103,max:101,step:50)], currentPos=1, nextReady=false, initOk=true, threadRunning=true, step=50, minStep=50, updateTimestamp=1556434867190} are not ready!

从错误信息来看，threadRunning=true表示当前buffer正在填充数据，但是获取nextID的逻辑并没有等待数据填充完，就尝试获取导致报错

[WARNING] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:528) at java.lang.Thread.run (Thread.java:745) Caused by: org.springframework.boot.context.embedded.tomcat.ConnectorStartFailedException: Connector configured to listen on port 8080 failed to start at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.checkThatConnectorsHaveStarted (TomcatEmbeddedServletContainer.java:237) at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer.start (TomcatEmbeddedServletContainer.java:213) at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.startEmbeddedServletContainer (EmbeddedWebApplicationContext.java:308) at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.finishRefresh (EmbeddedWebApplicationContext.java:147) at org.springframework.context.support.AbstractApplicationContext.refresh (AbstractApplicationContext.java:546) at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh (EmbeddedWebApplicationContext.java:124) at org.springframework.boot.SpringApplication.refresh (SpringApplication.java:693) at org.springframework.boot.SpringApplication.refreshContext (SpringApplication.java:360) at org.springframework.boot.SpringApplication.run (SpringApplication.java:303) at org.springframework.boot.SpringApplication.run (SpringApplication.java:1118) at org.springframework.boot.SpringApplication.run (SpringApplication.java:1107) at com.sankuai.inf.leaf.server.LeafServerApplication.main (LeafServerApplication.java:10) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke (Method.java:498) at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:528) at java.lang.Thread.run (Thread.java:745) [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 51.736 s [INFO] Finished at: 2019-03-08T10:23:55+08:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:1.5.18.RELEASE:run (default-cli) on project leaf-server: An exception occurred while running. null: InvocationTargetException: Connector configured to listen on port 8080 failed to start -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

snowflake模式下获取id需要输入一个毫无用处的字符串，给我的感觉怪怪的。这里这么处理感觉没有意义的，完全可以写两个接口，匹配不同的模式。是不是因为开源版本为了方便？想问一下大佬。 我这边在实现rpc调用方式，所以觉得可以新建一个模块一些api放入这个模块就可以啦，新建两个接口，snowflake模式获取就不需要输入没有意义的一个字符串了。

https://github.com/Meituan-Dianping/Leaf/blob/76301dcb45bcbcc594f55ece6b1c0a01886edf84/leaf-core/src/main/java/com/sankuai/inf/leaf/snowflake/SnowflakeZookeeperHolder.java#L85-L92

workerID = Integer.parseInt(nodeKey[1]); 获取到的为leaf_name的值 改为workerID = Integer.parseInt(nodeKey[nodeKey.length - 1]);

官方博客介绍snowflake模式下整个启动流程如下：

服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

1. 若写过，则用自身系统时间与leaf_forever/${self}节点记录时间做比较，若小于leaf_forever/${self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警。
2. 若未写过，证明是新服务节点，直接创建持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize。
3. 若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约。
4. 否则认为本机系统时间发生大步长偏移，启动失败并报警。
5. 每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}。

请问有关第2步、第3步临时节点leaf_temporary的相关逻辑，源码中好像没有，是否是版本更新摒弃了这一部分逻辑。

Hi Leaf Community,

初来乍到，多多包涵，有个问题想请教下。

当前 master (revision: 86a6441d263497b9f9ee321de13422b9c63f0c06) 中，SnowflakeIDGenImpl#get 方法声明如下：

public synchronized Result get(String key) 

从源码中得出两个实现细节：

1. SnowflakeIDGenImpl#get 方法是加了对象级别的可重入锁
2. 参数 key 在 get方法的实现里没用到
3. SnowFlakeIdGenImpl 在 SnowfalkeService 是单例，SnowflakeSerivce 也是单例
4. 由 1 2 3 可以知道，对于某个 Leaf-Server 实例，所有到 /api/snowflake/get/{key} 的请求，共享同一个 SnowflakeIdGenImpl，即属于同一个 ID 序列，可能存在两个风险
   1. 不同的 key 共享同一个 ID 序列，导致 sequence 用的比较快，可能有在一个毫秒内耗完 sequence 的风险
   2. 在 SnowflakeIDGenImpl#get 方法上做同步，会降低并发性能，这里可能会成为瓶颈

基于上述理解，有几个问题想请教下：

1. 对于 leaf server snowflake，有没有参考数据，单机到多少 qps 是个比较安全的值
2. 在 SnowflakeIDGenImpl#get 方法上做同步，有什么设计上的考虑，如果改成在 key 级别做同步会有什么坑，潜在的问题可能是 key 如何维护

我提了一个PR#118，让让Segment模式生成的ID不连续，保证信息安全性。

在Leaf的官方介绍文章中曾经提到分布式ID应该保证信息安全性，

4.信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

让ID不连续，否则容易被恶意爬取和泄露单量，目前使用snowflake模式生成ID时是有取随机数相关的逻辑来保证ID不连续的，但是如果是Leaf-segment数据库方案来生成ID，每次从数据库取完ID，都是存储在内存中，发放给业务项目，所以运行期间，使用的ID都是连续的，竞争对手很容易通过在两天中午12点分别下单，通过订单id号相减就能大致计算出公司一天的订单量。如果我们在每次从数据库取一个分段的ID时，计算一个随机数，丢弃掉随机数数量的ID，这样就可以保证ID不连续，保证Leaf-segment数据库方案来保证生成ID的安全性。

源代码：SegmentIDGenImpl中updateSegmentFromDb()方法中计算当前ID分段最小值

long value = leafAlloc.getMaxId() - buffer.getStep();

修改后的代码

 int bound = buffer.getStep()/20;//随机值最大取值为5%的Step，主要考虑到buffer中id使用量超过10%就会触发另一个buffer的更新，所以我们取的随机值的最大值小于10%会好一些，不然一开始就触发更新了。
int randomValue = RANDOM.nextInt(bound);//生成随机值
long value = leafAlloc.getMaxId() - buffer.getStep() + randomValue;//丢弃随机值数量的id，让id不连续，保证id安全性

现象描述： 为防止单台leaf-server出现故障。将leaf-server 多机器注册到注册中心后，例如spring cloud的eureka注册中心，然后对外提供服务。会出现id跳动生成，不连续。 例如在step为2000的情况下，id从1开始，如果启动三台机器：A机器1-2000 B机器 2001-4000 C机器4001-6000 则ID生成会呈现 1 2001 4001 2 2002 4002 3 2003 4003的现象

能不能把cache存放在redis里呢？效率会有影响吗？还是说做HA，保证一台挂了，另外一台马上起来。永远只要一台提供服务？

Bumps spring-beans from 4.3.18.RELEASE to 5.2.20.RELEASE.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

目前Spring版本2.6.x，通过mvn clean install -Dmaven.test.skip=true方式引入 leaf-boot-starter com.sankuai.inf.leaf 1.0.1-SNAPSHOT （至于为什么是1.0.1-SNAPSHOT是因为改了里面的RELEASE为SNAPSHOT） 然后启动显示报错： leaf的spring版本5.2.9，spring-boot版本2.3.4.RELEASE，mysql-connect-java 8.0.13, druid 版本1.1.10 通过修改mybaits-spring版本和mybaits版本均不行

Bumps log4j-core from 2.7 to 2.17.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

` //must set value before set max long value = leafAlloc.getMaxId() - buffer.getStep();

segment.getValue().set(value);

segment.setMax(leafAlloc.getMaxId());

segment.setStep(buffer.getStep());

` why must set value before set max?