別のリモート API への呼び出しをラップし、課金可能な WCF Web サービスを作成しています。
私はこれをクライアントの使いやすさのために同期サービスにしたいと考えています。また、99% の確率でリモート API が迅速に応答するため、クライアントに認識可能な遅延はありません。
また、サービスを有料化したいと考えています。クライアントは自分のアカウントにお金を入金することができ、成功した場合は各サービス コールが請求されます。
当然のことながら、各リクエストが届いたときに、電話をかけるのに十分な金額がアカウントにあることを確認する必要があります。
私の計画と現在のプロトタイプは次のことを行います。
- ストア プロシージャを呼び出してクライアントの残高を確認し、十分な場合は、この要求に必要な金額を差し引きます。この SProc にはトランザクションが含まれており、ROWLOCK と HOLDLOCK を使用して、クライアントの残高が一度に 1 つずつ読み取り/更新されるようにします。
- 正常に充電できた場合は、必要な操作/リモート API 呼び出しを実行します。
- 操作/リモート API が失敗した場合、金額をクライアントの残高に返金します (再びトランザクション、ロックされた更新 SProc)。
- すべて問題がなければ、DB で呼び出しを完了としてマークします
このようにすることで、クライアントに同時リクエストを許可することができ、唯一のボトルネック (だと思います!) は残高チェック中です。
私の考えでは、呼び出し全体を ac# トランザクションでラップすると、クライアントは一度に 1 つの呼び出ししかできないということになります。
このメカニズムの問題を予測できる人、またはより良い設計方法を提案できる人はいますか?
私が見ることができる 1 つの問題は、最初の部分が完了し、クライアントに請求されたが、操作/リモート API 呼び出し中に壊滅的な何かが発生し、払い戻しが行われない場合、不完全な呼び出しに対して料金が発生することです。コールに対して完了または払い戻し済みのマーカーがなく、「オフライン」で処理する必要があるため、これらを検出できます。