リソースロックおよびビジネスロジック

Question

次の状況を考慮してください。 サブエンティティA.Bを作成するためにエンティティAに更新要求があります。 Aに多くのBがあるかもしれません、それぞれのBは一意のEメールアドレスを持っています。 エンティティAは共有エンティティであり、同じ要求が複数のサーバで並列に実行されます（スケーラブルマイクロサービス）。

A.Bを作成するには、BがAのサブエンティティとして存在していないことを確認する必要があります（Bのメールアドレスに従って）。

この更新要求を処理するサービスは、更新を安全にするためにA（一意のID）をロックする必要があります。

私の質問は、技術よりも概念的なものである：この更新タスクのビジネス・ロジックの一部は

1. は、この場合には、リソースAをロックしていますか？

2. ベリファイとアップデートの手順を処理するものとは別のミドルウェアにリソースロックを入れることを検討しますか？ （他のオプションは、ビジネス・ロジックの一部としてロックを治療し、ビジネスロジックを担当するミドルウェアで直接それを置くことです。）あなたのビジネスが構築されていない限り

Answer 1

ロックは（ビジネス関連の問題ではありません分散データベース）、ビジネスロジックの一部と見なすべきではありません。

さらに、分散ロックを実装する必要はありませんが、パッケージ化されたソリューション（データ永続化ソリューションの一部であることが望ましい）に依存する必要があります。

how to do this with Redisの記事でRedlockというアルゴリズムについて説明しています。 building concensus in Cassandraに関する記事にリンクしているブログ記事です。そして、ここにconcurrency in Mongoのリンクがあります。これらの記事から分かるように、分散ロックは大きく複雑な問題で、おそらく自分自身に取り組んではいけません。

Answer 2

競合問題に対する選択されたソリューションの技術的な実装は、明らかにビジネスロジックではありませんが、適切なソリューションを選択するにはビジネス知識が必要です。

これは、並行処理のシナリオでデータの整合性を保護するための正しいアプローチを決定するために、ビジネスの仕組みを理解する必要があるということです。並行性の競合が発生する頻度はどれくらいですか？競合は自動的に解決できますか？矛盾するものは何ですか？それだけでなく、ビジネスは強い一貫性の上で最終的な一貫性を非常によく受け入れるかもしれません。つまり、同時性シナリオでデータの整合性を保護するためのメカニズムは、ドメインの一部であってはなりません。これらはおそらくアプリケーションサービスレイヤーまたはインフラストラクチャレイヤーのいずれかに入りますが、並行処理の競合をどのように解決し、ビジネスにどのように影響するかについて、ビジネスエキスパートが議論に参加する必要があります。