面對突發流量激增Coinbase如何擴展其交易平臺

面對突發流量激增Coinbase如何擴展其交易平臺

導讀：2017年以來，世界範圍內都在關注加密貨幣，Coinbase流量壓力激增。Coinbase怎麼應對這些流量壓力，又怎麼在流量非高峯時期作準備，這是不少技術人都關心的話題。本文做者是Coinbase工程師團隊成員，就這些問題給出了詳盡的解釋。

2017年以來，世界範圍內都在關注加密貨幣，所以其整個生態系統的市值從200億美金躍升至6000億美金。在此期間，coinbase的全部技術組件都經歷了實戰的檢驗，咱們除了須要關注安全性以外，平臺的可靠性和可擴展性也是很是重要的。咱們在MongoDB World 2018上，咱們談到了2017年技術上的收穫，以及如何擴展咱們現有平臺。這裏有演講視頻[1]，本文是此次演講的概述。

2017年的教訓

2016年的時候，coinbase的流量還比較平穩。咱們也預計過可能遇見的問題，由於後端平均每分鐘處理25000個API請求，因此咱們將流量紅線設置爲每分鐘10萬個API請求。

然而，隨着2017年5月-6月以太坊價格飆升，流量超過了紅線，所以咱們也經歷了服務宕機的狀況。

爲了快速解決問題，Coinbase的工程師團隊首先關注環境中的瓶頸。咱們坐了不少工做好比，垂直拆分擴展，升級數據庫版本（以利用新版本的特性），優化索引以及將熱點數據庫拆分等。全部的這些措施都爲咱們帶來很大改進，然而流量持續攀升，僅僅靠這些還不夠。

在每次出問題的時候，出問題的模式都是相似的：咱們的監控平臺顯示有很是高的（100倍）延遲，而且伴隨着ruby服務器和mongodb數據庫之間事物處理時間的不匹配。咱們主要使用Mongdb存儲數據，在流量大的時候會遇到這種高延遲，然而ruby服務的時間卻沒有增長。

由於咱們的監控工具沒法爲這些問題的緣由提供答案，所以咱們稱之爲幽靈問題。這些查詢來自哪裏？查詢看起來在作什麼？爲何ruby處理時間也有峯值？問題是在應用程序這邊嗎？

簡而言之，咱們的監控系統沒法利用咱們全部環境。咱們須要一個框架來回答這些問題，而且將之可視化。

咱們開始經過修改mongodb驅動來追蹤查詢，能夠記錄超過響應時間閾值的查詢，以及request/response大小，響應時間，源代碼行等信息。

改進後的dashboard提供了更詳細的數據，使咱們能快速縮小問題的範圍。咱們注意到的第一個奇怪的現象是，咱們用戶登陸購買或者查看儀表板的時候，會有大量查詢。

這種狀況的緣由是咱們的用戶和設備之間是多對多關係。即某些用戶可能有多個設備，某些設備對應多個用戶。糟糕的設備指紋識別算法將大量用戶置於同一設備中，從而致使單個設備對應大量user_id。

爲了解決這一問題，咱們將之重構爲一對多關係，即每一個設備只映射到一個用戶。從下圖能夠看到，性能提高是很大的。

這也說明了良好的監控工具的必要性，在可以細粒度追蹤數據庫查詢以前，幾乎沒法發現這一問題。使用新工具以後，就很容易發現問題了。

咱們須要解決的另外一個問題是熱點集合的大量讀取。咱們決定使用memcached緩存查詢結果，即在查數據庫以前，全部請求都先查詢緩存，在寫數據庫以前，也會先作操做使緩存失效。

爲了可以儘可能與業務解耦，緩存是在ORM和數據庫驅動這一層添加的，這使得咱們同時影響多個數據庫集羣。

通過12月和1月份的流量激增證實，這些改進都是很是有效的措施。藉助這些手段，咱們可以成熟更大的流量激增。

