美团发行人Leaf-snowflake方案Leaf-snowflake方案完全沿用了snowflake方案的位设计，即“1+41+10+12”的组装方式身份证号。对于workerID分配，当服务集群数量较少时，可以手动配置。Leaf服务规模大，手动配置成本太高。所以利用Zookeeper持久化时序节点的特性，自动为snowflake节点配置wokerID。Leaf-snowflake是按照以下步骤启动的：启动Leaf-snowflake服务，连接Zookeeper，查看是否已经注册到leaf_forever父节点下（是否有子节点按此顺序）。如果已经注册，取回自己的workerID（zk序列节点生成的int类型ID号），启动服务。如果没有注册，在父节点下创建一个持久化序列节点。创建成功后，取回序列号作为你的workerID号，启动服务。弱依赖ZooKeeper，除了每次去ZK取数据外，还会在本地文件系统缓存一个workerID文件。当ZooKeeper出现问题，恰好机器出现问题需要重启的时候，可以保证服务能够正常启动。这样就实现了对三方组件的弱依赖。SLA在一定程度上是为了解决时钟问题而改进的，因为这个解决方案依赖于时间。如果机器时钟回拨，可能会产生重复的ID号，需要解决时钟回拨的问题。整个启动流程图见上图。服务启动时，首先检查是否写入了ZooKeeper的leaf_forever节点：如果写入了，则将自己的系统时间与leaf_forever/${self}节点的记录时间进行比较，如果小于leaf\_forever/$对于{self}时间，认为机器时间已经大步回调，服务启动失败，告警。如果没有写入，证明是新的服务节点，直接创建一个持久化节点leaf_forever/${self}写入自己的系统时间，然后综合比较其他叶子节点的系统时间判断自己是否自己的系统时间是准确的。具体方法是取leaf_temporary下所有临时节点（都是运行的Leaf-snowflake节点）的ServiceIP:Port，然后通过RPC请求所有节点的系统时间，计算sum(time)/nodeSize。如果abs(systemtime-sum(time)/nodeSize)
