私たちは、私たちのプロジェクトでメッセージングを使用して、悲観的な並行性を実装しています。つまり、メッセージングがダウンすると（チャネルがダウンすると）、同時性が低下します。ビジネスアプリケーション - メッセージングを使用するペシミスティック並行性
私は楽観的な並行性と悲観的な並行性を組み合わせると考えています。悲観的同時実行がダウンした場合次に、バックアップオプティミスティック並行...いつものように
THX、リーフェンCardoen
はまだあります、私は答えは、あなたが構築している業務アプリケーションの性質に依存すると思います。アプリケーションのSLAとは何ですか？どのようなミッションクリティカルはそれですか？
メッセージングインフラストラクチャに障害が発生しても、アプリケーションはロックサービスとは別に機能しますか？もしそうなら、おそらく、並行性制御メカニズムが単一障害点でないことを確認する義務があります。
また、真に分散したフォールトトレラントのペシミスティックなロックメカニズムを実現するためのトピックでは、problem of consensusに対処する必要があります。大部分の悲観的なロックアルゴリズムは、ロックの要求に応答することができる（つまり、「ロック」テーブルがあるか、シングルトンロックサーバーがある）、シリアライズされた単一の機関が存在することに依存しています。
このようなデザインには、単一障害点が全面的に記述されています。あなたの最初の質問に答える - はい、ビジネスアプリケーションがメッセージを使って悲観的なロックを提供しているのを見ました。しかし、フォールトトレランスの問題を完全に解決することは、私が遭遇したほとんどのビジネスアプリケーションにとっては過度のもののように思えます。
オプティミスティックな並行性制御では、その性質上、この問題は発生しません。なぜなら、分散フォールトトレラントアプリケーションでは一般的にこの方法が好まれるからです。しかし、ビジネス要件は実装の容易さよりも頻繁に勝っていることを認識しています。
トピックに興味がある場合、Chubby Lock Serviceの記事にはPaxos consensus protocolを利用した記事が掲載されています。