米国のグループのリーフクラスタデータの生成は、IDを生成しました

https://tech.meituan.com/2017/04/21/mt-leaf.htmlからの振替

複雑な分散システムでは、多くの場合、一意に識別されるデータ及びメッセージの大量を必要とします。金融、支払い、ケータリング、ホテル、猫の目の映画や他の製品、システム、データが成長し、データやニュースデータのサブライブラリーのサブテーブルの一部を識別するための固有のIDの必要性を米国のグループのレビューと同様に、IDデータベースをインクリメント明らかに需要を満たすことができない。特に、このような順序ことを、ライダーは、クーポンもユニークIDのロゴを行うために必要とされています。この時点では、グローバルに一意なIDが必要ですシステムで生成することができます。ダウン要約、およびID番号そのための要件は何というビジネスシステム？

グローバルに一意な：それは基本的な要件である一意の識別子であるため、重複するID番号が表示されないことができます。
インクリメンタルトレンド：ほとんどのRDBMSのデータ構造は、インデックスBツリーデータ、我々は秩序ある書き込み性能を確保するために、主キーを使用するようにしてください上記の選択に主キーを格納するために使用されるので、MySQLのInnoDBエンジンを使用するには、クラスタ化インデックスです。
単調に増加する：特定のIDより大きいIDを確保する、例えばバージョン番号、取引の特別なニーズは、ソーティングIMメッセージをインクリメントします。
情報セキュリティ：IDが連続している場合は、Paの悪意のあるユーザーが直接オーダーをダウンロードするには、指定されたURLに基づいて、行うことは非常に簡単な仕事を取るために、注文番号はさらに危険であれば、私たちは直接、単一の日の量のためにその競争を知っています。そのため、いくつかのシナリオでは、それは、定期的に不規則なIDを必要としないことがあります。

123は、同じ方式が満たすことができない使用して、上記3種類のシーン、3及び4需要または相互に排他的に対応します。

また、ID番号システム生成されたビジネスの独自のID番号の要件、および可用性の要件に加えて、同時にID生成システム障害、全体の米国のグループの有料レビュー、クーポンはクーポンを発行し、他の主要ライダーがすることができない単一のアクションを送信する場合、想像非常に高く、災害をもたらすだろう、実行、。

IDは、次の操作を行う必要があり、システムを生成することにより、要約します：

平均遅延と遅延TP999は、できるだけ低いこと。
可用性5 9。
高QPS。

UUID

：32桁の16進数、5つのセクションに分けハイフン、8-4-4-4-12 36文字例の形の標準タイプのUUID（汎用一意識別子）550e8400-e29b-41d4-a716-446655440000これまで、産業の総詳細な仕様は、IETF UUIDによって発行されたとして、5つの方法は、UUIDを生成するための汎用一意識別子（UUID）URN名前空間の。

利点：

パフォーマンスは非常に高いです：ローカルなしネットワークの消費量を生成しません。

短所：

収納しやすい：UUID長い、128ビットバイト16、36は、一般的なシーンの多くは適用されない、文字列の長さを示します。
安全でない情報：漏洩をもたらすことができるMACアドレス生成アルゴリズムのUUIDベースのMACアドレスは、この抜け穴はメリッサウイルス作成者の位置を見つけるために使用されてきました。
IDは、次のような主キーのようになります。特定の環境におけるいくつかの問題は、DBの主キーシーン、UUID非常にNAがあるんです。

①できるだけ短く明確な提案を主キーを持つMySQLの公式は、[4]、長さはUUID 36文字が要件を満たしていないしようとします。

クラスタ化インデックス以外のすべてのインデックスがセカンダリインデックスとして知られています。InnoDB内で、セカンダリインデックスの各レコードには、行の主キー列、ならびに二次インデックスに指定された列を含んでいます。*** InnoDBは、主キーが長い場合は、二次インデックスがより多くの領域を使用する***。クラスタ化インデックスの行を検索するために、この主キー値を使用するので、短い主キーを有することが有利です。

MySQLへの有害な指標②：InnoDBエンジンでデータベースの主キーとして場合は、UUID障害は、位置データが頻繁に変化が真剣にパフォーマンスに影響を与える可能性があります。

クラススノーフレークスキーム

実施形態のこの種は、一般的に分割されている名前空間のプログラムは、64ビットのマルチステージ、別マーキングマシンに分割されているアルゴリズムIDを生成する（より一般的に、それは別々に分析されるためUUIDが考えられます）示されるように、時間などは、例えば、64ビットスノーフレークに、それぞれ以下の図（ネットワークからの画像）を表します。

画像

