# Notify.me 體系結構-同步性 > 原文： [http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html](http://highscalability.com/blog/2008/10/27/notifyme-architecture-synchronicity-kills.html) 開始一個新項目的好處是，您終于有機會正確地做它。 當然，您最終會以自己的方式弄亂一切，但是在那一瞬間，世界有了一個完美的秩序，一種讓人感到滿足和美好的正義。 全新的實時通知交付服務 notify.me 的 CTO Arne Claassen 現在正處于這個蜜月期。 Arne 足夠親切地與我們分享他如何構建通知服務的理念。 我想您會發現它很有趣，因為 Arne 對其系統如何工作進行了許多有用的詳細介紹。 他的主要設計理念是最小化圍繞同步訪問形成的瓶頸，即，當*請求了一些資源并且請求者占用更多資源，等待響應時。 如果無法及時交付所請求的資源，則會堆積越來越多的請求，直到服務器無法接受任何新請求為止。 沒有人得到他們想要的東西，而您斷電了。 通過將請求和響應分為單獨的消息傳遞操作將同步操作分解為異步操作，可以停止資源過載。 它可以使系統盡可能快地處理積壓的請求，而不會導致系統因并行請求過多而崩潰。 在大多數情況下，請求/響應周期是如此之快，以至于它們看起來像線性的事件序列。* Notify.me 正在采用一種創新且冒險的策略，即使用基于 XMPP 的系統 ejabberd 作為其內部消息傳遞和路由層。 Erlang 和 Mnesia（Erlang 的數據庫）是否能夠跟上通信量并在通信量擴展時保持低延遲？ 找出來將會很有趣。 如果您對 notify.me 感興趣，他們已經為 HS 讀者提供了 500 個 Beta 帳戶： [http://notify.me/user/account/create/highscale](http://notify.me/user/account/create/highscale) ## 你是誰？ 我的名字是 notify.me 的首席技術官 Arne Claassen。 在過去的十年中，我一直在致力于高度可擴展的基于 Web 的應用程序和服務。 這些站點采用了各種傳統擴展技術的組合，例如服務器場，緩存，內容預生成以及使用復制和群集的高可用性數據庫。 所有這些技術都是減輕許多用戶爭用的稀缺資源（通常是數據庫）的方法。 知道了這些技術的好處和陷阱后，我就成為專注于規避稀缺資源場景的架構師系統的焦點。 ## 什么是 notify.me，為什么創建它，為什么它是一件好事？ notify.me 是我們首席執行官 Jason Wieland 的創意。 這是一種近乎實時的通知服務，可提醒用戶注意網絡上發布的新內容。 旨在解決普通用戶難以及時掌握網絡上發生的時間緊迫事件的麻煩。 例如，一旦發布符合其搜索條件的新公寓，就會在 Craigslist 上搜索公寓的用戶收到警報。 notify.me 所做的艱巨工作是反復檢查 Craigslist 是否有新列表，并在發布新列表時提醒用戶。 通知可以傳遞到即時通訊程序，桌面應用程序，移動設備，電子郵件和 Web 應用程序。 我們的目標是創建和發布開放的 API，使人們能夠構建新的有趣的應用程序以生成和傳遞信息。 ## 您的服務與人們可能熟悉的其他服務相比如何？ 像 Twitter，Friend Feed，Gnip 或 Yahoo Pipes？ 有很多公司處于我們的競爭格局中，其中有些是直接競爭對手，例如 yotify.com 或 Alerts.com。 主要區別在于我們的方法。 Yotify 和警報的重點是作為通知門戶網站供用戶訪問。 notify.me 是一個實用程序，重點是通過 XMPP 和 REST API 提供網站上所有可用的功能，允許用戶與來自其選擇應用程序的通知進行交互。 我們還允許將消息升級到目的地。 例如，如果用戶未登錄其 IM 或狀態為離開，則可以升級通知并將其路由到其移動設備。 在消息傳遞領域，我們幾乎與 Twitter 相反。 Twitter 基于其自己的用戶生成的內容向內發布模型。 有人發了一條推文，并發布給了他們的關注者。 notify.me 正在創建一個面向外部的消息傳遞系統。 用戶添加支持 Web feed 標準的任何網站，或將現有的通知電子郵件重定向給我們。 如果有的話，我們是一條消息傳遞管道，是對 titter 的補充（更多內容請參見下文）。 Friendfeed 在將您所有的社交網絡合并到一個集中區域方面做得很好。 他們的主要重點是構建與搗碎的供稿進行交互的功能和工具。 此供稿非常適合作為 notify.me 的源添加，允許用戶通過即時通訊程序接收所有社交網絡更新。 社交癮君子想要的功能是能夠實時了解墻上是否有新帖子，以便您可以立即做出響應。 雅虎管道將被視為可能的合作伙伴，類似于他們向 Netvibes 和 Newsgator 追加銷售的方式。 他們的重點是提供一個直觀的編程界面，以便能夠操縱提要并創建有用的混搭。 例如，[熱門交易搜索](http://pipes.yahoo.com/pipes/pipe.info?_id=_E8FgV_42xGWa5pfZVUMqA)是一個漂亮的管道，可在一組網站上搜索最佳交易。 由于目標選項有限，用戶可能不想使用 Yahoo 自己的通知選項。 在我們的 Beta 組中，我們看到用戶添加 eBay 鏈接的活動類似。 ebay 有一個競爭性的通知管道來通知 notify.me，但是用戶仍然在我們的服務中添加 ebay 搜索鏈接。 事實證明，他們希望在一個中央位置來管理各種新聞源。 Gnip 是純粹的基礎設施。 我們有類似的技術，但我們要追求完全不同的市場。 我們產品尚未公開的另一個核心功能是，我們的管道是雙向的，即任何數據源也可以是目的地，反之亦然。 這樣做的主要好處是能夠響應消息，例如確認收到的支持通知單。 雙向通信將需要與 notify.me API 集成，源可以通過該 API 來傳遞回復選項。 我們目前正在與 Twitter API 進行深度集成，以通過 IM 在您已收到其他通知的同一通道中為推文提供雙向功能。 ## 您能否解釋 notify.me 的不同部分以及它們如何連接在一起？ 一般而言，我們的系統由三個子系統組成，每個子系統都有許多實現。 1\. **接收**由 rss 和電子郵件接收器組成，它們會不斷檢查用戶的電子郵件地址（ [[受電子郵件保護]](/cdn-cgi/l/email-protection) ）和用戶的供稿中是否有新數據。 新數據變成通知，并傳播到路由。 2\. **路由**負責將用戶的通知發送到正確的交付組件。 路由是系統中與用戶進行交互以進行管理的點，例如更改源和目??的地以及查看歷史記錄。 通知歷史記錄是一個專門的傳遞組件，即使在通過整個管道后，也可以通過網站仔細閱讀所有消息。 3\. **傳遞**當前由歷史記錄（總是獲取消息），Xmpp IM，SMS 和電子郵件以及正在開發的私有 RSS，AIM 和 MSN 組成。 從更高的技術層面來看，此系統的拓撲結構由兩個單獨的消息總線組成： 1\. **存儲轉發隊列**（使用 [simpleMQ](http://sourceforge.net/projects/simpleMQ) ） 2 。 **XMPP** （使用 [ejabberd](http://www.ejabberd.im/) ） **攝取端使用存儲和轉發隊列**來分發攝取工作，并且通常在任何地方進行 數據在用戶的路由規則可見之前進行處理。 這允許擴展靈活性以及在組件故障期間進行進程隔離。 **Xmpp 總線**被稱為 Avatar 總線，之所以這樣命名，是因為每個數據擁有實體均由守護進程表示，該進程是該實體數據的唯一授權。 我們有四種類型的化身，即 Monitor，Agent，Source 和 User 1。 **Monitor** 化身只是負責觀察實例運行狀況并根據需要旋轉和關閉其他計算節點的負責方。 2\. **代理**化身是將網關提供給我們用戶的狀態信息并將消息傳遞給用戶的傳遞網關。 3\. **源**化身是攝取器，例如 RSS。 該化身從存儲和轉發隊列中提取新消息，并將新消息通知其訂戶。 4\. **用戶**化身可保留特定用戶的所有配置和消息傳遞數據。 它負責接收來自攝取頭像的新通知，確定路由并將消息推送到適當的傳遞代理，因為該代理聲明了執行該傳遞的能力。 ## 您面對哪些特殊挑戰，如何克服這些挑戰？ 您考慮了哪些選擇，為什么決定以其他方式進行選擇？ 從一開始，我們的主要目標就是避免瓶頸和阻礙水平擴展的障礙。 最初，我們計劃將整個系統構建為通過隊列的無狀態消息流，沿線的每個守護程序都負責流經它的數據，然后將其合并，復用和路由到下一個點，直到實現交付為止。 這意味著除了備份隊列之外，沒有任何一個部件的故障會影響整個部件。 但是，我們很早就意識到，一旦為用戶指定了一條消息，我們就需要能夠跟蹤消息的位置并能夠根據用戶的配置和狀態動態地重新路由它。 這導致我們通過 REST API 在守護程序之間添加了一些不適當的耦合。 由于我們仍在將處理遷移到組合隊列/異步總線體系結構，因此仍然存在一些這種問題。 當我們意識到沒有狀態的純消息傳遞將無法滿足我們的動態需求時，簡單的解決方案是返回到嘗試過的狀態保持器，即中央關系數據庫。 知道我們的擴展目標后，這會引入一個失敗點，我們遲早將無法緩解這一點。 我們決定以不同的方式來看待我們的狀態，而不是考慮根據功能（即攝取，解析，轉換，路由，交付）基于流過的數據查詢狀態來創建處理單元，而是想到了這些單元 在數據所有權方面，即來源和目的地（用戶）。 一旦走上了軌道，幾乎沒有共享狀態，我們可以更改存儲模式，讓每個數據所有者對自己的數據負責，從而允許持久層的水平擴展以及更高效的緩存。 跨所有者訪問數據的其余需求是分析。 在許多系統中，分析是存在中央數據庫的主要原因，因為事實和維度經常在生產模式中混雜在一起。 就我們的目的而言，此數據與生產無關，因此永遠不會影響活動容量。 用法和狀態更改被視為不可變的事件，它們在發生時排隊進入我們的存儲轉發系統。 我們存儲轉發隊列的性質使我們能夠自動將所有主機中的所有這些事件收集到中央存檔中，然后可以通過 ETL 流程將其處理為事實和維度數據。 這允許對使用情況進行近實時跟蹤，而不會影響面向用戶的系統。 ## 您能否再解釋一下您對 XMPP 的選擇？ 它主要用作 EC2 節點上的聯合 XMPP 服務器之間的消息總線嗎？ 是否將 XMPP 隊列用作來自所有來源的每個用戶的消息的隊列，然后再將其推送給用戶？ 我們有三個不同的 xmpp 群集，它們利用聯合來進行跨階段的操作：用戶，代理和頭像總線。 ### 用戶數 這是一臺常規的 xmpp IM 服務器，我們在該服務器上為每個用戶創建帳戶，向他們提供可從任何具有 Xmpp 功能的客戶端使用的 IM 帳戶。 此帳戶還用作我們的桌面應用程序登錄時的用戶，這將成為我們用于第三方消息提取和分發的 API 的身份驗證 ### 代理商 連接到該群集的守護程序充當我們的內部 Avatar 總線與外部客戶端之間的通信橋。 目前，這主要是用于與聊天客戶端進行通信，因為每個用戶都被分配了一個他們無需我們即可通過其進行通信的代理，無論他們使用其默認帳戶還是使用諸如 jabber.org，googletalk 等的第三方帳戶。 通過專用代理的這些代理測試使用 Xmpp RPC 的客戶端 API。 將來，我們還將為第三方集成提供完整的 XMPP 和 REST API，這些 API 將使用代理與 Avatar 總線進行通信。 我之前提到過，代理程序也是化身，但是它們有點特殊，因為它們在 Avatar 總線上沒有用戶，而是通過跨服務器聯合與其他化身進行對話。 我們目前還在為 Oscar 和 MSN 網絡建立代理，由于它們的本機傳輸不是聯邦的，因此它們將直接位于頭像總線上。 我們還計劃評估其他網絡，以獲得將來的支持。 ### 頭像 頭像是我們的內部消息總線，用于路由和處理所有命令和消息。 盡管我們確實利用在線狀態進行監視，但我們主要在頭像之間使用直接消息傳遞和基于 IQ 的 RPC 節。 那么什么是化身？ 它是一個守護程序（單個物理守護程序進程可以托管許多化身守護程序），是某些外部實體數據的權限。 即 在 notify.me 中注冊的每個用戶都有一個化身，用于監視代理的狀態變化，接收照顧該用戶的消息并負責將這些消息路由到適當的傳遞渠道。 這意味著每個頭像都是關于該用戶的所有數據的唯一授權者，并負責持久化數據。 如果系統的其他部分想要了解有關該用戶的信息或修改其數據，它將使用 Xmpp RPC 與虛擬形象進行對話，而不是與某些中央數據庫進行對話。 目前，化身持續存在于磁盤和 SimpleDB 中，同時保持 ttl 管制的高速緩存正在進行中。 由于僅化身可以寫入自己的數據，因此無需檢查數據庫，而是可以將其內存和磁盤緩存視為權威，而 SDB 主要用于寫入。 僅在節點發生故障時才需要讀取以在另一節點上啟動化身。 在巴士的另一端，有我們的攝入裝置。 攝取器由許多守護程序組成，通常在針對外部源的輪詢循環上運行，將新數據排隊到我們的存儲轉發隊列中，適當的攝取器頭像會拾取新消息并將其分發給其訂閱者。 在攝取器頭像方案中，它是訂閱和路由數據的權限。 這是一個典型的用例：用戶通過 Web 界面訂閱 RSS feed。 Web 界面將請求發送到用戶的頭像，該頭像將保留訂閱以供參考，然后從 rss 接收器請求訂閱。 隨著新的 rss 項目到達，rss 攝入器會將項目多路復用到訂閱該供稿的所有用戶頭像。 用戶化身依次確定適當的投放機制并安排投放時間。 一般而言，這意味著用戶頭像通過``用戶代理''訂閱了用戶的 Xmpp 狀態。 在用戶處于接受消息的適當狀態之前，用戶化身排隊 rss 項目。 一旦用戶準備好接收通知，就將狀態更改從代理傳播到內部總線，然后用戶化身將 rss 項目發送給代理，代理再將其發送給用戶。 目前，所有頭像均始終在線（即使大部分都是空閑的），這對于我們當前的用戶群來說還不錯。 我們的計劃是修改 ejabberd 的脫機存儲模塊，以便我們可以盲目發射節并使隊列中的消息向監視器發出信號以啟動用于目標 XmppId 的適當化身。 一旦建立了該系統，我們將能夠按需啟動化身，并在閑置時將其關閉。 ## 您希望在什么流量負載下破壞當前的體系結構，您的計劃是什么？ 由于我們的系統是分布式的，并且是設計異步的，因此應避免在負載下發生系統范圍的故障。 但是，盡管避免了所有常見的瓶頸，但事實是我們的消息總線使這一切成為可能，這可能成為我們的限制因素，要么是因為它無法處理化身的數量（總線上的節點），要么是因為延遲 巴士變得無法接受。 我們只是開始使用頭像系統作為我們的骨干網，所以它仍然有點脆弱，我們仍在對 ejabberd 進行負載測試以確定在什么時候遇到限制因素。 雖然我們已經在集群 ejabberd，但 mnesia 數據庫復制和跨節點震顫的負載意味著連接數或延遲都將最終導致集群失敗或僅消耗太多內存來進行管理。 由于我們的消息傳遞主要是點對點的，因此我們希望可以將用戶群劃分為頭像孤島，每個孤島都托管在專用的頭像子域群集中，從而減少了消息和連接負載。 只要我們的筒倉經過適當設計，以將跨子域的中斷保持在最低水平，我們就應該能夠擁有 n 個筒倉來保持負載最大。 要避免這種體系結構失敗，我們面臨的最大挑戰就是永遠保持警惕，防止引入會造成消息傳遞瓶頸的功能。 我們通過單個處理器或處理器系列的大量消息流量會引入依賴關系，我們無法通過子域劃分來擴展自己。 ## 相關文章 * [notify.me 技術博客-INotification](http://techblog.notify.me/)* [Flickr-預先進行必要的工作并將其余的工作排入隊列](http://highscalability.com/strategy-flickr-do-essential-work-front-and-queue-rest) 好東西！ 很高興看到 erlang（和 ejabberd）越來越受歡迎！ 盡早優化，對吧？ 所有的擴展工作，盡管瘋狂有趣，并且在智力上令人興奮，但直到成功真正需要時，它們才如此。 您可能還說這是浪費。 :) 我不認為早期優化在這里是錯誤的。 由于執行此操作的大多數工具幾乎都是“開箱即用”的，因此通常只需要簡單（但可能會很耗時）的管道即可。 這個設置似乎沒有什么真正復雜的。 我想知道在以下情況下 notify.me 采取了哪些措施來克服這種即時性： 假設那里有 10,000 名程序員從 CraigList 訂閱了“高級程序員”。 一旦一家公司在 CraigList 上發布了“高級程序員”的招聘廣告，所有這 10,000 名程序員都會收到 IM，SMS 或電子郵件的通知。 （希望我到目前為止是對的），notify.me 如何保證通知將同時（幾乎）發送給訂閱者？ 如果第一個程序員收到通知的時間與最后一個程序員收到通知的時間之間的時間間隔大于 10 分鐘，則這是毫無意義的通知。 希望我說得足夠清楚。 關于早期優化：由于我們沒有處理已建立的溝通渠道（就像大多數網絡媒體資源一樣），因此我們無法明確定義提升的方式。 看看我們從第一種方法中學到的知識，很明顯地，我們需要一些可以擴展的基線管道，因為一旦需要，就可能會重新構造我們路由消息的方式 。 您好，我叫 Jason Wieland，我是 notify.me 的首席執行官，我只想對所有評論（公開和私人）表示感謝，并回答最后一個帖子。 飛行員負責將通知發送給用戶。 這些是分布式守護程序，旨在可伸縮且不會過載。 實時消息傳遞（讀取 IM，桌面應用程序）引擎每秒可以處理數千條消息。 電子郵件和短信（在獲得簡短代碼之前）是另一回事。 電子郵件是通過多頭 smtp 集群發送的，但是，我們只能依靠 smtp 協議流程的工作方式。 因此可能會有時間波動。 我們建議任何想要立即收到通知的人使用 Instant Messenger 或我們的桌面應用程序。 謝謝， 杰森 Jason， 謝謝您的答復。 正如您提到的， “實時消息傳遞（讀取 IM，桌面應用程序）引擎每秒可以處理數千條消息。” 使用 IM 的訂戶可以同時接收通知嗎？ 是否沒有循環遍歷所有訂戶并向其發送通知？ 因為我絕對是可伸縮性的新手，所以我能想像出要解決此問題的方法是導入“ fork-join”模型，以同步所有守護程序。 祝您一切順利 劉浩 Hello Hao Liu, 用戶可以在同一批次中收到多個通知。 批處理是我們創建的 2 秒窗口，用于將同時到達的消息分組在一起。 每個用戶只有一個輕量級守護程序（稱為 Avatar）。 每個用戶平均每天會收到 30 條通知，因此大多數時間它處于空閑狀態，并且有足夠的空間來處理一組消息。 雖然它們要在相同的時間實例中進行處理。 它們將在不到一秒的時間內被處理（我們的目標是每位用戶每秒處理約 100 條消息）。