釺幫助消費品牌使用數據個性化的消息,如電子郵件、應用信息,推送通知,短信。釺運行在大規模:每一天我們將數十億的消息發送到世界各地的月度活躍用戶超過二十億。鑒於這種規模和性能需求的信息,處理速度至關重要。在這篇文章中,我將提供一些背景如何使用AWS自動伸縮功能盡快處理,節省成本。
首先,有兩個主要類別進行處理在釺:數據處理和消息發送。當客戶與釺集成時,manbetx万博全站客户端他們通常在手機安裝一個SDK應用程序或網站。每次有人使用一個應用程序或訪問一個網頁,釺結合,我們的服務器處理數據以了解更多關於最終用戶的偏好和行為。釺也攝食數據合作夥伴,如段,mParticle,振幅,AppsFlyer。每一條數據需要盡快處理,因為每個數據點會影響客戶messaging-an行動用戶需要可能會導致一個消息發送或預定的信息被取消。轉換數據也告訴我們如果一個客戶活動的目標,這可能將客戶在他們的生命周期。
第二類是消息發送。釺的客戶可以發送manbetx万博全站客户端各種類型的信息,我們稱之為運動。運動可以單一消息或組成的整個生命周期策略組成的多個消息跨多個天或數周。活動可以安排在特定的時間出去,立即發送,由用戶行為或API調用,或者更多。我們的客manbetx万博全站客户端戶希望我們很快發送他們的消息。性能總是會要求增加的預期。釺每天發送約二十億條消息,這意味著我們發送平均近140萬條每一分鍾!
對我們來說最大的問題是,如何釺過程數據和發送消息沒有打破銀行盡快?也就是說,雖然我們總是可以添加更多的硬件規模和過程更快,我們需要確保我們為我們自己和我們的客戶經營合算的生意。manbetx万博全站客户端解釋如何做到這一點,我們先來學習一下我們的數據基礎設施。
釺部署數據庫為客戶在三個不同的模型。manbetx万博全站客户端小客戶共享數據庫。中型客戶數據在共享服務器上存儲在專用數據庫。我們最大的客戶有自己的專用數據庫在專用服務器。這種方法允許釺在每個用戶的基礎上,提供不同大小的數據庫和移動客戶成長。manbetx万博全站客户端
使用這種方法,然後構建應用程序服務器優先工作在特定的數據庫集群。這些應用程序服務器處理數據和發送消息之前,先為他們分配給集群試圖為其他集群過程。
支撐這種設計是我們使用的工作隊列。我們對我們的作業隊列有一個完全獨立的博客係統,但我會總結他們在這裏。工作隊列異步處理的體係結構模式。應用程序提交一個“工作”放在一個隊列。然後,“工人”進程從隊列獲取和操作。工作隊列模式有助於提高並發性、可靠性和可伸縮性。釺使用不同類型的隊列和工人消費從許多不同的隊列。總共釺過程數十億每天工作在幾十個複述,數據庫碎片。每個切分處理每秒近200 k操作在峰值負載!
我們支持的方式將不同的應用服務器與數據庫集群是通過我們的隊列部署:每個數據庫都有自己的一組隊列和自己的一組工人的應用服務器。
有極大的好處。首先,為特定的客戶可以幫助我們得到隔離與安全性和遵從性需求。我們的隊列部署模型也提高了可擴展性,允許我們增加吞吐量增加更多的複述,數據庫,工作隊列和應用程序服務器。還有其他的好處在我們的值得一看博客對我們的排隊係統。
回到消息,讓我們快速看一下消息發送管道在釺。
在高級別上,我們首先確定用戶發送消息的觀眾。然後,一些業務邏輯跑到觀眾中找出誰應該接收一條消息。例如,讓我們說我們是發送電子郵件,但觀眾中給定用戶沒訂閱或沒有一個電子郵件地址。或者我們發送推送通知iOS用戶提醒他們關於一個更新,和一個特定用戶的觀眾隻有一個Android用戶。在這種情況下,我們要把這些用戶過濾掉。接下來,我們執行完整性檢查結果觀眾反對任何全球頻率上限。為了避免發送太多信息給終端用戶,釺客戶可以配置規則,如“每周不超過三封電子郵件,每天不超過一個任何類型的消息。manbetx万博全站客户端“一旦我們知道誰釺發送活動,信息呈現,數據庫狀態被更新時,消息被發送出去。
在一個多步驟的管道,工作隊列可以構成的挑戰,因為所謂的“隊列的饑餓。”隊列天生的先進先出。這意味著如果我們有100個工作崗位為客戶客戶B的前一份工作在同一隊列,沒有什麼會被處理為客戶B直到所有100個工作機會為客戶處理A。要解決這個問題,我們建立了我們自己的動態隊列係統,為每個部分創建短暫的工作隊列消息發送管道。工人服務器然後加權選擇動態隊列上特定於數據庫分配它們。
為每個組和集群,我們收集一組作業隊列指標,如工作隊列的數量/可用性區域,延遲統計,有多少工作在未來我們將過程。
因此,釺的表現一直很高,我們每個月節省成千上萬美元的這種技術。
有很多方法讓我們提高我們如何在釺汽車規模;看看我們的工作頁麵加入我們的團隊!
