Skip to main content
Version: 0.7.4

最小競合リソース (Minimal Competing Resources)

最小競合リソースは、Claptrap フレームワークを使用する際に重要な概念です。この概念を理解することは、開発者が Claptrap の State をよりよく設計し、間違った設計を回避するのに役立ちます。

最小競合リソースとは#

マルチスレッドプログラミングにおける「リソース競合」の概念を例え、ここでは、ビジネスシステムにおける「最小競合リソース」の概念を提案する。この概念を使用すると、Newbe.Claptrap の設計ポイントを適用する方法を簡単に見つけることができます。

たとえば、電子メール のスナップの例では、各商品は "最小競合リソース" です。ここでは、すべての商品が「最小競合リソース」であることを示しているわけではありません。なぜなら、1万の商品に番号を付ければ、商品1と2をスナップし、それ自体が競争関係を持つからである。したがって、各商品は最小の競争リソースです。

ここで利用可能ないくつかの例があります:

  • シングル エンド ログオンのみを許可するビジネス システムでは、1 人のユーザーのログイン チケットが最小競合リソースです
  • 1 つの構成システムでは、各構成項目は最小競合リソースです
  • 株式取引市場では、すべての買い注文または売り注文は最小の競争リソースです

最小競合リソースは、最小同時実行ユニット (Minimal Concurrent Unit) とも呼ばれるシナリオがあります。

Claptrap の State は、少なくとも "最小競合リソース" の範囲以上である必要があります#

すべての商品が同じClaptrapのステート(最小競合リソースよりも大きい)で設計されている場合、エレクトラススナップの例を組み合わせます。Claptrap が基づいているアクタ モードは要求を処理するためにキューに入れられるため、異なるユーザーが商品を購入すると相互に影響します。つまり、各商品が 10 ms を処理する必要があると仮定すると、すべての購入要求を処理するには、最速で 10000 * 10 ms が必要です。ただし、各商品に番号が付けされている場合、各商品は個別の Claptrap の State として設計されています。そして、彼らは互いに関連していないので。すべての商品を販売するには、理論的にはわずか10msです。

したがって、Claptrap の State が最小競合リソースの範囲より大きい場合、システムは正確性に問題はありませんが、パフォーマンスが低下する可能性があります。 さらに、Claptrap の State が最小競合リソースの範囲よりも小さい場合、Claptrap 間の関係は扱いにくくなり、リスクが伴います。これは、通常、1 つのトランザクションで一緒に処理する必要がある最小競合リソースを複数の部分に分割するのと同等であるため、分散で非常に一般的な分散トランザクションの問題に戻り、対処が困難になります。