# Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入 > 原文： [http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html)  如果您是 Uber，并且需要存儲駕駛員和駕駛員應用程序每 30 秒發送一次的位置數據，該怎么辦？ 大量實時數據需要實時使用。 Uber 的解決方案是全面的。 他們構建了自己的系統，該系統在 Mesos 之上運行 Cassandra。 Uber 的軟件工程師 [Abhishek Verma](https://www.linkedin.com/in/verma7) 在一個很好的演講中都進行了解釋： [Cassandra 在跨多個數據中心的 Mesos 上 Uber](https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be) （ [幻燈片](http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016) ）。 您也應該這樣做嗎？ 在聽 Abhishek 的演講時，會想到一個有趣的想法。 這些天來，開發人員有很多艱難的選擇。 我們應該全力以赴嗎？ 哪一個？ 太貴了嗎？ 我們擔心鎖定嗎？ 還是我們應該嘗試同時兼顧并打造混合架構？ 還是我們應該自己做所有事情，以免由于未達到 [50％](http://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/) 毛利率而被董事會蒙羞？ Uber 決定建立自己的公司。 或者更確切地說，他們決定將兩個功能強大的開源組件融合在一起，從而將自己的系統焊接在一起。 所需要的是一種使 Cassandra 和 Mesos 協同工作的方法，而這正是 Uber 的基礎。 對于 Uber 的決定并不那么困難。 他們資金充裕，可以訪問創建，維護和更新這類復雜系統所需的頂尖人才和資源。 由于 Uber 的目標是使所有人在任何地方的運輸都具有 99.99％的可用性，因此在擴展到無限遠及更高水平時，希望能夠控制您的成本確實很有意義。 但是，當您聽演講時，您會意識到制作此類系統所付出的巨大努力。 這真的是您的普通商店可以做的事情嗎？ 不，不是。 如果您是那些希望每個人都在裸露的金屬之上構建自己的所有代碼的云專家之一，請記住這一點。 以金錢換時間通常很劃算。 通常，以技能交易金錢是絕對必要的。 鑒于 Uber 的可靠性目標，即 10,000 個請求中只有一個可能失敗，因此他們需要在多個數據中心中用完。 由于事實證明 Cassandra 可以處理巨大的負載并且可以跨數據中心工作，因此將其作為數據庫選擇是有意義的。 如果您想使所有人，任何地方的運輸都可靠，則需要有效地利用您的資源。 這就是使用像 Mesos 這樣的數據中心操作系統的想法。 通過在同一臺計算機上統計復用服務，您需要的計算機數量減少了 30％，從而節省了資金。 之所以選擇 Mesos，是因為當時 Mesos 是經證明可與數以萬計的計算機集群大小一起工作的唯一產品，這是 Uber 的要求。 優步的工作量很大。 有哪些更有趣的發現？ * 您可以在容器中運行有狀態服務。 Uber 發現，在裸機上運行 Cassandra 與在 Mesos 管理的容器中運行 Cassandra 之間幾乎沒有任何區別，開銷為 5-10％。 * 性能良好：平均讀取延遲：13 毫秒，寫入延遲：25 毫秒，P99 看起來不錯。 * 對于最大的群集，他們能夠支持超過一百萬次寫入/秒和約 10 萬次讀取/秒。 * 敏捷性比性能更重要。 通過這種架構，Uber 獲得的就是敏捷性。 跨集群創建和運行工作負載非常容易。 這是我的演講要點： ## 開頭 * 跨不同服務的靜態分區機器。 * 50 臺機器可能專用于 API，50 臺機器專用于存儲，等等，并且它們沒有重疊。 ## 即時 * 希望在 [Mesos](http://mesos.apache.org/) 上運行所有內容，包括諸如 Cassandra 和 Kafka 之類的有狀態服務。 * Mesos 是數據中心操作系統，可讓您像單一資源池一樣針對數據中心進行編程。 * 當時，事實證明 Mesos 可以在成千上萬的計算機上運行，??這是 Uber 的要求之一，因此這就是他們選擇 Mesos 的原因。 今天，Kubernetes 可能也可以工作。 * Uber 在 MySQL 之上構建了自己的分片數據庫，稱為 [Schemaless](https://eng.uber.com/schemaless-part-one/) 。 這個想法是 Cassandra 和 Schemaless 將成為 Uber 中的兩個數據存儲選項。 現有的 Riak 裝置將移至 Cassandra。 * 一臺機器可以運行各種服務。 * 同一臺機器上的統計復用服務可能會導致 的機器數量減少 30％ 。 這是 Google 在 Borg 上運行的 [實驗](http://research.google.com/pubs/pub43438.html) 的發現。 * 例如，如果一項服務使用大量 CPU，并且與使用大量存儲或內存的服務非常匹配，那么這兩項服務可以在同一服務器上有效運行。 機器利用率上升。 * Uber 現在有大約 20 個 Cassandra 集群，并計劃在將來有 100 個。 * 敏捷性比性能更重要。 您需要能夠管理這些集群并以平滑的方式對其執行不同的操作。 * **為什么在容器中而不是在整個機器上運行 Cassandra？** * 您想存儲數百 GB 的數據，但您還希望將其復制到多臺計算機上以及跨數據中心。 * 您還希望跨不同群集進行資源隔離和性能隔離。 * 很難在一個共享群集中獲得所有這些。 例如，如果您制作了一個 1000 節點的 Cassandra 群集，它將無法擴展，或者跨不同群集也會產生性能干擾。 ## 量產中 * 在兩個數據中心（西海岸和東海岸）中復制約 20 個群集 * 最初有 4 個集群，包括中國，但由于與滴滴合并，這些集群被關閉了。 * 跨兩個數據中心的 300 臺機器 * 最大的 2 個集群：每秒超過 100 萬次寫入和每秒 10 萬次讀取 * 群集之一正在存儲駕駛員和騎乘者應用程序每 30 秒發送一次的位置。 * 平均讀取延遲：13 毫秒，寫入延遲：25 毫秒 * 通常使用 [LOCAL_QUORUM](https://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html) 一致性級別（表示強一致性） ## 月背景資料 * Mesos 將 CPU，內存和存儲從計算機中分離出來。 * 您不是在查看單個計算機，而是在查看資源并對其進行編程。 * 線性可伸縮性。 可以在數以萬計的計算機上運行。 * 高度可用。 Zookeeper 用于在可配置數量的副本中進行領導者選舉。 * 可以啟動 Docker 容器或 Mesos 容器。 * 可插拔資源隔離。 用于 Linux 的 Cgroups 內存和 CPU 隔離器。 有一個 Posix 隔離器。 不同的操作系統有不同的隔離機制。 * 兩級調度程序。 來自 Mesos 代理的資源被提供給不同的框架。 框架在這些提議的基礎上安排自己的任務。 ## Apache Cassandra Backgrounder * Cassandra 非常適合 Uber 的用例。 * 水平可擴展。 隨著新節點的添加，讀寫規模呈線性增長。 * 高度可用。 具有可調一致性級別的容錯能力。 * 低延遲。 在同一數據中心內獲得亞毫秒級的延遲。 * 操作簡單。 這是同質的簇。 沒有主人。 集群中沒有特殊的節點。 * 足夠豐富的數據模型。 它具有列，組合鍵，計數器，二級索引等 * 與開源軟件的良好集成。 Hadoop，Spark，Hive 都具有與 Cassandra 進行通信的連接器。 ## 中層+ Uber + Cassandra = dcos-cassandra-service * Uber 與 Mesosphere 合作生產了 [mesosphere / dcos-cassandra-service](https://github.com/mesosphere/dcos-cassandra-service) -一種自動化服務，可輕松在 Mesosphere DC /上進行部署和管理 操作系統。  * 頂部是 Web 界面或 Control Plane API。 您指定所需的節點數； 您想要多少個 CPU； 指定 Cassandra 配置； 然后將其提交給 Control Plane API。 * 使用 Uber 的部署系統，它在 [Aurora](http://aurora.apache.org/) 之上啟動，用于運行無狀態服務，用于引導 dcos-cassandra 服務框架。 * 在示例 dcos-cassandra-service 框架中有兩個與 Mesos 主服務器通信的集群。 Uber 在其系統中使用了五個 Mesos 母版。 Zookeeper 用于領導者選舉。 * Zookeeper 還用于存儲框架元數據：正在運行的任務，Cassandra 配置，集群的運行狀況等。 * Mesos 代理在群集中的每臺計算機上運行。 代理將資源提供給 Mesos 主服務器，主服務器以離散報價分發它們。 報價可以被框架接受或拒絕。 多個 Cassandra 節點可以在同一臺計算機上運行。 * 使用 Mesos 容器，而不是 Docker。 * 覆蓋配置中的 5 個端口（storage_port，ssl_storage_port，native_transport_port，rpcs_port，jmx_port），因此可以在同一臺計算機上運行多個容器。 * 使用永久卷，因此數據存儲在沙箱目錄外部。 萬一 Cassandra 失敗，數據仍將保留在持久卷中，如果崩潰并重新啟動，則將數據提供給同一任務。 * 動態預留用于確保資源可用于重新啟動失敗的任務。 * Cassandra 服務操作 * Cassandra 有一個 [種子節點](https://www.quora.com/What-is-a-seed-node-in-Apache-Cassandra) 的想法，它為加入集群的新節點引導八卦過程。 創建了自定義 [種子提供程序](https://mesosphere.github.io/cassandra-mesos/docs/configuration-and-state.html) 來啟動 Cassandra 節點，該節點允許 Cassandra 節點自動在 Mesos 群集中推出。 * 可以使用 REST 請求增加 Cassandra 群集中的節點數。 它將啟動其他節點，為其提供種子節點，并引導其他 Cassandra 守護程序。 * 可以更改所有 Cassandra 配置參數。 * 使用 API??可以替換死節點。 * 需要修復才能跨副本同步數據。 維修在每個節點的主鍵范圍內進行。 這種方法不會影響性能。 * 清除將刪除不需要的數據。 如果已添加節點，則數據將被移動到新節點，因此需要清理才能刪除移動的數據。 * 可以通過框架配置多數據中心復制。 * 多數據中心支持 * 在每個數據中心中獨立安裝 Mesos。 * 在每個數據中心中設置框架的獨立實例。 * 框架互相交談并定期交換種子。 * 這就是 Cassandra 所需要的。 通過引導其他數據中心的種子，節點可以八卦拓撲并找出節點是什么。 * 數據中心之間的往返 ping 延遲為 77.8 ms。 * P50 的異步復制延遲：44.69 毫秒； P95：46.38ms; P99：47.44 毫秒； * 計劃程序執行 * 調度程序的執行被抽象為計劃，階段和塊。 調度計劃具有不同的階段，一個階段具有多個塊。 * 調度程序啟動時要經過的第一階段是協調。 它將發送給 Mesos 并找出已經在運行的內容。 * 有一個部署階段，檢查集群中是否已存在配置中的節點數，并在必要時進行部署。 * 塊似乎是 Cassandra 節點規范。 * 還有其他階段：備份，還原，清理和修復，具體取決于命中的 REST 端點。 * 集群可以每分鐘一個新節點的速率啟動。 * 希望每個節點的啟動時間達到 30 /秒。 * 在 Cassandra 中不能同時啟動多個節點。 * 通常給每個 Mesos 節點 2TB 的磁盤空間和 128GB 的 RAM。 每個容器分配 100GB，每個 Cassandra 進程分配 32GB 堆。 （注意：目前尚不清楚，因此可能有錯誤的細節） * 使用 G1 垃圾收集器代替 CMS，它具有更好的 99.9％延遲（16x）和性能，無需任何調整。 ## 裸機 vs Mesos 托管群集 * 使用容器的性能開銷是多少？ 裸機意味著 Cassandra 不在容器中運行。 * 讀取延遲。 幾乎沒有什么區別：5-10％的開銷。 * 在裸機上平均為 0.38 ms，而在 Mesos 上為.44 ms。 * 在 P99 上，裸機為.91 毫秒，在 Mesos 上，P99 為.98 毫秒。 * 讀取吞吐量。 差別很小。 * 寫入延遲。 * 在裸機上平均為 0.43 ms，而在 Mesos 上為.48 ms。 * 在 P99 上，裸機為 1.05 毫秒，在 Mesos 上，P99 為 1.26 毫秒。 * 寫入吞吐量。 差別很小。 ## 相關文章 * [關于 HackerNews](https://news.ycombinator.com/item?id=12600298) * [使用 Borg 在 Google 進行大規模集群管理](http://research.google.com/pubs/pub43438.html) * [Google 的三個時代-批處理，倉庫，即時](http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html) * [Google 延遲容忍系統：將不可預測的部分做成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) * [Google：馴服長時間延遲的尾巴-當更多機器等于更差的結果時](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) * [Google 從單一數據中心到故障轉移再到本地多宿主體系結構的過渡](http://highscalability.com/blog/2016/2/23/googles-transition-from-single-datacenter-to-failover-to-a-n.html) * [Uber 如何擴展其實時市場平臺](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) * [Uber 變得與眾不同：使用駕駛員電話作為備份數據中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) * [為在現代時代構建可擴展的有狀態服務提供依據](http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html) * [我也想運行有狀態容器](https://techcrunch.com/2015/11/21/i-want-to-run-stateful-containers-too/) * [Uber 工程技術堆棧，第一部分：基礎](https://eng.uber.com/tech-stack-part-one/) * [Uber，Twitter，PayPal 和 Hubspot 使用 Apache Mesos 的 4 種獨特方式](https://www.linux.com/news/4-unique-ways-uber-twitter-paypal-and-hubspot-use-apache-mesos) 鏈接到代碼：https://github.com/mesosphere/dcos-cassandra-service 順便說一句，在文章中有一個鏈接。 有趣。 我想知道他們如何處理每秒 1M 個事件的日志記錄。 我認為 ELK 不能跟上步伐。 @bob。 Uber 確實使用 ELK 進行記錄。 它具有最大的 ELK 日志搜索安裝之一。 我想知道他們是否正在使用 Mesos 卷進行持久數據存儲。 是的，我們正在使用持久卷（https://mesos.apache.org/documentation/latest/persistent-volume/）進行數據存儲。 你好 您能否闡明查詢的性質？ 聚合或聯接或基于緯度的查詢？ 是否想知道 solr 是否可以根據您的用例進行選擇？ > >有趣。 我想知道他們如何處理每秒 1M 個事件的日志記錄。 如今，許多人用來實現此目的的模式是使用 kafka 日志記錄庫，該庫掛接到其微服務中，并使用 spark 等將來自 Kafka 的日志消耗到 elasticsearch 中。 我們在一個很小的?8 節點 ES 集群上每秒處理數十萬個事件。 -SRE @ Orchard 平臺 您能否分享 DC 之間的延遲時間？ Uber 使用 DC / OS 很有意思，但選擇使用 Aurora 而非馬拉松。 我上次查看極光時（大約 18 到 24 個月前），它的發展程度不及馬拉松。 我想知道何時做出決定？ Aurora 文檔得到了很大的改進。 很棒的帖子！ 使用 Mesos 代替 Hadoop YARN 是否有任何特殊原因？ Mesos 是否更適合您的需求？ YARN 只能運行 Hadoop 工作負載 Mesos 允許您運行任何類型的工作負載。 謝謝您，先生，非常有信息。 Mesos 可以在沒有 docker 容器安裝 Cassandra 的情況下運行嗎？ 我們可以使用 Mesos 默認容器安裝 cassandra 嗎？ 很棒的翔實文章。 做得好！ 怎么可能有 100 萬次寫入但每秒 10 萬次讀取？ 支持多于讀比寫有意義嗎？