建築釺

緩存並發控製

通過喬恩·海曼2019年5月30日

得到分頁

它開始像許多作戰的故事,與一個Apdex頁麵與我們的一個SDK API集群22點。東部時間,醒來釺待命的工程師。Apdex的API之間的反應時間是衡量當API調用和當我們係統的回報。除了Apdex,我們的一個SDK API集群是返回HTTP 503錯誤無法提供服務。

Apdex問題往往意味著有數據庫緩慢或沉重的東西導致延誤。果然,看著我們的API集群之一DataDog我們看到高CPU利用率的一個API服務器的集群致力於我們的一個客戶。manbetx万博全站客户端在這個圖表,每個蜂窩單元格代表一個API服務器,和越橘,更高的CPU。

給你一些背景,在釺我們規模服務通過構建不同的“集群”的收集係統,包括我們的產品,創建不同的設施,我們可以運行個人客戶。manbetx万博全站客户端我們甚至建立專用API服務器或特定客戶的處理係統。manbetx万博全站客户端每月有超過16億活躍用戶,每月處理一萬億條數據和發送每天超過十億的消息,這個架構幫助我們分發負載和提高我們的服務質量。

因為我們的API服務器是無狀態並返回內容調用設備,我們自動定量SDK API艦隊基於CPU利用率。頁麵去的時候,我們自動定量程序已經擴大到近60 c4.4xlarge EC2服務器(約35美元k / mo點播服務器!),這個特定的API也處理每秒20000 API調用。

挖一點深入我們的應用程序性能監控(APM)工具,新的遺跡,我們看到平均響應時間約5 x預期的閾值,與大部分的布朗在這段時間,我們trigger_payloads標記”。“我們會在一個時刻,因為它是在早晨兩點鍾,我們需要解決這個問題。

每我們runbook CPU問題在我們的SDK API艦隊,第一步是要添加更多的CPU來穩定係統。盡管三倍活動API服務器的數量,這個問題並沒有消失。快速我們的圖表表示我們還收到周期性爆發的503年代這個API端點為我們的一個客戶。manbetx万博全站客户端

投入更多的硬件,不會解決問題。讓我們圓回“trigger_payload”部分的代碼。

銅焊的應用產品的消息

與“trigger_payloads”代碼塊銅焊的應用程序消息傳遞產品。互操作的api與我們的sdk做大量的複雜的處理。因為我們每一個sdk,無論是對iOS、Android,團結,網絡,或任何我們的一個打sdk,有當業務規則引擎應用消息(“艾瑪”)到最終用戶。銅焊的應用程序消息傳遞產品允許我們的客戶提供實時應用的消息將顯示當一個特定事件觸發。manbetx万博全站客户端一個客戶可能想要發送應用程序消息新注冊用戶完成購買,而另一個可以選擇的目標說西班牙語的用戶還沒有訂閱推送通知時聽的歌。

每次最終用戶會話開始在我們的一個客戶的應用程序或網站,艾瑪釺SDK請求,用戶可能有資格獲得。manbetx万博全站客户端SDK將下載並解壓所有的這些應用程序消息,連同他們的觸發條件,這樣一旦最終用戶執行的活動,顯示我沒有任何額外的延遲。這提供了一個無縫的產品體驗客戶的最終用戶,使釺作為如果它是應用程序的一部分。manbetx万博全站客户端

API層,擁有這樣一個靈活的應用程序消息產品意味著決定哪些可以相當cpu密集型艾瑪送下來。在每個API調用,API決定了最終用戶在設備上的請求,讀取所有可能的應用程序消息的應用程序,然後計算合格標準為用戶確定哪些艾瑪送下來。沒有限製有多少不同應用消息客戶可以主動一次。manbetx万博全站客户端使用的所有可能的應用程序消息,API讀取目標標準和流程,並將其存儲在memcached 90秒的TTL(或者,time - to - live)其他API過程可以使用計算狀態。

在銅焊,我們依靠很多APM調試和故障排除工具。當我們挖到代碼生成的這一個特定客戶的應用程序消息,我們注意到,盡管我們的API的平均響應時間是66 ms,每90秒我們看到大約6000 API調用超過14秒!每次發生這種情況,它引起了短暫的激增HTTP 503錯誤,正如我們的後台無法為所有迎麵而來的交通服務。