# 美國大選期間城市飛艇如何擴展到 25 億個通知 > 原文： [http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html](http://highscalability.com/blog/2016/11/14/how-urban-airship-scaled-to-25-billion-notifications-during.html)  *這是 Urban Airship 的來賓帖子。 貢獻者：亞當·洛瑞（Adam Lowry），肖恩·莫蘭（Sean Moran），邁克·赫里克（Mike Herrick），麗莎·奧爾（Lisa Orr），托德·約翰遜（Christine Ciandrini），阿什什·沃蒂（Ashish Warty），尼克·阿德雷德（Nick Adlard），梅勒·薩克斯·巴尼特（Mele Sax-Barnett），尼爾·凱利（Niall Kelly），格雷厄姆·福里斯特（Graham Forest）和加文·麥奎蘭* Urban Airship 受到數以千計的希望通過移動技術發展的企業的信任。 Urban Airship 是一家成立 7 年的 SaaS 公司，擁有免費增值業務模式，因此您可以免費試用 [](https://www.urbanairship.com/lps/best-push-notification-service)。 有關更多信息，請訪問 [www.urbanairship.com](http://www.urbanairship.com/) 。 目前，城市飛艇平均每天發送的推送通知超過 10 億條。 這篇文章重點介紹了 2016 年美國大選的城市飛艇通知使用情況，并探討了系統的架構-核心傳遞管道-為新聞發布者提供數十億實時通知。 ## 2016 年美國大選 在選舉日前后的 24 小時內，Urban Airship 發出了 25 億條通知，這是有史以來的最高日發送量。 這相當于在美國每人 8 條通知，或者世界上每部活動的智能手機 1 條通知。 盡管 Urban Airship 在每個行業垂直領域為超過 45,000 個應用程序提供支持，但對選舉使用情況數據的分析顯示，超過 400 種媒體應用程序占了這一記錄量的 60％，隨著跟蹤選舉結果并在一天之內發送 15 億條通知 報告。  總統選舉結束時，通知量穩定并達到頂峰。  到城市飛艇的 HTTPS 入口流量 [API](http://docs.urbanairship.com/api/ua.html) 在選舉期間達到了每秒近 75,000 的峰值。 這些流量大部分來自與城市飛艇 [API](http://docs.urbanairship.com/api/ua.html) [ 。  推送通知量一直在迅速增加。 最近的主要推動力是英國退歐，奧運會和美國大選。 2016 年 10 月，每月通知量同比增長 150％。  ## 核心交付管道架構概述 核心交付管道（CDP）是城市飛艇系統，負責從觀眾選擇器中實現設備地址，并傳遞通知。 無論我們同時發送給數千萬用戶，針對多個復雜子細分市場，包含個性化內容或兩者之間的任何內容，我們發送的所有通知都期望低延遲。 這是我們的架構的概述，以及我們在此過程中學到的一些知識。 ### 我們是如何開始的 最初始于 2009 年，最初是一個 Web 應用程序，一些工作人員已轉變為面向服務的體系結構。 隨著舊系統的各個部分開始出現規模問題，我們將它們提取到了一個或多個新服務中，這些服務旨在滿足相同的功能集，但規模更大且性能更好。 我們許多原始的 [API](http://docs.urbanairship.com/api/ua.html) API 和工作程序都是用 Python 編寫的，然后將它們提取到高并發 Java 服務中。 在最初將設備數據存儲在一組 Postgres 分片中的地方，我們的規模迅速超過了添加新分片的能力，因此我們轉向使用 HBase 和 Cassandra 的多數據庫體系結構。 CDP 是處理分段和推送通知傳遞的服務的集合。 這些服務根據請求提供相同類型的數據，但是出于性能原因，每個服務都以不同的方式對數據進行索引。 例如，我們有一個系統負責處理廣播消息，向注冊到相關應用程序的每個設備傳遞相同的通知有效負載。 該服務及其底層數據存儲區的設計與我們負責根據位置或用戶個人資料屬性傳遞通知的服務的設計有很大不同。 我們將任何長期存在的進程視為一項服務。 這些長期存在的過程遵循有關度量，配置和日志記錄的通用模板，以簡化部署和操作。 通常，我們的服務屬于以下兩類之一：RPC 服務或使用者服務。 RPC 服務使用非常類似于 GRPC 的內部庫提供命令來與服務進行同步交互，而消費者服務則處理來自 Kafka 流的消息并對這些消息執行特定于服務的操作。  ### 數據庫 為了滿足我們的性能和規模要求，我們嚴重依賴 HBase 和 Cassandra 來滿足我們的數據存儲需求。 盡管 HBase 和 Cassandra 都是列式 NoSQL 存儲，但它們的取舍卻大不相同，這些折衷影響我們使用哪個存儲以及用于什么目的。 HBase 非常適合高通量掃描，響應的預期基數很高，而 Cassandra 非常適合低基數查找，其中響應僅包含少數結果。 兩者都允許大量的寫入吞吐量，這是我們的要求，因為來自用戶手機的所有元數據更新都是實時應用的。 它們的故障特性也不同。 在發生故障時，HBase 支持一致性和分區容忍度，而 Cassandra 支持可用性和分區容忍度。 每個 CDP 服務都有一個非常特定的用例，因此具有高度專業化的架構，旨在促進所需的訪問模式并限制存儲空間。 通常，每個數據庫僅由單個服務訪問，該服務負責通過不太專門的界面提供對其他服務的數據庫訪問。 增強服務與其支持數據庫之間的 1：1 關系具有許多好處。 * 通過將服務的支持數據存儲視為實現細節而不是共享資源，我們獲得了靈活性。 * 我們可以在不更改服務代碼的情況下調整服務的數據模型。 * 使用情況跟蹤更為直接，這使容量規劃更加容易。 * 故障排除更加容易。 有時服務代碼存在問題，而其他時候則是備份數據庫問題。 將服務和數據庫作為邏輯單元可以極大地簡化故障排除過程。 我們不必懷疑“還有誰可以訪問該數據庫以使其表現為這種方式？” 相反，我們可以依靠服務本身的應用程序級指標，而只擔心一組訪問模式。 * 因為只有一種服務與數據庫交互，所以我們幾乎可以執行所有維護活動，而無需停機。 繁重的維護任務成為服務級別的問題：可以在不中斷服務的情況下完成數據修復，架構遷移，甚至切換到完全不同的數據庫。 的確，在將應用程序拆分為較小的服務時，可能需要進行一些性能折衷。 但是，我們發現，在滿足高可伸縮性和高可用性要求方面獲得的靈活性遠遠超過了其價值。 ### 數據建模 我們的大多數服務都處理相同的數據，只是格式不同。 一切都必須一致。 為了使所有這些服務的數據保持最新，我們嚴重依賴 Kafka。 Kafka 非常快，也很耐用。 速度需要權衡。 Kafka 郵件只能保證至少發送一次 ，并且不能保證依次發送。 我們如何處理？ 我們已將所有變異路徑建模為可交換的：操作可以按任何順序應用，并最終得到相同的結果。 它們也是冪等的。 這有一個很好的副作用，我們可以重播 Kafka 流以進行一次性數據修復作業，回填甚至遷移。 為此，我們利用了 HBase 和 Cassandra 中都存在的“單元版本”的概念。 通常，這是一個時間戳，但是可以是您想要的任何數字（有一些例外；例如，MAX_LONG 可能會導致一些奇怪的行為，具體取決于您的 HBase 或 Cassandra 的版本以及您的架構如何處理刪除操作）。 對我們來說，這些單元格的一般規則是它們可以具有多個版本，而我們訂購版本的方式則取決于其提供的時間戳。 考慮到這種行為，我們可以將傳入的消息分解為一組特定的列，然后將布局與自定義應用程序邏輯結合起來進行邏輯刪除，同時考慮時間戳。 這樣就可以在保持數據完整性的同時盲寫基礎數據存儲。 盲目地將更改寫入 Cassandra 和 HBase 并非沒有問題。 一個很好的例子是在重放事件中重復寫入相同數據的情況。 由于我們努力使記錄成為冪等，雖然數據的狀態不會改變，但必須壓縮重復的數據。 在最極端的情況下，這些額外的記錄可能會導致大量的壓縮延遲和備份。 由于這個細節，我們密切監視壓縮時間和隊列深度，因為在 Cassandra 和 HBase 中落后于壓縮會導致嚴重的問題。 通過確保流中的消息遵循一組嚴格的規則，并設計使用服務以預期亂序和重復的消息，我們可以使大量不同的服務僅同步一兩個秒 滯后的更新。 ### 服務設計 我們的大多數服務都是用 Java 編寫的，但是使用的是一種自以為是的現代風格。 在設計 Java 服務時，我們有一組常規準則需要考慮： * **做一件事，做好它。** -設計服務時，它應該承擔單一責任。 實施者可以決定職責中包括的內容，但是他或他將需要準備在代碼審查情況下證明其合理性。 * **沒有共享的操作狀態** -設計服務時，假定將始終至少有三個實例在運行。 服務需要能夠在沒有任何外部協調的情況下處理任何其他實例可以處理的相同確切請求。 那些熟悉 Kafka 的人會注意到，Kafka 使用者在外部協調對 topic：group 對的分區所有權。 本指南涉及特定于服務的外部協調，而不是利用可能在幕后進行外部協調的庫或客戶端。 * **約束您的隊列** -我們在服務中使用隊列，它們是將請求分批并將其散布到最終將完成任務的工作人員的好方法 從外部阻止。 所有隊列都應有界。 邊界隊列確實引發了許多問題，但是： * 當隊列已滿時，生產者會怎樣？ 他們應該阻止嗎？ 除？ 下降？ * 我的隊列應該有多大？ 要回答此問題，有助于假設隊列始終已滿。 * 如何完全關閉？ * 根據確切的用例，每個服務將針對這些問題提供不同的答案。 * **命名自定義線程池并注冊 UncaughtExceptionHandler** -如果最終創建自己的線程池，則使用 [的構造函數或幫助器方法 ]執行器](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html) ，以便我們提供 ThreadFactory。 使用該 ThreadFactory，我們可以正確地命名線程，設置線程的守護進程狀態并注冊 [UncaughtExceptionHandler](https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-) 以處理將異常置于頂部的情況 堆棧。 這些步驟使調試我們的服務變得更加容易，并且使我們避免了深夜的沮喪。 * **優先于可變狀態而不是可變狀態** -在高度并發的環境中，可變狀態可能很危險。 通常，我們使用可以在內部子系統和隊列之間傳遞的不可變數據對象。 擁有不變對象是子系統之間通信的主要形式，這使得并發使用的設計更加簡單，并且使故障排除更加容易。 ## 我們從這里去哪里？ 憑借 Urban Airship 通過移動錢包通行證發送通知的功能，對 Web 通知和 Apple News 通知的新支持以及其將通知發送到任何平臺，設備或營銷渠道的開放渠道功能，我們預計通知量將成倍增長 。 為了滿足這一需求，我們將繼續在“核心交付管道”架構，服務，數據庫和基礎架構上進行大量投資。 要了解有關我們技術的更多信息以及前進的方向，請參閱 [GitHub](https://github.com/urbanairship) ， [開發人員資源](http://docs.urbanairship.com/dev-resources.html) ， [文檔](http://docs.urbanairship.com/index.html) 和我們的 [職位頁面](https://www.urbanairship.com/careers) 。