面對突發流量激增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，由方圓翻譯。轉載本文請註明出處，歡迎更多小夥伴加入翻譯及投稿文章的行列，詳情請戳公眾號選單「聯絡我們」。參考閱讀： ofollow,noindex" target="_blank">為何伺服器QPS上不去？Java執行緒調優權威指南
- 360001c06ba574c14f734e7b9d7a450161214b1&scene=21#wechat_redirect" rel="nofollow,noindex" target="_blank">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最新技術。 點選“閱讀原文”瞭解大會更多詳情。