多線程與文件系統觀察家和/或MSMQ WCF服務

Question

我需要創建一個服務，這是基本職責如下：

1. 手錶創建任何新文件的特定文件夾。
2. 如果是，讀取該文件，處理它並將數據保存在數據庫中。

對於上述任務，我想用下面的方法創建一個多線程的服務：

1. 在主線程，創建文件系統觀察家的一個實例，只要一新文件已創建，請在threadQueue中添加該文件。會有N號。的消費者線程運行，它應該從隊列中取出一個文件並對其進行處理（即步驟2）。

2. 再次在主線程中創建文件系統監視器的實例，一旦創建新文件，就讀取該文件並使用wcf MSMQ服務將數據添加到MSMQ。當通過WCF MSMQ服務讀取消息時，這將是負責處理進一步

我是一個新手，當談到創建一個多線程的服務。所以不知道哪個是最好的選擇。請指導我。

感謝，

Answer 1

首先，請允許我說，你已經採取了明智的做法做一個生產者 - 消費者多模型。這是這種情況下最好的方法。

我會選擇1，使用ConcurrentQueue數據結構，它爲您提供了一種以線程安全方式排列任務的簡單方法。或者，您可以簡單地使用ThreadPool.QueueUserWorkItem方法將工作直接發送到內置線程池，而無需擔心明確管理工作人員或隊列。

編輯：關於FileSystemWatcher可靠性，MSDN說：

Windows操作系統會通知你的文件的組成部分由FileSystemWatcher的創造了一個緩衝改變 。如果短時間內有很多變化，緩衝區可能會溢出。這會導致 組件丟失跟蹤目錄中的更改，並且只會提供 提供一攬子通知。使用 來增加緩衝區的大小InternalBufferSize屬性是昂貴的，因爲它來自 非分頁內存不能換出到磁盤，所以請保持 緩衝區儘可能小但足夠大以便不會錯過任何文件更改事件。 爲避免緩衝區溢出，請使用NotifyFilter和IncludeSubdirectories屬性，以便過濾掉不需要的更改 通知。

所以它取決於變化發生的頻率和分配的緩衝區數量。

Answer 2

我還會考慮您對故障處理的要求以及您發送的文件的大小。 您是否決定選項1或2將取決於規格。

選項2具有優勢通過使用MSMQ，即使您需要重新啓動計算機，您也可以以可恢復的方式保存數據。選項1僅將您的數據存儲在內存中，可能會丟失。

在另一方面，選項2具有缺點與Unicode字符工作時MSMQ的消息大小限制爲4 MB每消息（在Microsoft博客here解釋），因此只有它的一半，而內存隊列容量更大。

[編輯]

思考的時間長一點，我寧願選擇。 在你的評論中，你提到你想要在文件系統中移動文件。這可能是非常昂貴的性能方面，如果您在不同的部分之間移動文件更糟。

我已經在工作中的多個項目中使用了MSQM，並且相信它對於您想要做的事情可以很好地工作。這裏最大的優點是MSMQ可以處理交易通信。這意味着，如果出於某種原因網絡或電力或任何故障發生，您的信息和文件都不會丟失。

如果在移動文件時出現這些情況，則很容易被損壞。

我唯一在肚子裏咕thing的是文件大小。要解決4 MB的郵件大小限制（請參閱上面的添加鏈接），我不會將文件內容放入郵件中。代替。我只會發送一個ID或一個文件路徑，以便消費服務可以找到它並在需要時讀取它。

這可以使消息和隊列大小保持較小，並避免在網絡和服務器中使用太多帶寬或內存。