# Mollom 體系結構-每秒以 100 個請求殺死超過 3.73 億個垃圾郵件 > 原文： [http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html](http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html)  [Mollom](http://mollom.com/) 是每個開發人員在絞盡腦汁尋找可行的軟件即服務創業公司時都夢 of 以求的出色的 SaaS 公司之一。 Mollom 與一小部分地理位置分散的開發人員一起以有益的方式運行有用的服務-[垃圾郵件過濾](http://www.youtube.com/watch?v=anwy2MPT5RE)。 Mollom 幫助保護了近 40,000 個網站免受垃圾郵件的侵擾，其中包括[屬于我的](http://biztaxtalk.com/)，這是我第一次了解 Mollom 的地方。 為了在 Drupal 網站上停止垃圾郵件的拼命嘗試，在該網站上，所有其他形式的 CAPTCHA 都失敗了，我在大約 10 分鐘內安裝了 Mollom，它立即開始工作。 那是我一直在尋找的開箱即用的體驗。 從 Mollom 開放其數字檢查系統開始，他們已經拒絕了超過 3.73 億封垃圾郵件，在此過程中，他們了解到，驚人的 90％的郵件都是垃圾郵件。 該垃圾郵件洪流僅由兩臺地理位置分散的計算機處理，這些計算機每秒處理 100 個請求，每個計算機都運行 Java 應用程序服務器和 Cassandra。 因為它們創建了一個非常高效的機器學習系統，所以幾乎不需要任何資源。 那不是很酷嗎？ 那么，他們怎么做呢？ 為了找出答案，我采訪了 Mollom 的聯合創始人 Benjamin Schrauwen，以及 Glassfish 和 Java 企業專家 Johan Vos。 證明軟件沒有國界，Mollom HQ 位于比利時的[H??TG0] （來自比利時的其他好東西： [Hercule Poirot](http://en.wikipedia.org/wiki/Hercule_Poirot) ，[巧克力](http://www.google.com/images?q=belgian+chocolate)，[華夫餅](http://www.google.com/images?q=belgium+waffles) ）。 ## 統計 * 服務于 40,000 個活躍的網站，其中許多是非常大的客戶，例如 Sony Music，Warner Brothers，Fox News 和 The Economist。 很多大品牌，有大網站，還有很多評論。 * 每天查找 1/2 百萬封垃圾郵件。 * 每秒處理 100 個 API 調用。 * 垃圾郵件檢查的延遲很短，大約需要 30-50 毫秒。 最慢的連接將是 500 毫秒。 延遲的第 95 個百分位數是 250 毫秒。 它確實針對速度進行了優化。 * 垃圾郵件分類效率為 99.95％。 這意味著 Mollom 不會捕獲 10,000 個垃圾郵件中的 5 個。 * [Netlog](http://mollom.com/blog/netlog-using-mollom) 是歐洲的一個社交網站，在其自己的數據中心中擁有自己的 Mollom 設置。 Netlog 每天根據自定義[分類器](http://en.wikipedia.org/wiki/Learning_classifier_system)處理大約 400 萬條消息，這些分類器對其數據進行了訓練。 ## 平臺 * 兩個生產服務器在兩個不同的數據中心中運行以進行故障轉移。 * 一臺服務器在東海岸，一臺在西海岸。 * 每個服務器是一個 Intel Xeon Quad 核心，2.8 GHz，16 GB RAM，4 個 300 GB 磁盤，RAID 10。 * [SoftLayer](http://www.softlayer.com/ ) -機器由 SoftLayer 托管。 * [Cassandra](http://cassandra.apache.org/) -選擇 NoSQL 數據庫是因為它具有出色的寫入性能和跨多個數據中心進行操作的能力。 * [Glassfish](http://en.wikipedia.org/wiki/GlassFish) -用于 Java EE 平臺的開源應用程序服務器。 他們選擇了 Glassfish，因為它具有企業級功能，例如復制和故障轉移。 * [Hudson](http://hudson-ci.org/) -可在所有服務器上進行后端的連續測試和部署。 * Java-Mollom 從一開始就是用 Java 編寫的。 * [Munin](http://munin-monitoring.org/) -用于測量和繪制有關服務器運行狀況的指標。 * [MySQL](http://www.mysql.com/) -JPA（Java Persistence API）用于常規數據集，而 Cassandra 用于大型數據集。 * [Pingdom](http://www.pingdom.com/) -用于正常運行時間監視。 * [Zendesk](http://www.zendesk.com/) -用于支持。 * [Drupal](http://drupal.org/) -用于具有自定義電子商務模塊的主網站。 * [解除混淆](http://unfuddle.com/)-Subversion 托管由其分布式開發團隊用于源代碼控制。 ## 什么是 Mollom？ Mollom 是一項 Web 服務，用于從用戶生成的內容中過濾掉各種類型的垃圾郵件：評論，論壇帖子，博客帖子，民意調查，聯系表，注冊表和密碼請求表。 垃圾郵件的確定不僅取決于發布的內容，還取決于張貼者的過去活動和聲譽。 Mollom 的[機器學習](http://en.wikipedia.org/wiki/Machine_learning)算法充當您的 24x7 數字主持人，因此您不必這樣做。 ### 如何使用？ 例如，諸如 Drupal 之類的應用程序使用一個模塊將 Mollom 集成，該模塊將自身安裝到內容編輯集成點中，以便在將內容寫入數據庫之前可以檢查其內容是否為垃圾內容。 該過程看起來像： * 當用戶向網站提交評論時，將對后端服務器進行 API 調用。 * 會對內容進行分析，如果是垃圾內容，則將告知網站阻止該內容，或者如果后端不確定，它將建議該網站顯示 [CAPTCHA](http://en.wikipedia.org/wiki/CAPTCHA) ，它們也可以提供該內容。 * 正確填寫驗證碼后，內容將被接受。 在大多數情況下，人們不會看到驗證碼，該內容將直接被視為*火腿*，火腿是好內容，*垃圾郵件*是壞內容。 * 僅在機器學習算法不是 100％確定的情況下才顯示 CAPTCHA，因此在大多數情況下不會給人類帶來不便。 ### 儀表板 Mollom 的每個帳戶都包含一個漂亮的[漂亮的信息中心](http://mollom.com/scorecard)，它向您顯示了已接受多少火腿和已拒絕多少垃圾郵件。 在圖中看到的垃圾郵件數量確實令人沮喪。 ### 運作流程 **安裝。** 對于 Drupal 來說，安裝非常容易。 像安裝其他模塊一樣安裝它。 在 Mollom 網站上創建一個帳戶。 獲取一對安全密鑰，將這些密鑰配置到模塊中，然后選擇要使用 Mollum 保護的系統部分。 就是這樣 **每日**。 我定期檢查垃圾郵件是否已經通過。 它不是 100％，因此某些垃圾郵件確實可以通過，但很少。 如果垃圾郵件確實通過了，則有一種方法可以告訴 Mollom 該帖子確實是垃圾郵件，應將其刪除。 無論如何，這都是您必須要做的，但是在此過程中，您正在幫助培訓 Mollom 的機器學習算法，了解什么是垃圾郵件。 **允許匿名用戶交互**。 有了出色的垃圾郵件檢查程序，就有可能建立一個網站，人們可以進行匿名交互，這是許多使用某些類型網站的人真正喜歡的。 一旦您要求注冊，參與活動就會減少，并且注冊也不會阻止垃圾郵件發送者。 ### 并非一切都是玫瑰色 處理誤報是 Mollom 的最大缺點。 垃圾郵件檢測是拒絕火腿和接受垃圾郵件之間的困難平衡行為。 Mollom 的機器學習算法似乎運行得很好，但是有時存在一個問題，即好的帖子被拒絕，您會感到恐懼：*您的提交觸發了垃圾郵件過濾器，將不被接受*。 目前沒有追索權。 對于用戶而言，幾乎沒有什么比讓他們的光榮評論被垃圾郵件拒絕更令用戶生氣的了。 用戶只會嘗試幾次來解決問題，然后他們只會放棄并走開。 問題是無法解決此問題。 為了保護機器學習算法不被玩耍，Mollom 不允許您提供一個示例，該示例錯誤地拒絕了應接受的內容塊，盡管他們正在努力在將來添加它。 這是一個艱難的決定。 靜態 CAPTCHA 系統，即僅要求用戶通過測試即可提交內容的系統，一旦將站點定為嚴重攻擊目標就無法正常工作。 用戶注冊無效。 考慮到一個站點每天可能有成千上萬的垃圾郵件，對每個帖子進行審核需要非常高的負擔，尤其是對于“愛好”站點。 垃圾郵件完全殺死了一個站點，因此，要平衡激怒某些用戶的風險，而不要因為一個被炸毀的站點而最終沒有用戶。 ## 商業模式 * 讓 Mollom 輕松自如的是，它是免費的。 您只需在網站開始每天接受 100 多個火腿消息后付款。 對于小型站點，這可能永遠不會發生。 * 一旦超過免費門檻，便有 Mollom Plus（每天 1 歐元）和 Mollom Premium（3600 歐元/年/站點）的定價層，這似乎很合理。 * 免費的網站并不會像您期望的那樣浪費資源，它們實際上是重要培訓數據的來源。 所有使用 Mollom 的網站都在不斷將數據反饋給后端分類器。 使用 Mollom 的人越多，通過從用戶那里獲得的所有反饋進行培訓的效果就越好。 沒有免費的網站，Mollom 就不會像現在那樣準確。 ## 建筑 * Mollom 非常受工程驅動。 主要重點在于使 Mollom 在代碼和服務器資源使用上都盡可能高效。 * 實際上，每個服務器都可以處理所有請求，但是它們具有完整的故障轉移。 工作在機器之間分配。 如果其中一個發生故障，則工作移至另一臺機器。 * 他們曾經有 3 臺服務器，但是由于它們提高了性能，因此可以將第三臺服務器用作登臺服務器。 * 每個服務器每秒可以處理完整的 100 個連接，并且每個連接運行整個管道：全文分析，計算作者的信譽并提供 CAPTCHAS。 * 真正針對低延遲進行了優化。 由于垃圾郵件檢測是內容提交到站點過程的一部分，因此，如果花很長時間，對用戶來說真的很煩。 * 軟體動物經歷了幾個發展階段： 1. 最初，一個由兩個人組成的小團隊在做兼職，負責算法，分類器和他們試圖解決的實際業務問題。 為了在后端建立基礎架構，他們使用了自己的線程池，連接池，資源管理實現。 他們發現他們花了太多時間來支持所有這些東西并使其擴展。 然后他們切換到 Java 應用程序服務器 Glassfish，因此他們不必擔心內存管理，REST 處理，XML 解析和數據庫連接池。 2. 過去的主要問題是磁盤帶寬。 他們需要跟蹤 Internet 上所有 IP 地址和所有 URL 的信譽，因此這是一個龐大的數據存儲，具有許多隨機訪問權限。 3. 早期，他們使用廉價的虛擬機，而一切都在 MySQL 中進行，但無法擴展。 4. 然后，他們將其移至固態磁盤并將所有內容存儲在文件中。 固態解決了寫問題，但是有一些問題： 1. 真的很貴。 2. 這對安裝的文件系統類型非常敏感。 3. 寫入速度很快，但是遍歷數據以清理數據或在數百萬個小對象上訓練新的分類器仍然非常緩慢。 5. 然后他們離開了固態，搬到了卡桑德拉。 * Cassandra 現在用作寫繁重負載的數據庫和緩存層： * 在 [RAID 10](http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/) 磁盤配置（條帶化和鏡像）上運行，這對于大量讀/寫非常有用。 * 卡桑德拉（Cassandra）針對寫入進行了優化，而 Mollom 的寫入量要大于讀取量。 * 設計為分布在數據中心內部和整個數據中心。 * 缺點是沒有標準的 NoSQL 接口，這使得編寫應用程序變得困難。 * Cassandra 的行緩存使他們不必在系統中添加另一個緩存層，從而消除了大量應用程序代碼。 * Cassandra 具有老化功能，該功能會在一段時間后自動刪除數據。 歐洲有嚴格的隱私法，要求一段時間后刪除某些數據。 此功能是一個巨大的勝利。 這是一個非常昂貴的操作，Cassandra 處理它會刪除很多應用程序代碼。 * 博客評論通過系統的路徑： * 請求可以來自任何客戶端。 客戶端跨服務器負載平衡請求。 這部分將在后面說明。 典型的客戶端是 Drupal 系統。 請求可以是 XML-RPC 或 REST。 * 請求由 Glassfish 應用程序服務器處理并遵循典型的應用程序服務器工作流程：請求由 servlet 處理并委托給會話 bean。 * 付費客戶首先得到服務，免費客戶可能會遇到更長的延遲。 * 對該請求進行解析和分析。 稍后再詳細介紹。 確定垃圾郵件分數并將其返回給用戶。 因此，Mollom 有不同的功能部分：垃圾郵件檢查和 CAPTCHA 處理。 CAPTCHA 包括生成，提供和處理響應。 不同的會話 bean 負責 Mollom 功能的各個部分。 * 分類器完全位于 RAM 中。 一小部分內容被炸裂成數千個可以識別垃圾郵件的小令牌。 這些分類器在 RAM 中具有幾百萬個令牌。 分類器需要真正快速運行，因此它們必須位于 RAM 中。 * 卡桑德拉（Cassandra）中保存的是信譽分數，頻率，URL 和 IP 地址。 Cassandra 的新行緩存功能現在充當其緩存層。 以前，他們實現了內部緩存，但是已將其刪除。 * 兩個數據中心中的兩臺機器都運行 Cassandra 和 Glassfish 應用程序服務器。 Cassandra 不斷在數據中心之間復制數據。 * 內存中的數據結構不會直接復制。 他們寫信給 Cassandra，然后復制。 另一端的緩存超時，因此它將轉到 Cassandra 并獲取新數據。 最終是一致的。 不一致的窗口很小，但是模型在這么短的時間內不會受到負面影響。 * 一致性是根據具體情況進行管理的。 對于信譽和 IP 地址，最終的一致性很好。 會話數據（包括 CAPTCHA 會話）保持嚴格一致，因此當計算機進行故障轉移時，它們將正確跟蹤。 * 客戶端負載平衡 * Mollom 使用[客戶端負載平衡](http://mollom.com/api/client-side-load-balancing)，該負載平衡基于延遲等進行分配。作為一家初創公司，他們沒有錢購買大型負載平衡器。 他們的另一個目標是能夠對多個數據中心進行全局負載平衡，這將需要昂貴且復雜的設置。 * 客戶端列表的管理通過 API 進行。 每個客戶端都有其可以使用的可用服務器的列表。 * 每個客戶端可以獲取要使用的服務器的不同列表。 可以向付費客戶提供更近的服務器列表，以減少延遲。 * 當服務器發生故障時，客戶端將嘗試列表中的下一個服務器。 * 客戶端負載平衡有助于從舊系統遷移到新的基于 Glassfish 的系統。 將為新用戶提供已遷移計算機的地址，而舊用戶仍在舊計算機上工作，并且可以通過更新其服務器列表以有序方式進行遷移。 這允許進行測試，以便他們可以測試功能，然后測試伸縮性和性能。 他們查看了響應時間，連接隊列中有多少個連接以及隊列中將保留多長時間。 他們可以測試如果增加線程池中的線程，更改 JDBC 連接數以及其他配置會發生什么情況。 所有人遷移后，舊服務器將關閉。 過渡期間幾乎沒有停機時間，這對于高可用性系統至關重要。 當系統關閉時，垃圾郵件正在通過。 * 客戶端方法的缺點是，如果第三方客戶端的文字寫得不好，就會出現問題。 例如，客戶端可以獲取服務器列表，并以相反的順序對其進行迭代，這是錯誤的。 他們現在與客戶開發人員緊密合作，并提供高質量的參考代碼示例，以便開發人員可以學習最佳實踐。 * 機器學習 * Mollom 是一組學習系統。 一個既不考慮用戶行為也不考慮起點的 CAPTCHA 解決方案，永遠無法達到這種水平的知情保護，并且通常要求用戶在每個帖子上都解決 CAPTCHA 問題。 使用 Mollom 的文本分析，僅當 Mollom 不確定帖子時，用戶才必須解決驗證碼。 * 平均消息長度約為 500 個字符，這被分解為 3,000 個功能。 通過查看 IP 地址或 Open ID 的信譽來確定帖子的混亂狀態，可以查看用戶 ID，情感，語言，褻瀆，特定單詞和單詞組合，還可以查看文字的寫法。 等等。所有這些都是基于分類器的。 一些分類器本質上是統計的，可以自動學習。 一些基于規則的分類器可確保它們永遠不會出錯。 最終，所有這些測試將決定垃圾郵件得分。 * 他們從該過程中學習，并實時更新分類器和內部指標。 * Glassfish 可處理工作計劃，并旨在處理多核工作負載。 * 關鍵是創建一個盡可能平行的作品設計，并具有盡可能小的鎖定窗口。 * 調整并發 HTTP 連接的數量，以便它們具有適當大小的可用連接池。 * 每個服務器使用 16 個線程。 * 大多數調用由無狀態會話 Bean 處理，該會話狀態可很好地進行并發管理。 * 他們在池中保留了多個會話 bean，但讓 Glassfish 決定池中應包含多少個會話 bean。 在峰值負載下，池中將有更多會話 Bean，因此可以有效地處理請求。 任何給定時刻都可以并行運行 32 個會話 Bean。 * 所有的分類器實際上都是會話 Bean，它們被不同的線程重用。 * 每個會話 bean 都有自己的與 Cassandra 的客戶端連接，因此它們不會互相阻塞。 * 當用戶不響應 CAPTCHA 時，該會話將被清除，Mollom 得知這可能是垃圾郵件。 * 每個服務器的每個分類器都有一個實例。 * 會話清理的鎖爭用時間很短，其中正在更新分類器。 * 每 1/2 小時將更新的分類器寫回到 Cassandra。 * 應用整合 * Mollom 使用開放式 API，可以將其集成到任何系統中。 * 庫：Java，PHP，Ruby 等。 * 集成解決方案：Drupal，Joomla，Wordpress 和其他內容管理系統。 * 第三方根據 Mollom 產生的示例代碼生成新的綁定。 * 為了監視服務器的運行狀況，他們使用 Munin 進行了持續監視： * 垃圾回收后堆的大小是多少？ * 可用連接數是多少？ * 線程池中可用的線程數是多少？ 確保沒有一個線程長時間等待鎖。 * 當您查看他們的體系結構時，Mollom 試圖構建一種可以透明地在多個數據中心內工作的體系結構，當它們已經超出單個服務器系統的規模時，它們本身可以向上擴展： * 客戶端負載平衡用于選擇和故障轉移服務器。 * Glassfish 群集將用于在應用程序層進行故障轉移，并使添加和刪除計算機變得容易。 * Cassandra 將用于跨數據中心管理數據層。 * Netlog 的 Mollom 安裝具有一些有趣的特征。 它比 Mollom.com 主要服務器處理的更多，但是垃圾郵件的分布完全不同，因為他們的人員進行通信是社交網絡的一部分。 Netlog 上的垃圾郵件分布為 90％的火腿和 10％的垃圾郵件，而在殘酷的博客世界中，這恰恰相反。 有趣的含義是，處理火腿所需的資源較少，因此它們實際上可以在同一服務器上執行更多工作。 * 他們最初嘗試使用虛擬服務器，并考慮使用 Amazon，但是他們發現 IO 是使用共享虛擬服務器的主要瓶頸。 IO 延遲和帶寬是真正的問題，因此他們決定擴大規模并使用更大的計算機和更大的磁盤。 * 令人驚訝的是，它們不受 CPU 限制。 8 個內核中只有兩個在計算。 其他人只是在做 IO。 * Mollom 的流量相當穩定，因此擁有專用服務器更具成本效益。 他們看到亞馬遜更多地是一種處理高峰負載的方式。 * 開發過程 * 他們是分散的團隊。 三個人在比利時，一個在德克薩斯州，波士頓和德國。 * Scrum 被用作開發過程，他們對此非常滿意。 Scrum 會議在下午 2 點通過 Skype 進行。 他們發現隨著他們的成長，他們需要更多的過程。 * 開發人員在本地進行開發，并將代碼提交到 Unfuddle 中。 * Hudson 被用作他們的持續集成環境。 Hudson 使他們從舊系統到新 Glassfish 系統的遷移更加容易，因為必須在部署之前通過測試。 他們并沒有浪費太多時間，因為在生產部署之前就發現了問題。 * 他們有很多測試：單元測試，系統測試，Drupal 測試。 只有當 Hudson 通過了這些測試時，才能部署系統。 * 仍然可以手動進行部署，以減少潛在的停機時間。 * 每當他們發現垃圾回收時間出現問題時，這總是歸因于其應用程序中的內存泄漏。 萬一發生內存泄漏，他們將進行核心轉儲。 要從 16GB 的計算機分析核心轉儲不是那么容易，您可能無法在本地計算機上對其進行分析，因此他們要做的是在 Amazon 上租用一個大內存實例來分析轉儲。 處理堆轉儲大約需要 2 個小時。 他們比較了兩個轉儲，一個在執行時間 10 小時后，另一個在執行時間 20 小時后。 如果存在重大差異，則可能是由于內存泄漏。 ## **未來方向** * Mollom API 使用 XML-RPC，他們現在正在測試 REST 實現，以使服務更易于使用 Mollom 進行混搭。 * 現在，他們已經過渡到 Cassandra，在增長需要時，他們可以更輕松地進行橫向擴展。 * 即將發布的企業功能可以將數百個網站作為一個單元進行管理。 通過情緒，垃圾郵件分數或從某些 IP 地址刪除所有評論，很容易在一組網站上進行審核。 * 他們已經進行了有關進入 Twitter 等流數據業務的討論，但受到歐洲更加嚴格的隱私政策的限制。 * 他們將使用 Glassfish 進行實驗，以平衡每個數據中心的負載。 * 如果負載增加 10 倍，則必須添加更多的 Cassandra 節點。 磁盤 IO 是瓶頸。 僅當它們的增長速度必須超過 10 倍時，才需要添加更多的應用程序服務器。 ## 經驗教訓 [ * ****效率帶來幸福。** Mollom 非常重視高性能工程。 他們為 Mollom 極具成本效益而感到自豪。 它可以在一臺服務器上處理許多請求，而延遲時間很短，這使客戶感到滿意，這使他們感到滿意，因為他們不必維護大量機器，而且成本很低。 他們從一開始就將其作為優先事項，并選擇了正確的技術來實現其目標。 這樣一來，他們就可以利用自己賺的錢，在營銷，建立用戶群以及在 Mollom 之上開發新產品方面進行投資。** * **廣度免費，付出深度**。 機器學習需要大量示例數據才能成功檢測到垃圾郵件。 為了獲得這些數據，Mollom 為客戶提供了免費的服務，他們提供了更好地訓練學習算法所需的廣泛數據，他們是不斷提供情報和反饋的來源。 較大的客戶不僅提供收入，而且還可以從免費客戶那里學到的數據受益。 該模型似乎是大數據和機器學習所特有的，眾所周知，這是一切的未來。 * **移除非特定領域的障礙物**。 大型系統需要大量基礎架構工作。 基礎架構的工作通常使工作不再涉及與產品的真正價值產生領域相關的功能（分類器，信譽系統，客戶端庫）。 Mollom 有意識地嘗試通過選擇 Cassandra 和 Glassfish 來盡可能地擺脫基礎設施業務。 * **注意客戶端代碼**。 客戶端代碼很有吸引力，因為它使用別人的資源而不是您的資源。 問題在于代碼編寫得不好，這會使您的系統看起來很糟糕。 與客戶開發人員緊密合作，并提供高質量的參考代碼示例，以便開發人員可以學習最佳實踐。 * **優先考慮付費客戶**。 付費客戶可以獲得更好的服務質量。 它們首先在隊列中處理，并且減少了整個系統的延遲。 付費客戶可以訪問故障轉移服務器，而免費客戶只能使用一臺服務器。 * **通過讓堆棧進行繁重的操作**來減少代碼。 在早期，Mollom 代碼庫比現在大得多。 Cassandra 通過處理復制和行緩存刪除了許多復雜的代碼，Glassfish 刪除了許多應用程序代碼，并將處理集群。 隨著時間的推移而簡化。 * **最小化鎖爭用**。 Mollom 花了很多時間來減少 Glassfish 服務器中的鎖爭用，因為這已成為主要瓶頸。 盡可能少地鎖定即可保持完全的并行性。 ## 相關文章 * [Mollom API](http://mollom.com/api) * [Mollom Drupal 模塊](http://drupal.org/project/mollom) * [Mollom 技術白皮書](http://mollom.com/files/mollom-technical-whitepaper.pdf) * [Mollom 的 Twitter 帳戶](http://twitter.com/#!/mollom) * [第 072 集-Mollom.com 的 GlassFish 后端，帶有 Dries 和 Johan](http://blogs.sun.com/glassfishpodcast/entry/episode_072_mollom_com_s) * [Mollom 獲得了一個新的后端](http://buytaert.net/mollom-gets-a-new-backend) * [在 Glassfish 上用 Mollom 打擊垃圾郵件](http://blogs.lodgon.com/johan/) * 要了解有關大數據和機器學習的更多信息，請查看 [Strata Conference](http://strataconf.com/strata2011/public/schedule/proceedings) 中的一些資料。 好帖子！ 我想念什么嗎？ 100 rps 令人印象深刻嗎？ 托德 首先，我是該網站的忠實擁護者，我會定期關注您的帖子。 我喜歡這篇文章，但是每秒的請求引起了我的注意。 我很好奇您認為“高吞吐量”服務。 我問是因為我是 Proxomo 的首席軟件架構師（http://www.proxomo.com）。 我們的負載測試已在兩臺服務器（在 Microsoft Azure 上運行）上以每秒超過 500 個請求的速度為 REST 服務提供時鐘。 謝謝 Daniel ..... 丹尼爾，您好，如果您想談談您的架構，請給我發電子郵件。 關于您的問題，我認為沒有任何特定的閾值定義“高吞吐量服務”。 Mollom 給我留下了深刻的印象，因為它們有一個復雜的機器學習應用程序，可以在一臺（大型）機器上運行，它們遵循嚴格的質量和性能指標，它們是可盈利的，并且它們以正確的方式做事。 有很多人在創建應用程序，不是每個人都是 Google，所以我真的很喜歡這些提供真正價值的更人性化服務的示例。 垃圾郵件取決于上下文。 如果我經營一個科技網站，那么政治評論就是垃圾郵件。 如果我經營一個政治網站，那么技術評論就是垃圾郵件。 如果使用“從用戶那里獲得的所有反饋”對 Mollom 進行培訓，如何避免出現問題？ 如何將其整合到 Drupal 中？？？