我試圖將當前的應用程序更改爲縮放。快速寫入永久隊列
目前它每小時最多可處理幾百萬個事件,但當我切換到SaaS模型時,卷的容量預計會增加10到100倍,所以能夠以分佈式方式執行處理非常重要時尚。
該應用程序是一個Web應用程序,目前每小時接收120萬個事件。它使用2個Tomcat服務器,每個服務器監聽500個線程和一個工作管理器排隊事件,然後產生幾百個工作線程來後處理事件。
我想要做的是將寫入與處理分離並將處理移至分佈式環境。
快速寫入到磁盤的事件。
這裏的解決方案可以像寫入LinkedBlockingQueue一樣簡單,並將成百上千個條目的批次轉儲到文件中,或者使用已經完成此操作的好的庫或調整數據庫以支持這種類型的合理排隊時尚。
如果系統變得不可用,則無法捕獲上次事件並不重要,重點在於服務器工作時的性能。
將事件處理移至分佈式系統。
我需要將數據移動到分佈式系統(例如HDFS)。還有什麼其他選擇?處理具有中等複雜度(例如,一些複雜性在自連接中生成頻繁項目集並進一步濾除該集合,其他部分涉及跨越多個層次結構聚合數據)。我目前使用數據庫(MySql & DB2)並考慮Hadoop。任何其他選項?
將結果存儲在只讀快速讀取系統中。
我目前使用SOLR,沒有更好的選擇
?
我知道這個問題產生了多個主題,任何輸入讚賞。讓我知道是否有更好的標籤可以使用。
謝謝!
Sebi
嗨,彼得,謝謝你的建議。這看起來很有趣。 我可以看到,使用它可以暫時保留來自所有Web服務器線程的請求,並且在另一端有N個進程以批處理方式(每秒左右)將數據快速移動到分佈式環境中的N臺機器,以處理加載。 隊列能夠在崩潰後恢復嗎? – sfeher 2012-02-20 14:56:14
如果您的程序崩潰,則保留所有更改。如果最後一個條目不完整,它不會出現在索引中。爲了最大限度地提高性能,它不保證寫入磁盤,所以如果系統崩潰(例如內核崩潰),您可能會丟失很多未提交的更改(在重負載下) – 2012-02-20 22:18:47
您可以使批處理大小動態變化。即讀取等待請求(達到某個限制)處理它們,重複。當負載相對較低時,這將導致小批量響應批次,並且在重負載時批量越來越大。 – 2012-02-20 22:21:47