2012-02-17 44 views
2

我試圖將當前的應用程序更改爲縮放。快速寫入永久隊列

目前它每小時最多可處理幾百萬個事件,但當我切換到SaaS模型時,卷的容量預計會增加10到100倍,所以能夠以分佈式方式執行處理非常重要時尚。

該應用程序是一個Web應用程序,目前每小時接收120萬個事件。它使用2個Tomcat服務器,每個服務器監聽500個線程和一個工作管理器排隊事件,然後產生幾百個工作線程來後處理事件。

我想要做的是將寫入與處理分離並將處理移至分佈式環境。

  1. 快速寫入到磁盤的事件。

    這裏的解決方案可以像寫入LinkedBlockingQueue一樣簡單,並將成百上千個條目的批次轉儲到文件中,或者使用已經完成此操作的好的庫或調整數據庫以支持這種類型的合理排隊時尚。

    如果系統變得不可用,則無法捕獲上次事件並不重要,重點在於服務器工作時的性能。

  2. 將事件處理移至分佈式系統。

    我需要將數據移動到分佈式系統(例如HDFS)。還有什麼其他選擇?處理具有中等複雜度(例如,一些複雜性在自連接中生成頻繁項目集並進一步濾除該集合,其他部分涉及跨越多個層次結構聚合數據)。我目前使用數據庫(MySql & DB2)並考慮Hadoop。任何其他選項?

  3. 將結果存儲在只讀快速讀取系統中。

  4. 我目前使用SOLR,沒有更好的選擇

我知道這個問題產生了多個主題,任何輸入讚賞。讓我知道是否有更好的標籤可以使用。

謝謝!

Sebi

回答

1

最好的系統,既能夠插入和查詢 - 的確是RDBMS。但它不可擴展。 NoSQL系統不可擴展,因爲它們構建得更好,但是因爲他們放棄了一些東西。讓我們看看它們可以構建什麼。
HBase和Cassandra都是專門爲將隨機事件插入轉換爲順序磁盤IO而構建的。換句話說 - 它們是編寫優化的系統,您可以將它們視爲完美的分佈式數據庫索引。因此,通過添加更多節點,您可以獲得所需的任何插入速率。

關於連接和聚合是存在問題的一點。
如果您能夠成功設計您的密鑰,以便將數據進行彙總,則可以高效地提取和彙總數據。
連接也有問題,但有一個選項可以寫入已經預先加入的數據。您應該在應用程序級別執行此操作。
對於更復雜的處理,您需要使用MapReduce,但它可能會影響插入速率。
DataStax的Brisk聽起來很適合您的情況,因爲它具有Cassandra與MapReduce預集成的功能,可以在Cassandra Data上運行MapReduce。它還能夠減少故事中OLTP部分的MapReduce影響。

0

一些問題聽起來像他們有JMS作爲解決方案。這是一個隊列,它應該是快速的,它是可靠的(跨機器故障),並且它是持久的。

例如,可以將ActiveMQ配置爲強制客戶端等待數據提交到多臺計算機上的光盤,方法是將其設置爲「經紀人網絡」。請參閱http://activemq.apache.org/networks-of-brokers.html

它還允許您將郵件標記爲永久性的,以便經紀人可以在重新啓動後繼續工作。我強烈建議使用ActiveMQ的http://activemq.apache.org/kahadb.html建議,因爲舊版本存在嚴重問題。

這有助於分配事件,但對處理沒有任何幫助,也沒有實際數據的最終存儲。有多少客戶需要訪問多少數據,以及數據生成多久?您可以使用JMS中的「主題」將消息分發給所有客戶端,還可以使用「上次映像主題」等概念在代理上存儲某些狀態,以便您的客戶端可以重新啓動。 http://activemq.apache.org/subscription-recovery-policy.html解釋了這些。

儘管如此,聽起來好像你最終會用Hadoop來處理信息,所以不妨使用內置到它們堆棧中的任何東西。 :)

0

您可以使用內存映射文件作爲持久隊列。

此庫支持持續的事件驅動消息,以每秒數百萬次(而不是每小時)的速度在進程之間產生亞微秒級的延遲。它也非常簡單(等級太低大多數情況的使用,但你可以使用它作爲一個起點)今天

https://github.com/peter-lawrey/Java-Chronicle

+0

嗨,彼得,謝謝你的建議。這看起來很有趣。 我可以看到,使用它可以暫時保留來自所有Web服務器線程的請求,並且在另一端有N個進程以批處理方式(每秒左右)將數據快速移動到分佈式環境中的N臺機器,以處理加載。 隊列能夠在崩潰後恢復嗎? – sfeher 2012-02-20 14:56:14

+0

如果您的程序崩潰,則保留所有更改。如果最後一個條目不完整,它不會出現在索引中。爲了最大限度地提高性能,它不保證寫入磁盤,所以如果系統崩潰(例如內核崩潰),您可能會丟失很多未提交的更改(在重負載下) – 2012-02-20 22:18:47

+0

您可以使批處理大小動態變化。即讀取等待請求(達到某個限制)處理它們,重複。當負載相對較低時,這將導致小批量響應批次,並且在重負載時批量越來越大。 – 2012-02-20 22:21:47