41ビット時間が表すことができる（1L << 41）/（1000L * 3600 * 24 * 365）= 69歳、10ビットマシンは、それぞれのマシン1024表すことができます。私たちはIDC部門の必要性を持っている場合は、また、10ビットは、IDCに5ビットを分割することができ、作業に5ビットマシンを指しています。これは32 IDC、機械32を表すことができ、各IDCは、自分のニーズに応じて定義することができることができます。12増分シーケンス番号が2 ^ 12 ID、409.6ワット/秒から約理論的QPSスノーフレークスキーマを表すことができる、この割り当ては確保できる任意のID IDCのいずれか機械生成任意ミリ秒でそれは異なっています。

このアプローチの長所と短所は以下のとおりです。

利点：

シーケンスの高い、低エネルギー自給ミリ秒は、全体のIDは、トレンドにインクリメントされます。
システムは、サービス展開、高い安定性と、パフォーマンスのIDが非常に高い生成、サード・パーティのデータベースに依存しません。
ビットビットは、その事業特性に応じて、非常に柔軟に割り当てることができます。

短所：

強い依存のマシンクロック、マシンのクロックFaをする結果となるコールバックが繰り返されたり、サービスが利用できないされている場合。

アプリケーション例MongdbオブジェクトID

オブジェクトID MongoDBの公式文書では、最終的に24進長として識別4 + 3 + 2 + 3の方法により、12バイトの「時間エンコーディング+ + PID + INC」によってカウント等スノーフレークすることができますシステムの文字。

データベースの生成

MySQLの例では、フィールド設定を使用auto_increment_incrementし、auto_increment_offset自己増力IDは、MySQLは以下のSQLを使用して得られた各サービスは、ID番号を読み取ることを保証します。

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

画像

次のようにこのアプローチの長所と短所は以下のとおりです。

利点：

既存のデータベースシステムの機能実現、小型のコスト、DBAプロのメンテナンスを使用して、非常にシンプル。
ID番号は単調にインクリメントは、サービスIDのためのいくつかの特別な要件を達成することができます。

短所：

システムが利用できないときに強い依存性DB、DB異常は、致命的な問題です。マスターコピーから、例外的な状況でのデータの一貫性を確保することができるが、難しいの可用性を高めるように構成することができます。主な矛盾から切り替えた場合、重複Faを生じ得ます。
MySQLの読み取りおよび書き込みのパフォーマンスを、単一のパフォーマンスのボトルネックで発行されたID番号。

对于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

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

系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做？假设现在只有一台机器发号是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

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

采用双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号相减就能大致计算出公司一天的订单量，这个是不能忍受的。面对这一问题，我们提供了 Leaf-snowflake方案。

image

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

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

image

弱依赖ZooKeeper

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

解决时钟问题

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

image

参见上图整个启动流程图，服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

若写过，则用自身系统时间与leaf_forever/${self}节点记录时间做比较，若小于leaf_forever/${self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警。
若未写过，证明是新服务节点，直接创建持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize。
若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约。
否则认为本机系统时间发生大步长偏移，启动失败并报警。
每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}。

強い依存クロックに、機械作業のNTPの同期は、第2レベルのロールバックを引き起こす可能性があり、時間の要件、より敏感、私たちは、あなたが直接NTPの同期をオフにすることができますことをお勧めします。直接クロックは、追いつくためにクロックとして直接コールバックのリターンERROR_CODEを、サービスを提供していないとき。次のようにまたは1回の再試行を行い、その後、警報システムに報告、時計や自動コールバックを持っていると、アラームノード自体を除去した後にすることが分かっています。

 //发生了回拨，此刻时间小于上次发号时间
 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

その時は、コールバックすることを確認するため、リーフ・スノーフレーク戦略機械の部品があったうるう秒、2017年に登場し、ラインから判断すると、ビジネスへの影響を避けるために管理。

米国のグループの葉は、社内の金融サービスは、支払取引、レストラン、持ち帰り、ホテル、観光を含め猫の目の映画やビジネスの他の多くの行をレビュー。QPSは5ワット/ sで、TP999の1msの近くで測定された圧力ができ、機械4C8Gの葉の現在のパフォーマンスは、ほとんどの企業のニーズを満たすことができました。その高性能SLAとサービスを保証しなければならない、我々はまだ唯一のパスラインに達しており、改善の余地がたくさんある、公共の会社の内部技術インフラとして、億の日々の量を提供する番号を呼び出します。

CHEOWトンは、米国のグループは、中に主に関与インフラチームのメンバーをレビューMTRACE米国のグループ大規模な分散リンクトラッキングシステムの発電システムリーフIDと美しさのグループの開発分散レビュー。勤務アリババ、2016年7月に米国のグループに参加しました。