# Mailinator 架構 > 原文： [http://highscalability.com/blog/2008/1/24/mailinator-architecture.html](http://highscalability.com/blog/2008/1/24/mailinator-architecture.html) **更新：**在[中進行應用搜索的有趣探索，如何每秒搜索 185 封電子郵件中的單詞“ pen1s”](http://mailinator.blogspot.com/2008/01/how-to-search-for-word-pen1s-in-185.html) 。 如果 indexOf 沒有減少，您會更加努力。 曾經有一個醉酒的朋友啟發您創建了首個受到數百萬人喜愛，被數千人顛覆的互聯網服務，同時每年通過[欺騙](http://www.flickr.com/photos/arcticstylings/814612466)處理超過 12 億封電子郵件 ]舊服務器？ 這就是 Paul Tyma 來建立 Mailinator 的方式。 Mailinator 是一項免費的無設置 Web 服務，用于通過創建一次性注冊電子郵件地址來阻止惡意垃圾郵件發送者。 如果您不給網站提供真實的電子郵件地址，那么他們就不會向您發送垃圾郵件。 他們反而對 Mailinator 發出垃圾郵件：-) 我喜歡從角度出發進行設計，而 Mailinator 有一個巨大的挑戰：性能第一，第二和最后。 為什么？ 因為 Mailinator 是免費的，所以 Paul 可以展示他對設計的不同看法。 競爭對手購買大型 Iron 來處理負荷時，Paul 卻提出了一個大主意：選擇正確的問題并設計一個適合該問題的設計。 不再。 不少 結果是一個完美的系統架構十四行詩，在形式的約束之內美。 Mailinator 作為垃圾郵件破壞超級英雄如何開展工作？ 網站：http：//mailinator.com/ ## 信息來源 * [Mailinator 的體系結構](http://mailinator.blogspot.com/2007/01/architecture-of-mailinator.html)* [Mailinator's 2006 Stats](http://mailinator.blogspot.com/2007/02/mailinators-2006-stats.html) ## 該平臺 * 的 Linux* 雄貓* Java ## 統計資料 * 2007 年將處理大約 12.9 億封電子郵件。2006 年為 450.74 百萬封電子郵件。2005 年為 280.68 百萬封電子郵件。* 峰值速率為每天 650 萬封電子郵件或 4513 個/分鐘或 75 個/秒。* Mailinator 運行在非常適度的計算機上，該計算機具有 AMD 2Ghz Athlon 處理器，1GB RAM（使用的內存更少）和低性能的 80G IDE 硬盤驅動器。 而且機器根本不是很忙。* 即使在持續的垃圾郵件攻擊和高峰值負載下，Mailinator 也可以無人值守運行數月，并且很少丟失電子郵件。 ## 架構 * 擁有免費系統意味著該系統不一定是完美的。 因此，設計目標是： -設計一個系統，該系統重視生存，甚至是用戶。 生存是關鍵，因為 Mailinator 必須每天抵御攻擊。 -為用戶提供 99.99％的正常運行時間和準確性。 更高的正常運行時間目標將是不切實際且成本高昂的。 而且由于該服務是免費的，因此這對于用戶來說只是游戲規則的一部分。 -支持以下服務模型：用戶注冊某些內容，轉到 Mailinator，單擊訂閱鏈接，然后忘記它。 這意味著電子郵件不必永久存儲在磁盤上。 電子郵件可以駐留在 RAM 中，因為它是臨時的（3-4 小時）。 如果您想要一個真實的郵箱，請使用其他服務。* 電子郵件處理的原始流程是： -Sendmail 在單個磁盤郵箱中接收到電子郵件。 -基于 Java 的 Mailinator 使用 IMAP 和/或 POP（隨時間變化）抓取電子郵件并將其刪除。 -系統隨后將所有電子郵件加載到內存中，然后將其放置在那里。 -達到 20,000 個內存限制后，最早的電子郵件便被推出。* 原始體系結構運行良好： -它穩定并且一次可以使用幾個月。 -它幾乎使用了所有 1GB 的 RAM。 -每天收到的電子郵件速率開始超過 800,000 時出現問題。 由于 Mailinator 和電子郵件子系統之間的磁盤爭用，系統崩潰了。* 新架構： -想法是刪除磁盤上的路徑，這是通過完整的系統重寫來完成的。 -Web 應用程序，電子郵件服務器和所有電子郵件存儲都在一個 JVM 中運行。 -Sendmail 被替換為自定義的 SMTP 服務器。 由于 Mailinator 的性質，因此不需要完整的 SMTP 服務器。 Mailinator 不需要發送電子郵件。 它的主要職責是盡快接受或拒絕電子郵件。 這是分層的缺點。 分層通常是擴展的關鍵策略，但由于關鍵決策最好在堆棧的最高級別進行處理，因此會降低性能。 因此，當許多 RAM 和周期竊取操作已經完成時，工作流將流經系統，僅在較低層進行轉儲。 因此，決定使用定制 SMTP 服務器是一個有趣而勇敢的決定。 此時大多數人只會添加更多硬件。 他們不會錯，但是看到這條路也很有趣。 也許有了更多 [DOM 和 AOP](http://radio.weblogs.com/0103955/categories/stupidHumanProgramming/2007/06/20.html#a244) 這樣的體系結構，我們可以展平堆棧并在需要時獲得更好的性能。 -現在 Mailinator 直接接收電子郵件，進行解析并將其存儲到內存中。 磁盤被完全繞過，并且磁盤仍然相當空閑。 -系統關閉時，電子郵件將寫入磁盤，因此可以在啟動時重新加載它們。 -記錄已關閉，以消除傳票的風險。 執行日志記錄時，日志數據是成批寫入的，因此在一次磁盤寫入中將寫入數千行日志。 這樣可以最大程度地減少磁盤爭用，否則會丟失有用的診斷信息。 -系統使用少于 300 個線程。 不需要更多。 -到達后，每封電子郵件都會通過過濾器系統，如果所有過濾器都通過，則會存儲在 RAM 中。 -每個收件箱僅限于 10 封電子郵件，因此流行的收件箱，例如 [[受電子郵件保護]](/cdn-cgi/l/email-protection) ，無法使系統崩潰。 -傳入的電子郵件不得超過 100k，所有附件都將立即被丟棄。 這樣可以節省 RAM。* 電子郵件在 RAM 中壓縮： -由于從未查看過 99％的電子郵件，因此壓縮電子郵件可以節省 RAM。 當有人看著它們時，它們只有 被解壓縮。 -Mailinator 可以使用不到 300MB 的內存在 RAM 中存儲約 80,000 封電子郵件，而原始設計中的 1GB RAM 中存儲了 20,000 封電子郵件。 -使用此池，平均電子郵件壽命約為 3-4 小時。 -可能有 200,000 封電子郵件可以容納在內存中，但是并沒有真正的需求。 -這是我喜歡的設計細節之一，因為它基于真實的應用程序使用模式。 RAM 很珍貴，而 CPU 卻不是，所以知道大多數情況下您不必將 CPU 命中兩次，使用壓縮來節省 RAM 卻以 CPU 為代價。* Mailinator 不保證匿名和隱私： -沒有隱私。 任何人都可以隨時閱讀任何收件箱。 -放寬這些約束，同時又令人震驚，使設計更加簡單。 -對于用戶而言，這很簡單，因為不需要注冊。 當網站要求您提供電子郵件地址時，您只需輸入一個 mailinator 地址即可。 您無需創建單獨的帳戶。 鍵入電子郵件地址可以有效地創建 mailinator 帳戶。 簡單。 -在實踐中，用戶仍然可以獲得高度的隱私。* 可生存性的目標導致積極的垃圾郵件過濾。 -Mailinator 沒有針對 SPAM 的任何內容，但是由于 SPAM 太多，因此在威脅到系統正常運行時必須將其過濾掉。 -這導致以下規則：如果您做任何事情（無論是否發垃圾郵件）都開始影響系統，則您的電子郵件將被拒絕，您可能會被鎖定。* 要被接受，電子郵件必須通過以下過濾鏈： -退回：所有退回的電子郵件都會被丟棄。 -IP：丟棄了來自單個 IP 的過多電子郵件 -主題：丟棄了有關同一主題的過多電子郵件 -便箋：包含了表示仇恨或犯罪或僅是徹頭徹尾的討厭表情的主題 。* 從單個 IP 地址 中幸存的電子郵件泛濫-AgingHashmap 用于過濾來自特定 IP 地址的垃圾郵件發送者。 當電子郵件到達 IP 地址時，會將 IP 放入地圖中，并為所有后續電子郵件增加計數器。 -在一段時間內沒有電子郵件后，計數器將被清除。 -當發件人達到電子郵件計數閾值時，將阻止該發件人。 這樣可以防止發件人淹沒系統。 -許多系統使用這種邏輯來保護各種資源，例如注釋。 您可以將 memcached 用于分布式系統中的相同目的。* 防范僵尸攻擊： -垃圾郵件可以從稱為 IP 僵尸網絡的不同 IP 地址的大型坐標集中發送。 相同的消息是從數千個不同的 IP 地址發送的，因此用于阻止來自單個 IP 地址的電子郵件的技術還不夠。 -這種過濾比 IP 阻止要復雜一些，因為您必須解析足夠多的 電子郵件才能獲得主題行，而匹配主題字符串則需要更多的資源。 -當 2 分鐘之內有 20 封電子郵件發送同一主題時，所有帶有該主題的電子郵件將被禁止 1 小時。 -有趣的是，并沒有永遠禁止主題，因為這意味著 Mailinator 將不得不永遠跟蹤主題，并且系統設計固有地是瞬態的。 我認為這很聰明。 通過一些“不好的”電子郵件，通過系統變得簡單得多，因為不必管理任何持久性列表，并且該列表肯定會成為瓶頸。 一個具有更嚴格的 SPAM 過濾目標的系統將不得不創建一個更加復雜且不那么健壯的體系結構。 -僅有 9％的電子郵件被此過濾器阻止。 -從我的閱讀中，Mailinator 僅針對 IP 和主題進行過濾，因此不必閱讀電子郵件正文即可接受或拒絕電子郵件。 當大多數電子郵件將被拒絕時，這可以最大程度地減少資源使用。* 為減輕 DOS 攻擊的危險，請執行以下操作： -丟棄在特定時間段內保持沉默的所有連接。 -Mailinator 會非常緩慢地（例如 10 或 20 或 30 秒）將回復發送給電子郵件發件人，即使是非常少量的數據也是如此。 這會減慢試圖盡快發送垃圾郵件的垃圾郵件發送者的速度，并可能使他們重新考慮再次向該地址發送電子郵件。 繁忙時段的等待時間減少了，因此電子郵件不會丟失。 ## 得到教訓 * **完善是陷阱**。 驅動器使 100％的一切變得更加復雜。 如果您去過那些會議，您就會知道他們的樣子。 哦，我們不能這樣或那樣做，因為發生錯誤的可能性為 0.01％。 而是問：你會多么不完美，不夠好？ * **扔掉的東西與**存放的東西一樣重要。 我們對如何設計系統有許多先入之見。 我們理所當然地認為您需要橫向擴展，幾天后需要訪問電子郵件，并且必須為每個人提供 私人帳戶。 但是您真的需要這些東西嗎？ 你能扔什么？ * **了解系統的用途并進行相應設計**。 所有人都擁有一切意味著您對任何人都不是。 將電子郵件保留很短的時間，允許一些 SPAM 通過，并接受少于 100％的正常運行時間，這將為該系統創建一個強大的愿景，從而有助于在各個領域推動設計。 如果您對系統的含義和需求有非常深刻的了解，則只能構建自己的 SMTP 服務器。 我知道這絕不會成為我的主意。 我會增加更多的硬件。 * **對于常見情況，在提交資源**之前快速失敗。 很高比例的電子郵件被拒絕，因此在堆棧中盡早拒絕它是有意義的，以最大程度地減少完成任務的資源。 找出如何盡快使經常發生故障的物品短路。 這很重要，并且經常被忽視。 * **效率通常意味著您自己建立**。 現成的工具往往可以完成全部工作。 如果您只需要完成部分工作，則可以編寫運行速度更快的自定義組件。 * **自適應地忘記**。 有點失敗是可以的。 不需要永遠記住所有被阻止的 IP 地址。 讓塊決策從本地數據而不是全局狀態開始。 這是功能強大且簡單而強大的體系結構。 * **Java 不必太慢**。 說夠了。 * **避開磁盤**。 許多應用程序需要使用磁盤，但是磁盤始終是瓶頸。 您可以使用其他創意策略在磁盤周圍進行設計嗎？ * **限制資源使用量**。 放入約束，例如收件箱大小，這將使您的系統無法控制地突刺。 必須在資源有限的情況下避免無限制的資源使用。 * **壓縮數據**。 嘗試節省 RAM 時，壓縮可能是一大勝利 。 我發現使用壓縮的開銷很少，而內存使用量卻下降了一半以上。 如果您是在本地進行通信，則只需讓客戶端對數據進行編碼并保持編碼狀態即可。 構建 API 無需解碼完整的消息即可訪問數據。 * **使用固定大小的資源池來處理負載**。 許多應用程序無法控制資源的使用，例如內存，如果使用過多，它們就會崩潰。 要創建一個真正強大的系統，請修復您的資源，并在這些資源已滿時放棄工作。 您可以老化資源，給予優先訪問權，給予公平訪問權或使用任何其他邏輯來仲裁資源訪問權，但是由于資源將受到限制，因此您將承受負載。 * **如果不保留數據，則不會傳喚**。 由于 Mailinator 不存儲電子郵件或在磁盤上登錄日志，因此可以進行傳票。 * **使用您所知道的**。 我們已經看過幾次這一課了。 保羅比其他任何人都更了解 Java，因此他使用了 Java，使其得以運行，然后他完成了工作。 * **查找您自己的 Mailinators** 。 當然，Mailinator 是一個小型系統。 在大型系統中，這只是一個小功能，但是您的系統由許多 Mailinator 大小的項目組成。 如果您開發了諸如 Mailinator 之類的 ，該怎么辦？ * **KISS 存在，盡管很少見**。 總是談論保持簡單，但是我們很少顯示真實的例子。 這主要是因為您的方法很復雜，而我的方法卻很簡單，因為這是我的方法。 Mailinator 是簡單設計的一個很好的例子。 * **健壯性是體系結構**的功能。 要創建有效利用內存并能抵御大量垃圾郵件攻擊的設計，需要一種能夠查看整個堆棧的架構方法。 ## 相關文章 * [PlentyOfFish](http://highscalability.com/plentyoffish-architecture) 擁護直截了當的裸露骨頭。* [Varnish](http://highscalability.com/links/goto/117/) 巧妙地使用 OS 功能來找到令人難以置信的性能。* [ThemBid](http://highscalability.com/thembid-architecture) 優雅地將開源組件組合在一起。 很棒的閱讀。 這屬于“我曾想過的想法”的構想。 我不知道他如何獲得資助？ [http://codershangout.com](http://codershangout.com) 編碼人員可以進行視頻群聊的地方！ 有資金嗎？ 自掏腰包。 這是他的愛好。