分散IDとは何かを理解するのに役立つ記事

[[409671]]

1. 分散IDとは何ですか?

分散システムでは、データ、メッセージ、HTTPリクエストなどを一意に識別するために、グローバルに一意なIDが必要になることがよくあります。このグローバルに一意なIDは分散IDと呼ばれます。

2. 分散 ID が必要な理由は何ですか?

1. ID にデータベースの自己増分型を使用すると、分散システムでシャーディングが必要な場合に、同一のテーブルが 2 つ存在し、主キーの競合が発生する可能性があります。

2. 電子商取引の注文番号は、最も単純な生成ルールである自己増分方式を使用します。しかし！この注文番号はシリアル番号と同じなので、競合他社が貴社の実際の運営情報を簡単に見ることができるようになります。

3. 分散 ID はどのような条件を満たす必要がありますか?

グローバルに一意: IDはグローバルに一意である必要があります

高パフォーマンス: 高可用性と低レイテンシ。 ID 生成の応答は高速である必要があります。そうでないと、ビジネスのボトルネックになります。

高可用性: 100% の可用性は誤解を招く恐れがありますが、可能な限り 100% の可用性に近づける必要があります。

容易なアクセス: すぐに使用できる設計の原則に従い、システムの設計と実装を可能な限りシンプルに保つ

増加傾向: 増加傾向にあるのが最適です。この要件は特定のビジネスシナリオによって異なり、通常は厳密に必須ではありません。

セキュリティ: ID が継続的に生成されると、業務情報が漏洩し、推測される可能性もあるため、ランダムで不規則な ID が必要です。

読みやすさ: 長くなりすぎないようにしましょう。アフターサービス中にユーザーがすでに不安な気分になっていると想像してください。非常に長い注文番号を報告/入力するように依頼すると、エラー率が高くなりやすく、顧客のイライラが増すだけです。注文番号が長すぎる場合は、別の方法として、文章に分割します。

スケーラビリティ: Taobao の注文番号は元々 12 桁または 14 桁でしたが、現在は 16 桁になっています。ウェブサイトの取引量は年々増加しており、必然的に注文番号も長くなっていきます。

4. 分散ID生成方式

言語
データベース自動増分ID
データベースマルチマスターモード
数値セグメントモード
レディス
スノーフレーク
美団（葉）

注: 主流のID生成方式は、データベースセグメントモードとスノーフレークアルゴリズムに基づいています。

5. 利点と欠点

1. UUIDに基づく

アドバンテージ：

生成は十分に単純で、ローカル生成はネットワークを消費せず、ユニークである

欠点:

順序付けされていない文字列、トレンドの自動増加機能なし
具体的なビジネス上の意味はない
文字列が長すぎる場合 (16 バイト、128 ビット、または 36 ビット)、保存およびクエリ時に MySQL のパフォーマンスが大幅に低下します。 MySQL では、主キーはできる限り短くすることを公式に推奨しています。データベースの主キーである UUID の乱れにより、データの場所が頻繁に変更され、パフォーマンスに重大な影響を及ぼします。

2. データベースに基づいてIDを自動増加

ID が必要な場合は、テーブルにレコードを挿入して主キー ID を返します。しかし、この方法には致命的な欠点があります。アクセス数が急増すると、MySQL 自体がシステムのボトルネックになります。分散サービスを実装するためにこれを使用することはリスクがあり、推奨されません。

アドバンテージ：

シンプルな実装、単調に増加するID、数値型の高速クエリ速度

欠点:

DBの単一ポイントではダウンタイムのリスクがあり、高同時実行シナリオを処理できません。

3. データベースクラスタモードに基づく

前述のように、シングルポイントデータベース方式は推奨されないため、上記の方式に高可用性の最適化をいくつか加え、マスタースレーブモードのクラスターに変更しましょう。マスターノードに障害が発生して使用できなくなることが心配な場合は、デュアルマスターモードのクラスターを作成できます。つまり、2 つの MySQL インスタンスが独立して自動増分 ID を生成できます。すると別の問題が起こります。 2 つの MySQL インスタンスの自動増分 ID はどちらも 1 から始まります。重複した ID が生成された場合はどうすればよいですか?

解決策: 開始値と増分ステップサイズを設定する

MySQL_1 の設定:

 @@auto_increment_offset を 1 に設定します。 -- 開始値 
 @@auto_increment_increment = 2 を設定します。 -- 歩幅

MySQL_2 の設定:

 @@auto_increment_offset を 2 に設定します。 -- 開始値 
 @@auto_increment_increment = 2 を設定します。 -- 歩幅

2 つの MySQL インスタンスの自動インクリメント ID は次のとおりです。

 1、3、5、7、9
 2、4、6、8、10

