Uber如何做到每秒100万次写入操作?在多个数据中心使用Mesos和Cassandra
Posted 云头条
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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毫秒。
读取吞吐量:差异非常小。
云头条编译|未经授权谢绝转载
相关阅读:
以上是关于Uber如何做到每秒100万次写入操作?在多个数据中心使用Mesos和Cassandra的主要内容,如果未能解决你的问题,请参考以下文章
每秒上百万次的跨数据中心写操作?Uber是如何使用Mesos和Cassandra来处理的