分散システムに基づく7つのユニークID実装ソリューション、収集する価値がある

概要

システムの一意の ID は、システムを設計するときによく遭遇する問題であり、私たちはこの問題に苦労することがよくあります。さまざまなシナリオ、ニーズ、パフォーマンス要件に適した ID を生成する方法は多数あります。したがって、より複雑なシステムでは、複数の ID 生成戦略が使用される場合があります。

[[275648]]

分散IDの特徴

• 一意性: 生成された ID がネットワーク全体で一意であることを確認します。
• 規則的な増分: 生成された ID が特定のユーザーまたはビジネスに対して一定の数値で増分されることを確認します。
• 高可用性: ID が常に正しく生成されるようにします。
• 時間付き：IDに時間が含まれているため、取引日が一目でわかります。

以下では、いくつかの分散 ID 生成スキームを紹介します。

1. データベースの自動増分シーケンスまたはフィールド

最も一般的な方法です。データベース全体で一意のデータベースを活用します。

アドバンテージ：

1) シンプルで便利なコード、そして許容できるパフォーマンス。

2) 数値 ID は自然にソートされるため、ページングやソートが必要な結果に役立ちます。

欠点:

1) データベースごとに構文と実装が異なるため、データベースを移行する場合や複数のデータベース バージョンをサポートする場合には、これを処理する必要があります。

2) 単一データベースまたは読み取り/書き込み分離の場合、または 1 つのマスターと複数のスレーブの場合、生成できるマスター データベースは 1 つだけです。単一障害点のリスクがあります。

3) 性能が要求を満たさない場合、拡張が困難です。

4) 複数のシステムを統合したり、データの移行が必要になったりすると、非常に面倒な作業になります。

5) テーブルやデータベースを分割すると問題が発生します。

最適化計画:

単一のマスター データベースの場合、複数のマスター データベースが存在すると、各マスター データベースに設定される開始番号は異なりますが、ステップ サイズは同じであり、マスターの数になる場合があります。たとえば、Master1 は 1、4、7、10 を生成し、Master2 は 2、5、8、11 を生成し、Master3 は 3、6、9、12 を生成します。これにより、クラスター内で一意の ID を効率的に生成できるようになり、ID 生成データベース操作の負荷も大幅に軽減されます。

2. UUID

一般的な方法。データベースやプログラムを使用して生成することができ、通常は世界で唯一のものになります。

アドバンテージ：

1) シンプルで便利なコード。

2) ID 生成のパフォーマンスは非常に良好で、基本的にパフォーマンスの問題はありません。

3) 世界で唯一、データ移行、システムデータ統合、データベース変更などを簡単に処理できます。

欠点:

1) ソートを行わないと、トレンドが上昇する保証はありません。

2) UUID は文字列を使用して保存されることが多く、クエリ効率は比較的低くなります。

3) 収納スペースが比較的広い。大規模なデータベースの場合は、ストレージ容量の問題を考慮する必要があります。

4) 大量のデータが送信される

5) 読めない。

3. IDをバッチで生成する

一度に複数の ID をオンデマンドでバッチで生成します。各世代では、データベースにアクセスし、データベースを最大 ID 値に変更し、現在の値と最大値をメモリに記録する必要があります。

アドバンテージ：

IDが生成されるたびにデータベースにアクセスして負荷をかけることを回避し、パフォーマンスを向上します。

欠点:

これはローカル生成戦略であり、単一障害点があり、サービスの再起動により ID の不連続が発生します。

4. RedisがIDを生成する

データベースを使用して ID を生成するパフォーマンスが十分でない場合は、Redis を使用して ID を生成してみてください。これは主に、Redis がシングルスレッドであるという事実に依存しており、グローバルに一意の ID を生成するためにも使用できます。これは、Redis のアトミック操作 INCR と INCRBY を使用して実現できます。

より高いスループットを得るには、Redis クラスターを使用できます。クラスター内に 5 台の Redis サーバーがあるとします。各Redisの値はそれぞれ1、2、3、4、5に初期化でき、ステップの長さは5です。各Redisによって生成されるIDは次のとおりです。

答え: 1,6,11,16,21

B: 2,7,12,17,22

C: 3,8,13,18,23

4,9,14,19,24 （アメリカ）

E: 5,10,15,20,25

これを任意のマシンにロードするだけで、将来変更することが難しくなります。ただし、基本的には3～5台のサーバーで十分であり、それぞれが異なるIDを取得できます。ただし、ステップ サイズと初期値は事前に指定する必要があります。 Redis クラスターを使用すると、単一点障害の問題も解決できます。

