2

どのアプローチを採用するか、何がベストプラクティスであるかについて、私はかなり混乱しています。次のことを行う C# アプリケーションがあるとします。

キューからメールを送信します。送信するメールとすべてのコンテンツが DB に保存されます。

これで、C# アプリケーションをほぼスケーラブルにする方法はわかりましたが、もう少し先に進む必要があります。

たとえば、Xサーバー間でタスクを分散できるという何らかの形の責任が必要です。そのため、すべての処理を 1 つのサーバーで行うだけでなく、サーバー間で共有します。1 つのサーバーがダウンした場合、負荷は他のサーバー間で共有されます。NLBがこれを行うことは知っていますが、ここでNLBを探しているわけではありません.

確かに、DB テーブルに何らかの列を追加して、そのレコードを処理するためにどのサーバーを割り当てる必要があるかを示すことができます。サーバー上の各アプリケーションには、DB の値と一致する何らかの種類の ID があり、それらは独自のレコードを取得するだけです-しかし、これは安っぽく、悪い習慣であり、非現実的であると私は考えています。

DB テーブルの行ロックも行うことは、デッドロックの可能性やその他の問題が発生する可能性があるため、私が行うことではありません。

また、ここで「極端に」スレッド化を使用することを示しているわけではありませんが、はい、アイテムごとにスレッド化して処理するか、スレッドごとに x 量のスレッドをバッチ処理します。

スケーラブルで可用性の高い C# アプリケーションを作成するには、どのようにアプローチすればよいですか? 目的は、それぞれが同じアプリケーションを備えた X サーバーを持ち、それぞれがレコードを取得して処理できるようにすることですが、サーバー間で共有される処理/アイテムのレベルを持っているため、一方のサーバーまたはサービスが失敗した場合に備えて、もう一方のサーバー別のサーバーが元に戻されるまで、その負荷を引き受けることができます。

私の理解不足や知識不足で申し訳ありませんが、これについてかなり多くのことを考えていて、良い堅牢な解決策を考えようとして睡眠不足でした。

4

1 に答える 1

1

作業をバッチ処理することを考えているので、各アプリは一度に x 個のレコードのみを取得し、取得したレコードをテーブルの bool フィールドで取得したものとしてマークします。SELECT ステートメントを修正して、取得/完了としてマークされていないレコードのみを取得します。この例では、同じレコードを処理するアプリが重複しないようにするために、テーブル ロックは非常に短い期間で問題ありません。

編集:あまりエレガントではありませんが、(上記の bool フィールドの代わりに) 各エントリの日付スタンプとステータスを持つことができます。次に、sproc を実行する定期的なエージェント ジョブを実行して、ステータスが [進行中] であるが、完了に設定されずに時間のしきい値を超えたレコードのステータスをリセットすることができます。後で別のアプリで再処理できるようになります。

これはあなたの好みには十分ではないかもしれませんが、エンタープライズには、洗練されていなくても問題なく動作するアプリがたくさんあることを隠しているに違いありません. 最高のものは、最小限の複雑さで機能します。

于 2012-04-23T20:26:07.357 に答える