私たちは、顧客データの現在のバージョンを示す単調に増加するキーを保持するユースケースを持っています。これは、システムで使用され、最新のバージョンを把握し、データの読み取りと処理の間に遅延があり、複数のバージョンを取得した場合、サードパーティの発信者の競合を解決します。自己管理単調増加キーまたはORシステムのタイムスタンプ
CUSTOMER_RESOURCE_ID CURRENT_VERSION
132323 1234
何かがこのリソースのために変更された場合、我々は(我々がいる限り、それがダウンしていないとして1300年にそれを増やしても、全く問題あり)1234年から1235年にバージョンをインクリメントします。そのためには、まず値を読み込んで更新する必要があります。
その他の方法として、DBのタイムスタンプを使用して、常に増加するDBタイムスタンプでバージョンを更新することができます。これは単なるシステムなので、DBを変更するときにクロックスキューが発生する可能性があります。また、一度に1つのスレッドのみがリソースを更新する別のロックがあるので、複数のスレッドがある時間内にデータを更新する場合(つまり、タイムスタンプの粒度が最小である場合)には心配していません。
データベースのシステムタイムスタンプを使用して、ちょうど更新で選択と増分を避けることができるのだろうかと思っていました。
この方法に問題はありますか?データベースのオーバーヘッドが少なくなると思っていますが、ここでどれくらい節約できるか分かりません。
あなたは一例で説明できますか? –
システムクロックの細かさによっては、おそらく複数のスレッド間の一意性を保証できません。 –
ありがとうございます、アップデートをご覧ください。 – instanceOfObject