Uber如何做到每秒100万次写入操作？在多个数据中心使用Mesos和Cassandra

如果贵公司是Uber，需要存储每30秒由司机和乘客应用程序发送出去的位置数据，该如何是好？要知道，有许多实时数据是需要实时使用的。

Uber的解决方案很全面。它构建了自己的系统，该系统在Mesos上运行Cassandra。这在Uber的软件工程师阿披谢克·弗玛（Abhishek Verma）的一次畅谈中都得到了解释，那次畅谈题为《Uber：多个数据中心环境下的Mesos上的Cassandra》（多张幻灯片，详见http://www.slideshare.net/DataStax/cassandra-on-mesos-across-multiple-datacenters-at-uber-abhishek-verma-c-summit-2016）。

这是不是贵公司也应采取的做法？这是读者在听阿披谢克的畅谈时会忖到的一个饶有意思的想法。

如今，开发人员要做出许多艰难的选择。我们该不该全身心地投入到云？哪一种云？成本是不是太过高昂？我们是否要担心厂商锁定？还是我们应该双管齐下，亲自搭建一种混合架构？还是说由于担心无法获得50%的毛利率，我们就应该完全自己搞？

Uber决定自行构建。或者确切地说，它决定通过结合两种功能非常强大的开源组件，组建一套自己的系统。需要的是让Cassandra和Mesos协同运行的一种方法，这就是Uber构建的方法。

对Uber来说，做出这个决定并不是太难。它财力很雄厚，拥有构建、维护和更新这种复杂系统所需的一流人才和资源。

由于Uber的目标是能够为任何地方准备出行的任何人确保99.99%的可用性，你在扩展到无限庞大的规模时，希望能够控制成本确实有其必要性。

但是你在听畅谈时，会认识到构建这种系统需要投入大量的精力。这果真是普通公司所能胜任的吗？不，胜任不了。如果你属于对云说不的那些人，希望每个人都在最基本的裸机上构建自己的代码，就要牢记这一点。

拿金钱换时间常常很划算。拿金钱换技能常常绝对必不可少。

考虑到Uber在可靠性方面的目标：在10000个请求中，只有1个请求可以失败，它就需要运行多个数据中心。由于事实证明Cassandra可以跨数据中心处理庞大的负载和工作，它成为数据库方面的选择合情合理。

如果你想确保任何地方的任何人都有可靠的出行，就需要高效地利用资源。这正是使用Mesos之类的数据中心操作系统背后的想法。通过在同样的机器统计多路复用服务，你需要的机器数量可以减少30%，这节省了资金。之所以选择Mesos，是因为当时Mesos是被证明唯一可处理数万个机器组成的庞大集群的产品，Uber需要这么大的集群。Uber采取的都是大手笔。

一些更令人关注的结果还有什么？

• 可以在容器里面运行有状态的服务。Uber发现，在裸机上运行Cassandra与在Mesos管理的容器里面运行Cassandra基本上没什么区别，开销只相差5%至10%。
• 性能很好：平均读取延迟是13毫秒，写入延迟是25毫秒，P99延迟看起来很短。
• 针对最大的集群，Uber能支持每秒100多万次写入和约10万次读取。
• 敏捷性比性能来得更重要。Uber构建的这种架构拥有所需的敏捷性。很容易在集群上构建和运行工作负载。

下面是我对那次畅谈的注释：

开始阶段

• 针对不同的服务，使用统计分区的机器。
• 50台机器可能专用于API，50台机器专用于存储，等等，它们并不互相重叠。

现阶段

• 想在Mesos上运行一切，包括Cassandra和Kafka之类有状态的服务。

• Mesos是数据中心操作系统，让你可以对数据中心进行编程，数据中心如同单一资源池。
• 当时，Mesos被证明可以在数万台机器上运行，这是Uber的要求之一，所以这就是为什么当初它选择了Mesos。如今，Kubernetes可能也行。
• Uber在MySQL上构建了自己的分片数据库，名为Schemaless（https://eng.uber.com/schemaless-part-one/）。其想法是，Cassandra和Schemaless将是Uber的两大数据存储方案。现有的Riak安装系统将迁移到Cassandra。

• 单单一台机器就能运行不同种类的服务。
• 同一机器上统计多路复用服务可以将需要的机器减少30%。这是在谷歌的Borg系统上进行的试验得出的结果。
• 比如说，如果一个服务使用许多CPU，它与使用许多存储或内存资源的另一个服务很相配，那么这两个服务就可以在同一台服务器上高效地运行。机器的利用率就会提高。
• Uber现在有约20个Cassandra集群，计划将来有100个集群。
• 敏捷性比性能来得更重要。需要能够管理这些集群，并且顺畅地执行在上面运行的不同服务。

• 为何在容器中运行Cassandra，而不是就在整个机器上运行？

• 你想要存储数百GB的数据，但又希望数据复制在多台机器上，而且跨数据中心复制。
• 你还想要不同的集群之间实现资源隔离和性能隔离。
• 很难在单一的共享集群中做到这一切。比如说，如果你构建了由1000个节点组成的Cassandra集群，它无法扩展，或者不同的集群之间会出现性能干扰。

生产环境

