特定の XML RPC に対して行う要求ごとに、一意の増分の数値トランザクション ID を生成する必要があります。これらの番号はドメイン全体で一意である必要があるだけですが、複数のマシンで生成されます。
データベースでこの数を追跡し、すべてのトランザクションで行ロックなどを処理する必要はありません。マイクロ秒のタイムスタンプを使用してこれをハックしようとしましたが、衝突があったのはほんの数スレッドでした。私のアプリケーションは数百のスレッドをサポートする必要があります。
どんなアイデアでも大歓迎です。
編集: 各トランザクション ID が前のリクエストよりも大きくなければならない場合はどうなりますか?
これを数百のスレッドから使用し、複数のマシンで作業し、増分 ID が必要な場合は、最後に生成された ID 番号を保存してロックするための集中化された場所が必要になります。これは必ずしもデータベースにある必要はありませんが、それが最も一般的なオプションです。ID を提供するだけの中央サーバーでも同じ機能を提供できますが、これはおそらくこれを配布する目的に反します。
それらが増分である必要がある場合、どの形式のタイムスタンプも一意であるとは保証されません。
それらを増分する必要がない場合は、GUID が機能します。各システムでタイムスタンプ + ハードウェア ID の何らかのタイプのマージを実行すると、一意の識別子が得られる可能性がありますが、ID 番号の部分は必ずしも一意であるとは限りません。
ハードウェア ID と増分タイムスタンプのペアを使用できますか? これにより、特定の各マシンの ID が増分されますが、ドメイン全体で必ずしも一意になるとは限りません。
- - 編集 - - -
2 つの理由から、どの形式のタイムスタンプを使用してもうまくいかないと思います。
まず、使用するタイマーの解像度に関係なく、異なるマシン上の 2 つのスレッドがまったく同時にスケジュールを試行しないことを保証することはできません。十分に高い解像度では、可能性は低いですが、保証はされません。
第二に、これを機能させるには、上記の衝突の問題を解決できたとしても、すべてのシステムにマイクロ秒の精度でまったく同じクロックを持たせる必要があり、これは実際には実用的ではありません。
これは、パフォーマンスのボトルネックを作りたくない場合は特に、非常に難しい問題です。ID は「インクリメンタル」かつ「数値」である必要があるとおっしゃっていますが、それは具体的なビジネス上の制約ですか、それとも他の目的のために存在するものですか?
これらが必要ない場合は、ほとんどの一般的なプラットフォームにライブラリがある UUID を使用できます。それらを使用すると、非常に短い期間で多数 (数百万!) の ID を生成でき、衝突がなく快適に使用できます。ウィキペディアの関連記事は次のように主張しています。
言い換えれば、次の 100 年間、毎秒 10 億の UUID を生成した後で初めて、複製が 1 つだけ作成される確率は約 50% になります。
各クライアントが独自の「次の ID」を追跡できる場合は、セントラル サーバーと通信して、一度に 1000 程度の範囲の ID を取得できます。クライアントが ID を使い果たすと、サーバーと再度通信する必要があります。
これにより、システムはIDの中央ソースを持ち、すべてのIDについてデータベースと通信する必要がなくなります.
Windows プラットフォームをターゲットにしている場合、Interlocked APIを試しましたか?
探している言語のGUIDジェネレーターをGoogleで検索し、数値にする必要がある場合はそれを数値に変換します。ただし、増分ではありません。
または、各スレッドに 1,000 (または 100 万、または 10 億) のトランザクション ID を「予約」して、一度に 1 つずつ配布し、それがなくなったら次の束を「予約」します。まだ本当に漸進的ではありません。
要件から「増分」を削除すると、 GUIDを使用できます。
ある種の共通データがなければ、複数のプロセスにわたってインクリメンタルを実装する方法がわかりません。