深夜小网站,网站建设流程 费用,南京网站搜索优化,网络推广与营销为了保证全局唯一性可以用时间作为区分点一部分#xff0c;时间尽可能细化#xff0c;可以精确到毫秒#xff0c;甚至是微秒和纳秒。如果是分布式系统有多态机器#xff0c;可以根据机器ID再进行以下区分。如哦机器运行的特别快#xff0c;1毫秒有大量ID生成#xff0c;可… 为了保证全局唯一性可以用时间作为区分点一部分时间尽可能细化可以精确到毫秒甚至是微秒和纳秒。如果是分布式系统有多态机器可以根据机器ID再进行以下区分。如哦机器运行的特别快1毫秒有大量ID生成可以结合实际限制下实际生成的ID数目。 如果N台机器去ID生成服务器的服务端得到全局ID很容易保证全局唯一切自增的但是存在单点失效的问题不满足高可用。 雪花算法
生成的结果是一个int64的数据。核心思想是使用41bit作为毫秒数10bit作为机器的ID(5个bit是数据中心5个bit的机器ID),12bit作为毫秒内的流水号意味着每个节点再每毫秒可以产生 4096 个 ID, 最后还有一个符号位永远是0.
优点 优点是毫秒书在高位自增序列在低位整个ID是趋势递增的。不依赖数据库等第三方系统一服务的方式部署稳定性更高生成ID的性能也是非常高的。可以根据自身业务特性分配bit位非常灵活。
缺点 强依赖机器时钟如果机器上时钟回拨会导致号重复或者服务会处于不可用状态。
Redis生成ID
因为 Redis 是单线程的也可以用来生成全局唯一ID。可以用Redis的原子操作INCR和INCRBY来实现。使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis可以初始化每台Redis的值分别是12345步长都是5各Redis生成的ID如下A: 1,6,11,16; B: 2,7,12,17; C: 3,8,13,18; D: 4,9,14,19; E: 5,10,15,29。负载到哪台机器提前定好未来很难做修改。3-5台服务器基本能安祖需求但步长和初始值一定需要事先确定使用Redis集群也可以解决单点故障问题。
**优点**不依赖数据库灵活方便且性能优于数据库数字ID天然排序对分页或需要排序的结果很有帮助。
**缺点**如果系统中没有Redis需要引入新的组件增加系统复杂度需要编码和配置的工作量比较大。
UUID
可以利用数据库也可以利用程序生成一般全球唯一。UUID是由32个16进制数字组成所以每个UUID的长度是128位16^32 2 ^128)。UUID有多个实现版本影响它的因素包括时间网卡MAC地址自定义Namespace等等。
优点简单代码方便生成ID性能非常好基本不会有性能问题全球唯一在遇见数据迁移系统数据合并或者数据库变更情况下可以从容应对。
缺点没有排序无法保证确实递增UUID往往是使用字符串存储查询的效率比较低存储空间比较大如果是海量数据库就需要哦考虑存储量的问题传输数据量大不可读。
美团Leaf
Leaf-segment
直接用数据库自增ID充当分布式ID减少对数据库的频繁操作。过程是从数据库批量的获取自增ID每次从数据库取出一个号段范围例如(1,10000]代表10000个ID业务服务将号段生成1~10000的自增ID并加载在内存在当前号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做很大程度上的降低了系统的风险。Leaf-segment采用双buffer的发过誓他的服务内部有两个号段缓存qusegment.当前号段已消耗10%时还没能拿到下一个号段则会另启一个更新线程去更新下一个号段。Leaf保证了总是会多缓存两个号段即便那一时刻数据库挂了也会保证发号服务可以正常工作一段时间。通常推荐号段(segment)长度设置为服务高峰期发号QPS的600倍(10分钟这样即使DB宕机Leaf仍能持续发号10-20分钟不受影响。
tip biz_tag
针对不同业务需求用biz_tag字段来隔离如果以后需要扩容时只需要对biz_tag分库分表即可
优点 Leaf服务可以很方便的线性扩展性能完全能够支持大多数业务场景容灾行性高Leaf服务内部有号段缓存即使DB宕机短时间内Leaf仍能正常对外提供服务。
缺点 ID号码不够随机能够泄漏发号数量的信息不太安全DB宕机会造成整个系统不可用用到数据库的都有可能
Leaf-snowflake
Leaf-snowflake基本上就是沿用了snowflake的设计ID组成结构正数位占1比特时间戳占41比特机器ID(占5bit)机房ID(占5 bit) 自增值占12bit) 总共54比特组成的一个int64类型。不同点主要是在workId的生成上Leaf-snowflake依靠Zookeerper生成workId。Leaf中workId时基于Zookeeper中生成一个顺序Id,相当于一台机器对应一个顺序节点。
启动服务的过程大致如下启动Leaf-snowflake服务连接Zookeeper, 在leaf_foever父节点下检查自己是否已经注册过如果有注册过直接取回自己的workerId(zk顺序节点生成的int类型ID号。启动服务如果没有注册过就在该父节点下面创建一个持久顺序节点创建成功后取回顺序号当作自己的workerID号启动服务。Leaf-snowflake对Zookeeper是一种弱依赖关系除了每次会去ZK拿数据以外也会在本机文件系统上缓存一个workerID文件。一旦Zookeeper出现问题敲好机器出现故障需重启时依然能够保证服务正常启动。
优点 ID号码是趋势递增的8 byte的64位数据满足上述数据库存储的主键要求。
缺点 依赖Zookeeper, 存在服务不可用风险