• 两个数据中心（东西海岸）约20个集群复制数据。
• 最初只有4个集群，包括中国，但是自从与滴滴合并以来，那些集群已被关闭。
• 两个数据中心有约300台机器。
• 最大的2个集群：每秒100多万次写入，每秒约10万次读取。

• 其中一个集群存储每30秒由司机和乘客应用程序发送出去的位置数据。

• 平均读取延迟是13毫秒，写入延迟是25毫秒。
• 主要使用LOCAL_QUORUM一致性级别（这意味着强一致性）。

Mesos背景知识介绍

• Mesos将CPU、内存和存储资源从机器抽取出来。
• 你不是着眼于单台机器，而是着眼于资源池，并针对资源池编程。
• 线性扩展性。可以在数万台机器上运行。
• 高可用性。Zookeeper用于数量可配置的副本当中的主节点选举（leader election）。
• 可以启动Docker容器或Mesos容器。
• 可插式资源隔离。面向Linux的Cgroups内存和CPU隔离器。有一个Posix隔离器。还有面向不同操作系统的隔离机制。
• 两级调度程序。来自Mesos代理的资源提供给不同的框架。框架针对提供的这些资源，调度各自的任务。

Apache Cassandra背景知识介绍

• Cassandra很适合Uber的使用场合。
• 可横向扩展。新节点添加后，读取和写入可线性扩展。
• 高可用性。具有容错性，并拥有可调整的一致性级别。
• 低延迟。可在同一数据中心里面获得亚毫秒级延迟。
• 操作简单。这是一种同构集群。没有主节点。集群中没有特殊节点。
• 足够丰富的数据模型。它有列、组合键、计数器、辅助索引等。
• 与开源软件很好地整合起来。Hadoop、Spark和Hive都拥有可与Cassandra对话的连接件。

Mesosphere + Uber + Cassandra = Dcos-Cassandra-Service

• Uber使用Mesosphere来生成mesosphere/dcos-cassandra-service，这种自动化服务让用户很容易在Mesosphere DC/OS上进行部署和管理。

• 最上面的是Web Interface或控制平面API。你可以指定想要多少个节点、想要多少CPU，指定一种Cassandra配置，然后提交给控制平面API。
• 使用Uber的部署系统，它可以在Aurora上启动，Aurora用于运行无状态的服务，它用于启动dcos-cassandra-service框架。
• 在例子中，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用到了种子节点概念，种子节点为加入集群的新节点启动广播进程（gossip process）。定制的种子提供者创建，以启动Cassandra节点，这让Cassandra节点得以自动部署到Mesos集群中。
• Cassandra集群中的节点数量可以使用REST请求来增加。它会启动额外节点，为它提供种子节点，并启动额外的Cassandra守护进程。
• 所有Cassandra配置参数都可以更改。
• 使用API，就可以更换死亡节点。
• 需要修复，以便跨副本同步数据。逐个节点地在主键区间上进行修复。这个方法并不影响性能。
• 清理可清除不需要的数据。如果节点已添加，那么数据将迁移到新节点上，所以需要清理来删除已迁移的数据。
• 多数据中心复制可通过框架来配置。

• 支持多数据中心

• 可在每个数据中心独立安装Mesos。
• 可在每个数据中心独立安装框架的实例。
• 框架可以彼此对话，并定期交换种子。
• 这就是Cassandra所需的一切。通过启动其他数据中心的种子，节点就能广播拓扑结构，并搞清楚有什么节点。
• 数据中心之间的往返ping延迟是77.8毫秒。
• 异步复制延迟： P50是44.69毫秒，P95是46.38毫秒，P99是47.44毫秒。

• 调度程序的执行

• 调度程序的执行被抽象成计划、阶段和block。调度计划有不同的阶段，而阶段又有多个block。
• 调度程序在打开后经历的第一个阶段是调和。它会查询Mesos，搞清楚已经在运行的对象。
• 有一个部署阶段，检查配置中的节点数量是不是已经存在于集群中，必要的话部署节点。
• block似乎是Cassandra节点的一个规格。
• 有其他阶段：备份、恢复、清理和修复，这取决于遇到的是哪些REST端点。

• 能够以每分钟一个新节点的速度启动集群

• 启动速度时间想要达到每个节点30秒。
• 多个节点无法在Cassandra中同时启动。
• 通常为每个Mesos节点提供2TB的磁盘空间和128GB内存。100GB被分配给每个容器，32GB栈区被分配给每个Cassandra进程（注意：这不是很明确，所以细节方面可能有误）。
• 使用G1垃圾回收器，而不是CMS；未经任何调整，它就拥有好得多的99.9th percentile延迟和性能。

• 裸机vs Mesos托管集群
• 使用容器有什么样的性能开销？裸机意味着Cassandra不是在容器中运行。
• 读取延迟。几乎没什么区别：开销相差5%至10%。

• 在裸机上，平均延迟是.38毫秒，而在Mesos上平均延迟是.44毫秒。
• 裸机的P99延迟是.91毫秒，在Mesos上，P99延迟是.98毫秒。

• 读取吞吐量：差异非常小。
• 写入延迟

• 在裸机上，平均延迟是.43毫秒，而在Mesos上，平均延迟是.48毫秒。
• 裸机的P99延迟是1.05毫秒，而在Mesos上，P99延迟是1.26毫秒。

• 读取吞吐量：差异非常小。

原文来自:云疯报

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com