爲了未來

如今咱們正努力確保在下一次流量激增以前作好準備。雖然在流量激增期間能夠作不少工做，可是咱們須要找到一種方法來改善咱們現有表現，以在流量較低的時間就能夠作好準備。顯然能夠經過模擬流量激增來測試咱們現有的環境，以發現咱們下一個問題來自哪裏。

咱們選擇的方案是流量捕獲和回放，特別是在數據庫上，按需生成流量。對咱們來講，這種方式比僞造流量更爲可取，由於不須要讓測試腳本跟隨業務迭代。每次運行測試套件時，咱們都會確保查詢捕獲的數據準備映射到應用程序流量。

爲此咱們構建了一個名爲capture的工具，它是mongoreplay的封裝。在咱們選定特定集羣后，catpure會啓動快照並開始捕獲定向到該集羣的應用服務器上的原始流量。以後對數據進行加密，並存儲到S3上。當咱們執行回放時，有另外一個名爲cannon的工具，將捕獲的流量回放到新啓動的集羣。

這個模式的一個挑戰是如何跨越多個應用服務器捕獲全部mongodb流量。cannon會打開10MB緩衝區，同時合併和過濾捕獲的流量來解決問題。

最終的結果是合併到一個文件中，cannon能夠將其定向到新推出的mongodb集羣。cannon容許精確選擇重放的速度，以模擬數千倍的流量負載。

咱們剛開始使用capture 和cannon，然而已經獲得不錯的結果。

其中一個重大發現來自cannon的調試功能，cannon可以檢查捕獲流量文件的前100條消息。通過檢查，咱們發現了一些有趣的事情。

請注意ping和find混合在一塊兒。事實證實，mongodb的ruby驅動未遵循正確的mongodb驅動規範。在每次find以前都執行ping命令以檢查副本集狀態。這種行爲雖然不太可能致使停機，可是基本能夠確定，這是前文所述幽靈行爲的緣由。

在通過這些努力以後，咱們爲coinbase目前的可靠性而自豪。2017年的事件證實，客戶訪問和查看資金的能力，對於達成咱們的目標（購買，銷售，管理加密貨幣）相當重要。雖然安全始終是咱們的首要任務，可是可靠性一樣重要。

原文地址：
https://blog.coinbase.com/how-were-scaling-our-platform-for-spikes-in-customer-demand-4a047cb3139c

文中連接：
[1] https://www.youtube.com/watch?v=i6ws1JpvNs0

本文做者Luke Dem，由方圓翻譯。轉載本文請註明出處，歡迎更多小夥伴加入翻譯及投稿文章的行列，詳情請戳公衆號菜單「聯繫咱們」。

參考閱讀：

• 爲什麼服務器QPS上不去？Java線程調優權威指南
• C++ Python PHP Java NodeJS性能大PK，結果PHP7是最……
• 2016 GIAC全球互聯網架構大會圓滿結束，所有PPT開放下載
• 一文讀懂Java 11的ZGC爲什麼如此高效
• JDK 11中將會加入使人驚歎的ZGC(不到2毫秒)
• 深刻解讀 Java 9 新特性
• Java10來了，來看看它一同發佈的全新JIT編譯器
• Java性能優化指南及惟品會的實戰

活動預告：
11 月 23 ~ 24 日，GIAC 全球互聯網架構大會將於上海舉行。GIAC 是高可用架構技術社區推出的面向架構師、技術負責人及高端技術從業人員的技術架構大會。今年的 GIAC 已經有微軟，騰訊、阿里巴巴、螞蟻金服，華爲，科大訊飛、新浪微博、京東、七牛、美團點評、餓了麼，才雲，格靈深瞳，Databricks，等公司專家出席。

本期 GIAC 大會上，系統架構部分精彩的議題以下：
參加 GIAC，盤點2018最新技術。點擊「閱讀原文」瞭解大會更多詳情。