クラスターのパフォーマンスが依然として高い同時実行性に耐えられない場合はどうなるでしょうか? MySQL を拡張してノードを追加する必要がありますが、これはかなり面倒な作業です。

3 番目の MySQL インスタンスを追加するには、最初の MySQL インスタンスと 2 番目の MySQL インスタンスの開始値とステップサイズを手動で変更し、3 番目のマシンの開始 ID 生成位置を既存の最大自動増分 ID の位置から離れた位置に設定する必要があります。ただし、これは、最初の MySQL インスタンスと 2 番目の MySQL インスタンスの ID が 3 番目の MySQL インスタンスの開始 ID 値に達する前に実行する必要があります。そうしないと、自動増分 ID が重複し、必要に応じて変更するためにマシンをシャットダウンする必要がある場合があります。

アドバンテージ：

DB単一点問題を解決する

欠点:

これはその後の容量拡張には役立ちません。実際、単一のデータベース自体は依然として大きな負荷がかかっており、高同時実行シナリオに対応できません。

4. データベースベースの数値セグメントモード

番号セグメントモードは、現在の分散 ID ジェネレータの主流の実装方法の 1 つです。番号セグメントモードは、データベースから自動増分 ID をバッチで取得することとして理解できます。数値セグメントの範囲がデータベースから取り出されるたびに、たとえば [1,1000] は 1000 個の ID を表します。特定のビジネスサービスは、この数値セグメントを使用して 1 から 1000 までの自動増分 ID を生成し、メモリにロードします。

複数の業務端末が同時に稼働する可能性があるため、バージョン番号は楽観的ロックを使用して更新されます。この分散 ID 生成方法は、データベースに強く依存せず、データベースに頻繁にアクセスせず、データベースにかかる負荷が大幅に軽減されます。

5. Redisベースモード

ID のアトミックな自己増分を実現するには、redis incr コマンドを使用します。

 127.0.0.1:6379> set seq_id 1 // 自動増分IDを1に初期化する
わかりました
127.0.0.1:6379> incr seq_id // 1ずつ増加し、増加した値を返す
(整数) 2

Redis を使用する際に注意すべき点の 1 つは、Redis の永続性の問題を考慮する必要があることです。 RedisにはRDBとAOFの2つの永続モードがあります。

RDB は永続性を保つために定期的にスナップショットを取得します。番号が継続的に増加しても、Redis がそれを時間内に保持せず、Redis がハングアップした場合、Redis を再起動すると ID が繰り返されます。
AOF は各書き込みコマンドを永続化するため、Redis がクラッシュしても ID が重複することはありません。ただし、incr コマンドの特殊性により、Redis を再起動してデータを回復するには時間がかかりすぎます。

6. スノーフレークベースのモデル

Snowflake は、Twitter の内部分散プロジェクトで使用される ID 生成アルゴリズムです。

Snowflake は Long 型の ID を生成します。 Long 型は 8 バイトを占め、各バイトは 8 ビットを占めるため、Long 型は 64 ビットを占めることになります。 Snowflake ID 構造は、正の数字 (1 ビット) + タイムスタンプ (41 ビット) + マシン ID (5 ビット) + データセンター (5 ビット) + 自動増分値 (12 ビット) の合計 64 ビットの Long 型で構成されます。

最初のビット (1 ビット): Java の long の最上位ビットは符号ビットであり、正または負を表します。正の数は 0、負の数は 1 です。通常、生成される ID は正の数なので、デフォルト値は 0 です。
タイムスタンプ部分（41ビット）：ミリ秒レベルの時間。現在のタイムスタンプを保存することはお勧めしません。代わりに、(現在のタイムスタンプ - 固定開始タイムスタンプ) の差を使用して、生成される ID が小さい値から開始されるようにします。 41 ビットのタイムスタンプは 69 年間使用できます、(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69 年。
作業マシン ID (10 ビット): workId とも呼ばれ、コンピュータールームまたはマシン番号の組み合わせで柔軟に構成できます。
シリアル番号部分（12ビット）、自己増分サポート同じノードで同じミリ秒内に4096個のIDを生成可能

このアルゴリズムのロジックによれば、このアルゴリズムを Java 言語で実装し、ツールメソッドにカプセル化するだけで済みます。その後、各ビジネスアプリケーションはこのツールメソッドを直接使用して分散 ID を取得できます。分散 ID を取得するために別のアプリケーションを構築することなく、各ビジネスアプリケーションが独自の作業マシン ID を持つことを確認するだけで済みます。

現在、スノーフレークアルゴリズムには時間ロールバックの問題があり、異なるマシンで時間が完全に同じであることを保証できないため、重複の問題が発生する可能性があります。