また、毎日 0 から始まるシリアル番号を生成するには、Redis を使用する方が適しています。たとえば、注文番号 = 日付 + その日の自動増分番号。毎日 Redis でキーを生成し、INCR を使用してそれを蓄積することができます。

アドバンテージ：

1) データベースから独立しており、柔軟性と利便性に優れ、パフォーマンスもデータベースより優れています。

2) 数値 ID は自然にソートされるため、ページングやソートが必要な結果に役立ちます。

欠点:

1) システムに Redis がない場合、新しいコンポーネントを導入する必要があり、システムの複雑さが増します。

2) コーディングと設定の作業負荷が比較的大きい。

5. Twitterのスノーフレークアルゴリズム（現在使用しているもの）

Snowflake は Twitter のオープンソースの分散 ID 生成アルゴリズムであり、その結果は長い ID になります。スノーフレーク アルゴリズムは、19 桁以下の順序付けられた Long 整数を生成します。これは、分散環境のデータの主キーとして主に使用されます。

基本的な考え方は、41 ビットをミリ秒として使用し、10 ビットをマシン ID (データ センター用に 5 ビット、マシン ID 用に 5 ビット) として使用し、12 ビットをミリ秒内のシリアル番号 (つまり、各ノードは 1 ミリ秒あたり 4096 個の ID を生成できる) として使用し、最後に常に 0 となる符号ビットを使用することです。

スノーフレーク アルゴリズムは、独自のプロジェクトのニーズに合わせて変更できます。たとえば、将来のデータセンターの数、各データセンター内のマシンの数、統一されたミリ秒単位で可能な同時リクエストの数を推定して、アルゴリズムに必要なビット数を調整できます。

アドバンテージ：

1) データベースから独立しており、柔軟性と利便性に優れ、パフォーマンスもデータベースより優れています。

2) 単一のマシン上で ID が時間の経過とともに増加します。

欠点:

これは単一のマシン上では増分的ですが、分散環境が関係するため、各マシンのクロックを完全に同期することはできず、クロックがグローバルに増分的ではない場合があります。

6. Zookeeperを使用して一意のIDを生成する

Zookeeper は主に、znode データ バージョンを通じてシリアル番号を生成します。 32 ビットおよび 64 ビットのデータ バージョン番号を生成できます。クライアントはこのバージョン番号を一意のシリアル番号として使用できます。

Zookeeper は、一意の ID を生成するためにほとんど使用されません。これは主に、Zookeeper とマルチステップ API 呼び出しに依存する必要があるためです。競争が激しい場合は、分散ロックの使用を検討する必要があります。したがって、同時実行性の高い分散環境ではパフォーマンスは理想的ではありません。

7. MongoDBのオブジェクトID

MongoDB の ObjectId アルゴリズムと Snowflake アルゴリズムは似ています。軽量に設計されており、同じグローバルに一意な方法を使用して、さまざまなマシンで簡単に生成できます。 MongoDB は最初から分散データベースとして設計されており、複数のノードを処理することが中核的な要件となっています。シャード環境で生成するのがはるかに簡単になります。

MongoDB では、ObjectId 型の自動生成されたフィールド「_id」に頻繁に遭遇します。

以前、MySQL などのリレーショナル データベースを使用していたときは、主キーは自動増分に設定されていました。しかし、分散環境では、このアプローチは実行可能ではなく、競合が発生します。このため、MongoDB は ObjectId と呼ばれる型を主キーとして使用します。 ObjectId は 12 バイトの BSON 文字列です。バイト順では、次のように表されます。

• 4バイト: UNIXタイムスタンプ
• 3バイト: MongoDBを実行しているマシンを示します
• 2バイト: この_idを生成したプロセスを示します
• 3バイト: 乱数から始まるカウンターによって生成された値

同じマシン上の複数の同時プロセスによって生成される ObjectId が一意であることを保証するために、次の 2 バイトは ObjectId を生成したプロセス識別子 (PID) から取得されます。

12バイトのObjectId

最初の 9 バイトは、同じ秒間に異なるマシン上の異なるプロセスによって生成される ObjectId が一意であることを保証します。最後の 3 バイトは自動的に増加するカウンターであり、同じプロセスによって同じ秒間に生成される ObjectId も異なることが保証されます。各プロセスは、同じ秒間に最大 2563 (16777216) 個の異なる ObjectId を持つことができます。