NotFound9

时间不一致一般不会有什么问题，只是丧失了一些业务含义，如果一些业务要求id跟生成时间必须一直到话。这种方案跟普通的获取ID的方案有额外的判断和CAS操作存储ID的时间开销和内存开销，而且发生了时间回拨也无法真正解决问题，只是多维持了一段时间。

> > https://www.jianshu.com/p/b1124283fc43 > > 这个解决方案需要依赖redis,是不是与原来雪花算法的初衷不一样了 目前几乎所有的分布式id生成框架都是有依赖的，因为需要对不同机器上生成的分布式id进行区分，所以每个部署了Leaf服务的ip:port都会有一个workID，Leaf依赖于Zookeeper去给每个ip:port分配一个workID，百度的uid-generator每次机器启动时依赖于数据库的自增键，分配一个workID。只是依赖强弱的区别，Leaf框架目前来看启动时，运行期间都是依赖于Zookeeper的，虽然说运行期间Zookeeper挂了，可以继续运行，但是会导致当前生成id的最大时间戳不能上报，而百度的uid-generator只在启动时依赖数据库，因为每次启动时获得的workID是不同的，下次启动时不需要复用上次的workID。 如果你要做到没有依赖，只能是在项目中的property配置文件中写一个映射表，对每个会部署分布式id服务的机器IP:port对应一个workId，也就是我fork了Leaf项目后，开发的local模式 项目地址：https://github.com/NotFound9/Leaf 介绍文章：https://juejin.im/post/5eaea4f4f265da7b991c4c31

#### “每个系统渲染像素不一样, 字体大小不同”： 当缓存里面没有这种字体下某字符对应的宽度时，会调用系统方法boundingRect来得到字符的宽度进行缓存的，所以不会因为系统不同，字体不同造成问题。 #### “换行方式”，需要考虑的问题有以下两个： 1. 当每一行的末尾容不下一个字符时，会从另起一行开始计算，造成的空余 因为现在的计算方式出于简便是将所有字符相加然后除以单行最大宽度得到行数，所以每一行末尾的空格可能会导致一些误差，但是可以通过在遍历时判断当前行数是否容不下一个字符，将这些换行导致的空余补上，由于是在宽度较小的情况下，行数较多时，容易造成计算误差，需要加上这些判断。但是我们的项目暂时没有发现算错的情况，就暂时没有加。 2. 有时候两行Label时，第一行没有显示满，末尾空出来一些空格 这是因为这些字全部排在一行，宽度不够，另起一行时，第二行只显示一两个字符会显得很空，所以系统渲染时就挪了几个字符到第二行。这只是系统在行数计算出来以后，对于排版的选择，不会影响我们的高度计算。

好的，感谢，一起学习进步！