精华内容
下载资源
问答
  • Leaf-snowflake方案完全沿用snowflake方案的bit位设计,即是“1+41+10+12”的方式组装ID号。对于workerID的分配,当服务集群数量较小的情况下,完全可以手动配置。Leaf服务规模较大,动手配置成本太高。所以使用...

    image

     

    Leaf-snowflake方案完全沿用snowflake方案的bit位设计,即是“1+41+10+12”的方式组装ID号。对于workerID的分配,当服务集群数量较小的情况下,完全可以手动配置。Leaf服务规模较大,动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的:

    1. 启动Leaf-snowflake服务,连接Zookeeper,在leaf_forever父节点下检查自己是否已经注册过(是否有该顺序子节点)。
    2. 如果有注册过直接取回自己的workerID(zk顺序节点生成的int类型ID号),启动服务。
    3. 如果没有注册过,就在该父节点下面创建一个持久顺序节点,创建成功后取回顺序号当做自己的workerID号,启动服务。

    image

    image

     

    弱依赖ZooKeeper

    除了每次会去ZK拿数据以外,也会在本机文件系统上缓存一个workerID文件。当ZooKeeper出现问题,恰好机器出现问题需要重启时,能保证服务能够正常启动。这样做到了对三方组件的弱依赖。一定程度上提高了SLA

    解决时钟问题

    因为这种方案依赖时间,如果机器的时钟发生了回拨,那么就会有可能生成重复的ID号,需要解决时钟回退的问题。

    image

    image

     

    参见上图整个启动流程图,服务启动时首先检查自己是否写过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}。

    由于强依赖时钟,对时间的要求比较敏感,在机器工作时NTP同步也会造成秒级别的回退,建议可以直接关闭NTP同步。要么在时钟回拨的时候直接不提供服务直接返回ERROR_CODE,等时钟追上即可。或者做一层重试,然后上报报警系统,更或者是发现有时钟回拨之后自动摘除本身节点并报警,如下:

     //发生了回拨,此刻时间小于上次发号时间
     if (timestamp < lastTimestamp) {
      			  
                long offset = lastTimestamp - timestamp;
                if (offset <= 5) {
                    try {
                    	//时间偏差大小小于5ms,则等待两倍时间
                        wait(offset << 1);//wait
                        timestamp = timeGen();
                        if (timestamp < lastTimestamp) {
                           //还是小于,抛异常并上报
                            throwClockBackwardsEx(timestamp);
                          }    
                    } catch (InterruptedException e) {  
                       throw  e;
                    }
                } else {
                    //throw
                    throwClockBackwardsEx(timestamp);
                }
            }
     //分配ID       
            

    原文:https://tech.meituan.com/2017/04/21/mt-leaf.html

    转载于:https://www.cnblogs.com/yx88/p/11285655.html

    展开全文
  • 分布式主键 Leaf-segment

    2019-09-28 15:27:33
    对于MySQL性能问题,可用如下方案解决:在分布式系统中我们可以多部署几台机器,每台机器设置不同的初始值,且步长和机器数相等。比如有两台机器。设置步长step为2,TicketServer1的初始值为1(1,3,5,7,9,11…...

    数据库生成

    以MySQL举例,利用给字段设置auto_increment_incrementauto_increment_offset来保证ID自增,每次业务使用下列SQL读写MySQL得到ID号。

    begin;
    REPLACE INTO Tickets64 (stub) VALUES ('a');
    SELECT LAST_INSERT_ID();
    commit;
    

    image

     

    这种方案的优缺点如下:

    优点:

    • 非常简单,利用现有数据库系统的功能实现,成本小,有DBA专业维护。
    • ID号单调自增,可以实现一些对ID有特殊要求的业务。

    缺点:

    • 强依赖DB,当DB异常时整个系统不可用,属于致命问题。配置主从复制可以尽可能的增加可用性,但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。
    • ID发号性能瓶颈限制在单台MySQL的读写性能。

    对于MySQL性能问题,可用如下方案解决:在分布式系统中我们可以多部署几台机器,每台机器设置不同的初始值,且步长和机器数相等。比如有两台机器。设置步长step为2,TicketServer1的初始值为1(1,3,5,7,9,11…)、TicketServer2的初始值为2(2,4,6,8,10…)。这是Flickr团队在2010年撰文介绍的一种主键生成策略(Ticket Servers: Distributed Unique Primary Keys on the Cheap )。如下所示,为了实现上述方案分别设置两台机器对应的参数,TicketServer1从1开始发号,TicketServer2从2开始发号,两台机器每次发号之后都递增2。

    TicketServer1:
    auto-increment-increment = 2
    auto-increment-offset = 1
    
    TicketServer2:
    auto-increment-increment = 2
    auto-increment-offset = 2
    

    假设我们要部署N台机器,步长需设置为N,每台的初始值依次为0,1,2…N-1那么整个架构就变成了如下图所示:

    image

    image

     

    这种架构貌似能够满足性能的需求,但有以下几个缺点:

    • 系统水平扩展比较困难,比如定义好了步长和机器台数之后,如果要添加机器该怎么做?假设现在只有一台机器发号是1,2,3,4,5(步长是1),这个时候需要扩容机器一台。可以这样做:把第二台机器的初始值设置得比第一台超过很多,比如14(假设在扩容时间之内第一台不可能发到14),同时设置步长为2,那么这台机器下发的号码都是14以后的偶数。然后摘掉第一台,把ID值保留为奇数,比如7,然后修改第一台的步长为2。让它符合我们定义的号段标准,对于这个例子来说就是让第一台以后只能产生奇数。扩容方案看起来复杂吗?貌似还好,现在想象一下如果我们线上有100台机器,这个时候要扩容该怎么做?简直是噩梦。所以系统水平扩展方案复杂难以实现。
    • ID没有了单调递增的特性,只能趋势递增,这个缺点对于一般业务需求不是很重要,可以容忍。
    • 数据库压力还是很大,每次获取ID都得读写一次数据库,只能靠堆机器来提高性能。

    Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话: >There are no two identical leaves in the world > “世界上没有两片相同的树叶”

    综合对比上述几种方案,每种方案都不完全符合我们的要求。所以Leaf分别在上述第二种和第三种方案上做了相应的优化,实现了Leaf-segment和Leaf-snowflake方案。

    Leaf-segment数据库方案

    第一种Leaf-segment方案,在使用数据库的方案上,做了如下改变: - 原方案每次获取ID都得读写一次数据库,造成数据库压力大。改为利用proxy server批量获取,每次获取一个segment(step决定大小)号段的值。用完之后再去数据库获取新的号段,可以大大的减轻数据库的压力。 - 各个业务不同的发号需求用biz_tag字段来区分,每个biz-tag的ID获取相互隔离,互不影响。如果以后有性能需求需要对数据库扩容,不需要上述描述的复杂的扩容操作,只需要对biz_tag分库分表就行。

    数据库表设计如下:

    +-------------+--------------+------+-----+-------------------+-----------------------------+
    | Field       | Type         | Null | Key | Default           | Extra                       |
    +-------------+--------------+------+-----+-------------------+-----------------------------+
    | biz_tag     | varchar(128) | NO   | PRI |                   |                             |
    | max_id      | bigint(20)   | NO   |     | 1                 |                             |
    | step        | int(11)      | NO   |     | NULL              |                             |
    | desc        | varchar(256) | YES  |     | NULL              |                             |
    | update_time | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
    +-------------+--------------+------+-----+-------------------+-----------------------------+
    

    重要字段说明:biz_tag用来区分业务,max_id表示该biz_tag目前所被分配的ID号段的最大值,step表示每次分配的号段长度。原来获取ID每次都需要写数据库,现在只需要把step设置得足够大,比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step,大致架构如下图所示:

    image

    image

     

    test_tag在第一台Leaf机器上是1~1000的号段,当这个号段用完时,会去加载另一个长度为step=1000的号段,假设另外两台号段都没有更新,这个时候第一台机器新加载的号段就应该是3001~4000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000,更新号段的SQL语句如下:

    Begin
    UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
    SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
    Commit
    

    这种模式有以下优缺点:

    优点:

    • Leaf服务可以很方便的线性扩展,性能完全能够支撑大多数业务场景。
    • ID号码是趋势递增的8byte的64位数字,满足上述数据库存储的主键要求。
    • 容灾性高:Leaf服务内部有号段缓存,即使DB宕机,短时间内Leaf仍能正常对外提供服务。
    • 可以自定义max_id的大小,非常方便业务从原有的ID方式上迁移过来。

    缺点:

    • ID号码不够随机,能够泄露发号数量的信息,不太安全。
    • TP999数据波动大,当号段使用完之后还是会hang在更新数据库的I/O上,tg999数据会出现偶尔的尖刺。
    • DB宕机会造成整个系统不可用。

    双buffer优化

    对于第二个缺点,Leaf-segment做了一些优化,简单的说就是:

    Leaf 取号段的时机是在号段消耗完的时候进行的,也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间,并且在这期间进来的请求也会因为DB号段没有取回来,导致线程阻塞。如果请求DB的网络和DB的性能稳定,这种情况对系统的影响是不大的,但是假如取DB的时候网络发生抖动,或者DB发生慢查询就会导致整个系统的响应时间变慢。

    为此,我们希望DB取号段的过程能够做到无阻塞,不需要在DB取号段的时候阻塞请求线程,即当号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段。这样做就可以很大程度上的降低系统的TP999指标。详细实现如下图所示:

    image

    image

     

    采用双buffer的方式,Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时,如果下一个号段未更新,则另启一个更新线程去更新下一个号段。当前号段全部下发完后,如果下个号段准备好了则切换到下个号段为当前segment接着下发,循环往复。

    • 每个biz-tag都有消费速度监控,通常推荐segment长度设置为服务高峰期发号QPS的600倍(10分钟),这样即使DB宕机,Leaf仍能持续发号10-20分钟不受影响。

    • 每次请求来临时都会判断下个号段的状态,从而更新此号段,所以偶尔的网络抖动不会影响下个号段的更新。

    Leaf高可用容灾

    对于第三点“DB可用性”问题,我们目前采用一主两从的方式,同时分机房部署,Master和Slave之间采用半同步方式[5]同步数据。同时使用公司Atlas数据库中间件(已开源,改名为DBProxy)做主从切换。当然这种方案在一些情况会退化成异步模式,甚至在非常极端情况下仍然会造成数据不一致的情况,但是出现的概率非常小。如果你的系统要保证100%的数据强一致,可以选择使用“类Paxos算法”实现的强一致MySQL方案,如MySQL 5.7前段时间刚刚GA的MySQL Group Replication。但是运维成本和精力都会相应的增加,根据实际情况选型即可。

    image

     

    同时Leaf服务分IDC部署,内部的服务化框架是“MTthrift RPC”。服务调用的时候,根据负载均衡算法会优先调用同机房的Leaf服务。在该IDC内Leaf服务不可用的时候才会选择其他机房的Leaf服务。同时服务治理平台OCTO还提供了针对服务的过载保护、一键截流、动态流量分配等对服务的保护措施。

    Leaf-segment方案可以生成趋势递增的ID,同时ID号是可计算的,不适用于订单ID生成场景,比如竞对在两天中午12点分别下单,通过订单id号相减就能大致计算出公司一天的订单量,这个是不能忍受的。

     

    原文:https://tech.meituan.com/2017/04/21/mt-leaf.html

     

    转载于:https://www.cnblogs.com/yx88/p/11285639.html

    展开全文
  • 简单介绍两种开源分布式主键生成器,UidGenerator和Leaf

    1.UidGenerator–百度开源分布式id生成器
    UidGenerator使用Java实现,基于Snowflake算法的唯一ID生成器。
    gitee地址:https://gitee.com/mirrors/UidGenerator

    UidGenerator在每次启动时,会把机器的host_name和port插入表中,把新纪录的id作为本实例的workerId,以此来保证每个实例在任何时间workerId的唯一性。

    UidGenerator提供了DefaultUidGenerator和CachedUidGenerator两种id生成器。
    DefaultUidGenerator是Snowflake算法的一种实现。
    CachedUidGenerator继承自DefaultUidGenerator,并做了以下两点改进:
    (1)使用未来时间,解决了Snowflake算法sequence天然存在的并发限制,及在出现时钟回拨时产生重复id的问题。
    (2)使用RingBuffer数组缓存预先生成的uid,并行化uid的生产和消费,最终使单机QPS可达600万,适用于高性能场景。
    RingBuffer填充uid时机:
    (1)RingBuffer初始化时,预先填充maxSequence个uid到RingBuffer。
    (2)take()消费时,获取uid前先检查剩余可用slot量(tail - cursor),如小于设定阈值paddingThreshold,则异步填充maxSequence个uid到RingBuffer。
    (3)通过Schedule线程定时填充maxSequence个uid到RingBuffer。可通过设置scheduleInterval启动定时填充功能。

    2.Leaf–美团点评分布式ID生成器
    Leaf 使用Java实现,提供两种生成ID的方式(Snowflake模式和号段模式),可以通过修改配置选择ID的生成方式。
    Snowflake模式,算法取自twitter开源的snowflake算法。
    号段模式,需要依赖数据库建立DB表。
    GitHub地址:https://github.com/Meituan-Dianping/Leaf
    官方文档地址:https://tech.meituan.com/2017/04/21/mt-leaf.html

    展开全文
  • 分布式主键生成学习

    2018-09-02 15:40:00
    https://tech.meituan.com/MT_Leaf.html 转载于:https://www.cnblogs.com/codeLei/p/9574027.html

    https://tech.meituan.com/MT_Leaf.html

    转载于:https://www.cnblogs.com/codeLei/p/9574027.html

    展开全文
  • 收藏一篇分布式环境下主键生成的策略,来自于美团: https://tech.meituan.com/2017/04/21/mt-leaf.html 转载于:https://www.cnblogs.com/baizhanshi/p/10500742.html
  • 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来存储索引数据,在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 信息安全:如果ID是连续的,恶意用户的扒取工作...
  • 分布式id leaf

    2020-06-16 15:30:47
    全局唯一 局部唯一 按情况保持递增 leaf 基于雪花算法 基于uuid 基于数据库主键 基于redis 基于zk etcd 基于leaf 基于uuid-generater
  • 在复杂分布式系统中,往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中,数据日渐增长,对数据分库分表后需要有一个唯一ID来标识一条数据或消息,数据库的...
  • Leaf是美团基础研发平台推出的一个分布式ID生成服务,名字取自德国哲学家、数学家莱布尼茨的一句话:“There are no two identical leaves in the world.”Leaf具备高可靠、低延迟、全局唯一等特点。Leaf项目已经在...
  • 分布式ID生成策略

    2020-06-02 17:05:03
    分布式ID生成策略前言1.数据库自增2.UUID3.snowflake算法4.snowflake扩展4.1百度UidGenerator4.2美团Leaf 前言 主键生成策略可以讲是一个系统最基本的问题,目前生成策略有多种,下面讲下我遇到的几种。 1.数据库...
  • 分布式id生成方式

    2019-04-28 14:48:29
    1、用户ID + 自增主键 2、UUID 3、美团 Leaf-segment数据库方案 4、美团 Leaf-snowflake方案 5、数据库主键设置起始值,递增数取决于分库分表数
  • 文章目录前言分布式ID的生成特性分布式ID的几种生成办法基于UUID优点缺点适用场景基于数据库主键自增优点缺点适用场景基于数据库多实例主键自增优点缺点适用场景基于类Snowflake算法优点缺点适用场景基于Redis生成...
  • 实现原理Leaf这个名字是来自德国哲学家、数学家莱布尼茨的一句话:There are no two identical leaves in the world"世界上没有两片相同的树叶"设置数据表主键自增是最简单的方案,缺点也很明显:强依...
  • 该jar包依赖springboot,封装了美团的leaf-parent, 服务器不同实例是通过数据库的主键生成表来确保id生成唯一的 只能在有数据源的模块中使用 如果使用模块中有springboot管理的数据源可以不用配置数据源 如果...
  • 这个ID会是数据库中的唯一主键,在它上面会建立聚集索引!ID生成的核心需求有两点:全局唯一趋势有序二,为什么要趋势有序以mysql为例,InnoDB引擎表是基于B+树的索引组织表;每个表都需要有一个聚集索引(clustered ...
  • Android代码-idleaf

    2019-08-06 07:49:16
    对于 Leaf——美团点评分布式ID生成系统 中介绍的 Leaf-segment数据库方案 生成唯一orderId的方案的一个实现。 在实现中使用双buffer优化,在第一个buffer使用50%的时候去加载另一个buffer的数据,这里分同步与异步...
  • mysql为什么不建议使用订单号或者...生成分布式电商业务唯一id的实现,可以参考:https://tech.meituan.com/2017/04/21/mt-leaf.html美团点评的这篇博客,这篇博客基本涵盖了目前所有的方式方法。但是,既然保证了...
  • mysql为什么不建议使用订单号或者其他形式的...生成分布式电商业务唯一id的实现,可以参考:https://tech.meituan.com/2017/04/21/mt-leaf.html美团点评的这篇博客,这篇博客基本涵盖了目前所有的方式方法。 但是...
  • 雪花算法中机器id保证全局唯一

    千次阅读 2019-03-09 12:52:02
    通常在生产中会用Twitter开源的雪花算法来生成分布式主键 雪花算法中的核心就是机器id和数据中心id, 通常来说数据中心id可以在配置文件中配置, 通常一个服务集群可以共用一个配置文件, 而机器id如果也放在配置文件...
  • 分布式ID的一些要求 (这段摘自美团Leaf开源项目) 全局唯一性:不能出现重复的ID号,既然是唯一标识,这是最基本的要求。 趋势递增:在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDBMS使用B-tree的数据结构来...
  • 1.为什么分 业务拆分,将一个大的业务拆分成多个小服务,服务之间通过RPC调用,不同服务的数据使用独立的数据库存储 应对高并发,读多写少...常见的是采用一个分布式发号器实现,Twitter的Snowflake,美团的leaf等..

空空如也

空空如也

1 2
收藏数 28
精华内容 11
关键字:

leaf分布式主键