分散状況で一意のデータベース ID を生成するソリューション

ビジネスの一意の識別子としての

ID は、データ設計でよく使用されます。例:

•Product - product_id

•Order - order_id

•Message - message_id

これらの識別子は、多くの場合、主キーは、データ アドレスを直接指すクラスター化インデックスを作成することです。クラスター化インデックスを指す通常のインデックスと比較して、インデックス クエリが 1 つ削減され、非常に高速になります。メッセージや注文などのビジネスでは、通常、逆時系列でデータをクエリする必要があります。その 1 つの方法は、ID 自体の挿入順序に依存することです。したがって、分散 ID は次の 2 つの主要な条件を満たす必要があります:

• グローバルに一意である

• 時間傾向が規則的である

MySQL の auto_increment を直接使用することはできないのではないかと言う人もいるかもしれません。ビジネスを始めた初期の頃は、私もこのソリューションを選択するでしょう。これはシンプルで効率的で高速です。スタートアップは依然として迅速に反復し、できるだけ早く製品を作成する必要があり、製品は頻繁に変更されるため、時間がかかりすぎます。開発時間は役に立たないかもしれません。はい、貴重な時間が無駄になりました。ただし、この解決策にはいくつかの問題があります:

• 並列挿入への影響 - レコード B はレコード A の主キーに依存します。レコード B を挿入する前に、レコード A が正常に挿入され、A.id を取得するまで待機する必要があります。

• データの回復は困難 - — データが誤って削除または消失した後、ログに ID がないため、データの相関関係を直接判断できません

• データベースとテーブルのシャーディングへの影響 — ID が不明なため挿入されるまで、ビジネスの主キーに基づいてデータベースとテーブルのシャーディングを実行することはできません

したがって、ビジネスが安定した後は、時間をかけて早期の技術的負債を返済する必要があります。

一般的なソリューション

データベースの auto_increment を使用して一意の ID を生成します

利点

•シンプルで既存の機能を使用し、開発労力が少ない

•固定 ID ステップサイズ

欠点

•単一の記述ポイント、高くはありません 利用可能

• 複数のメインライブラリが異なる auto_increment 開始点に従って展開された場合でも、可用性は向上しますが、ID の厳密な順序は保証されません

• データベースには毎回アクセスする必要があり、簡単にアクセスできますパフォーマンスの上限

ID をバッチで取得し、1 つずつ割り当てます

このソリューションでは、ID データもデータベースに保存されます。ID サービスは毎回データベースから N 個の ID を取得し、現在の最大 ID 値を元のデータに更新します。 N. ID サービスは、リクエストを生成するたびに ID を受け取ります。これらの N 個の ID が順番に返されます。

メリット

•バッチ取得、毎回データベースにアクセスする必要がなく、データベースの負荷が低い

デメリット

•サービス全体が単一ポイントであることに変わりはありません

•サービスのダウンタイムと再起動によりIDの不連続が発生します

•できない水平方向に拡張できます

改善点

一連のバックアップ サービスを追加します。メイン サービスに障害が発生し、バックアップ サービスに移行する場合は、vip + keepalived を使用するか、プロキシを追加できます。

uuid

利点

•ローカルに生成されたID、単一点の問題、パフォーマンスのボトルネックがない

欠点

•増分順序を保証できない

•長さが長すぎる、主キーとしてのパフォーマンスが低い

スノーフレークのようなアルゴリズム

Snowflake は、Twitter のオープンソース分散 ID 生成アルゴリズムです。その中心的なアイデアは、ミリ秒数として 41 ビット、マシン番号として 10 ビット、ミリ秒内のシーケンス番号として 12 ビットを使用する長い ID です。このアルゴリズムは理論的には 1 台のマシンで 1 秒あたり最大 1000*(2^12)、つまり 400W の ID を生成でき、ビジネス ニーズを完全に満たすことができます。

snowflake のアイデアを学び、各企業のビジネス ロジックと同時実行性を組み合わせて、独自の分散 ID 生成アルゴリズムを実装できます。

利点

•時間は高いレベルにあり、増加傾向にあります

•実装が簡単、他のサービスに依存せず、拡張が簡単です

欠点

•グローバルクロックはなく、単一のマシンが絶対的な順序ですが、クラスター全体の観点から見ると、傾向は Sequential です

注意事項

•ID はサブデータベースとサブテーブルの識別子としてよく使用されるため、これらの ID にはある程度のサブデータベース以降のデータが不均一にならないように、シーケンス番号は 1 から始まり、0 ～ 9 のいずれかから始まります

。