生産者と消費者のメカニズムがあり、生産されたアイテムをデータベースに保存する必要があります。これは要件です。また、いくつかのプロデューサーといくつかのコンシューマーがあり、プロデューサーとコンシューマーのスレッドはいくつかのデータベース テーブルのレコードにアクセスします。ProcessID 列は、どのスレッドがどのレコードにアクセスしているかを判断します。
スレッドは、Windows サービスを介して機能します。
ProcessID が作成される理由は 3 つあります。
1- スレッドが異常終了した場合、処理の再開を避けるために processID が使用されます。
2- スレッドはデータベースのロックによって同期されます。行ロックのみが取得されることを願っています。すべてのスレッドが ProcessID でマークされたいくつかのレコードにアクセスするため、ブロックされたスレッドが短時間だけ発生する可能性があります。
3-エラーをデータベースに記録しているため、どのスレッドがいつ何をしたかを追跡したかった。コンシューマーはアイテムを Web サービスに送信することに注意してください。
インメモリ配列をキューとして使用した場合、パフォーマンスが向上するとは思えません。次の欠点があります。
コンシューマーがアイテムをデキューするときは、データベース内のレコードをプロセス ID で更新する必要があります。
プロデューサーはアイテムをデータベースに挿入し、Output stp パラメータを使用してその ID を取得します。次に、アイテムをその ID とともにキューに入れ、データベースからの再読み取りを回避します。これがインメモリ キューの唯一の利点であり、回避します。データベースからアイテムを再読み込みします。レコードが DB に挿入されると、コンシューマー以外は何も更新されないことに注意してください。
もう1つの問題は、オペレーターが特定のアイテムをデータベースから削除することで消費を停止できると想定していることです。メモリキューで使用すると、この未来が失われます。
Queue クラスはプライベート オブジェクトをロックする必要があります。キュー メソッドへのアクセスは同期する必要があります。スレッドが枯渇する可能性を複製しているように感じます。スレッドがブロックされて待機する時間を複製しているように感じます。
2 つの質問
1- このデザインに欠けているものはありますか? うまくいくと思いますか？
2- インメモリ キューを使用しないのは良い考えですか?