设计一个分布式ID

为了保证全局唯一性可以用时间作为区分点一部分,时间尽可能细化,可以精确到毫秒,甚至是微秒和纳秒。如果是分布式系统有多态机器,可以根据机器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的值分别是1,2,3,4,5,步长都是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, 存在服务不可用风险

你可能感兴趣的:(笔记,分布式)