`
javafan_303
  • 浏览: 957700 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

Uber容错设计与多机房容灾方案

 
阅读更多

此文是根据赵磊在【QCON高可用架构群】中的分享内容整理而成。

赵磊,Uber高级工程师,08年上海交通大学毕业,曾就职于微软,后加入Facebook主要负责Messenger的后端消息服务。这个系统在当时支持Facebook全球5亿人同时在线。目前在Uber负责消息系统的构建并推进核心服务在高可用性方向的发展。

前言

赵磊在7月21号的全球架构师峰会深圳站上,做了主题演讲:Uber高可用消息系统构建,对于这个热门主题,高可用架构群展开了热议,大家对分布式系统中的各种错误处理非常感兴趣。Tim Yang特邀赵磊通过微信群,在大洋彼岸的硅谷给大家进一步分享。

分布式系统单点故障怎么办

non-sharded, stateless 类型服务非常容易解决单点故障。 通常load balancer可以按照固定的时间间隔,去health check每个node, 当某一个node出现故障时,load balancer可以把故障的node从pool中排除。

很多服务的health check设计成简单的TCP connect, 或者用HTTP GET的方式,去ping一个特定的endpoint。当业务逻辑比较复杂时,可能业务endpoint故障,但是health endpoint还能正常返回,导致load balancer无法发现单点故障,这种情况可以考虑在health check endpoint中增加简单的业务逻辑判断。

对于短时间的network故障,可能会导致这段时间很多RPC call failures。 在RPC client端通常会实现backoff retry。 failure可能有几种原因:

  1. TCP connect fail,这种情况下retry不会影响业务逻辑,因为Handler还没有执行。

  2. receive timeout, client无法确定handler是不是已经收到了request 而且处理了request,如果handler重复执行会产生side effect,比如database write或者访问其他的service, client retry可能会影响业务逻辑。

对于sharded service,关键是如何找到故障点,而且将更新的membership同步到所有的nodes。下面讨论几种sharding的方案:

  1. 将key space hash到很多个小的shard space, 比如4K个shards。 通过zookeeper (distributed mutex) 选出一个master,来将shard分配到node上,而且health check每一个node。当遇到单点故障时,将已经assigned的shards转移到其他的nodes上。 因为全局只有一个single master, 从而保证了shard map的全局一致。当master故障时,其他的backup node会获得lock成为Master

  2. Consistent hashing方式。consistent hashing 通常用来实现cache cluster,不保证一致性。 因为每个client会独立health check每一个node, 同时更新局部的membership。 在network partition的情况或者某一个node不停的重启, 很可能不同的client上的membership不一致,从而将相同的key写在了不同的node上。 当一致性的需求提高时,需要collaborative health check, 即每个node要monitor所有其他node的health。 Uber在这里使用的是gossip protocol,node之间交换health check的信息。

大面积故障怎么办

大面积故障时,比如交换机故障(rack switch failure),可用的机器不足以处理所有的请求。 我们尽可能做的就是用50%的capacity 处理50%的请求或者50%用户的所有请求。而尽量避免整个服务故障。 当设计一个服务的时候,它的throughput应该是可linear scale的。

  1. 在同样的CPU占用情况下,1个机器应该处理100个请求,那么5个机器应该可以处理500个请求。

  2. 而且在同样的机器数量下,20%的CPU可以处理200个请求,那么60%的CPU应该可以处理3倍即600个请求。

后者是很难实现的,而且当CPU越高的时候,服务的throughput并不是线性的。 通常在80%CPU以上的情况,throughput会下降非常快。 随着CPU使用增加,request的latency也会提高。 这对上下游的服务可能都是一个挑战,可能会导致cascade failure。

对于nodejs或者java nio一类的async IO框架来说,另外一个问题就是event loop lag。 这两者可能导致connection数量增加。下面举两个例子

  1. 有些RPC transport支持pipelining但不支持multiplexing (out of order responses), pipelining是指在同一个TCP连接上可以连续发出Req1, Req2, Req3, Response1, Response2, Response3,即Response的顺序必须和Request的顺序是一致。Req1如果需要很长时间,Req2和3就都不能返回。一个Request如果占用太长时间,会导致后面的很多个Request timeout。RPC client通常也会限制在一个TCP connection上面的max pending requests。但timeout发生,或者max pending requests情况下,client会主动创建新的connection。

  2. event loop lag 是指程序占用太长时间执行连续的CPU intensive任务。 只有当任务结束时,event loop才会handle IO events,比如从socket上面读数据。否则收到的数据只能保存在kernel 的TCP buffer里,通常这个buffer size小于64KB。当buffer满时(而且service又很长时间没有读buffer),socket的远端就不能发送更多的数据。这时也会导致远端的transport error。同样的,client会主动创建新的connection,当connection增加到预设的fd limit时,service就不能继续accept新的TCP connection了,其实是不能open新的文件了。而且,绝大部分的程序没有测试过达到fd limit的场景。很多API需要open file, 比如logging和core dump. 所以,一旦达到fd limit, 就像out of memory一样,将很难recover,只能crash process. 而这时正是过载的时候,重启实际上减少了capacity。 任何crash在过载的情况下只会更糟。facebook在这防止过载上做的很好,在C++实现的thrift server上,有一个或者多个threads只负责accept TCP connections. 你可以指定最多的connections for thrift calls。 这个connection limit是远小于fd limit, 当connection太多时,thrift server可以fail fast。所以,这种情况下可以让service能一直保持在max qps。

整个数据中心挂掉怎么办

在Uber的场景中,如果rider已经在一个trip上了,我们通产会等trip结束后才把rider迁移到其他的数据中心,我们叫做soft failover。否则需要hard failover,我们会把DNS指向其他的数据中心。 而且用户的DNS服务器很可能在一段时间内还是cache以前的ip,而且这个cache的时间是基本没办法控制的,所以我们会在load balancer上返回HTTP redirect,这样手机的客户端收到后会立即转向新的备份数据中心。

惊群问题(thundering herd), 很多服务在provision的时候根据平常的QPS预留了很少的容量空间,当数据中心或者load balancer重启的时候,如果所有的客户端同时发起请求,这时的QPS可以是平时的很多倍。 很可能导致大部分请求都失败。一方面需要在客户端实现exponential backoff, 即请求失败后retry的间隔时间是增长的,比如1秒,5秒,20秒等等。另外在load balancer上实现rate limiting或者global blackhole switch, 后者可以有效的丢掉一部分请求而避免过载,同时尽早触发客户端的backoff逻辑。

如果大家用AWS或者其他云服务的话,AWS的一个region通常包括几个数据中心。各个数据中心甚至在相邻的介个城市,有独立的空调系统和供电。

数据中心之间有独立的网络 high throughput low latency, 但是在region之间的网络通常是共有的 high throughput high lantecy

整个region挂掉很少发生。可以把服务部署在多个可用区(Availability Zone)来保证高可用性。

Q & A

Q1:health check endpoint中实现简单的业务逻辑,这个意思是load balancer中有业务逻辑检查的插件么?这样load balancer会不会很重啊,可以详细说一下么?

load balancer仍然是HTTP GET, health check 没有额外的开销,但是服务本身处理health的方式不同,可加入业务逻辑相关的检查 比如是不是能够访问数据库。

Q2:region切换时,用户的数据是怎么迁移的?

这个是个很好的问题,Uber采取的是个非常特别的方法。 realtime系统会在每次用户state change。state change的时候把新的state下载到手机上,而且是加密的。当用户需要迁移到新的数据中心的时候,手机需要上传之前下载的state,服务就可以从之前的state开始,但是non-realtime系统 比如用户数据是通过sql replication来同步的。是Master-master。而且Uber在上层有个数据抽象,数据是基本上immutable的 append-only 所以基本不存在冲突。

Q3:如果是req timeout,但另外一边已经执行成功了,这时候重试,那不就是产生了两次数据?特别是insert这种类型的。

是的,如果是GET类型的请求可以retry, 但是POST类型的请求 那么只能在conn timeout时可以安全的retry。 但是receive timeout不能重试。(Tim补充看法:对于POST请求,如果service实现了幂等操作也是可以retry)。 有些类型的数据可以自动merge比如set和map

Q4:那receive timeout,这种情况下,只能通过merge或者冲突对比解决?

恩 是的。 需要在逻辑层判断是不是能够retry。 这个我建议在更上层实现, 比如在消息系统中,全程不retry 就可以保证at most once delivery, 如果需要保证at least once delivery 需要加入数据库和client dedupe

Q5:大面积故障时Uber用什么手段来控制只处理部分用户请求?

我们实现了一些rate limiting 和 circuit breaking的库,但是这时针对所有请求的。 我们现在还没有做到只处理某些用户的请求。

Q6:“将key space hash到相对小的shard space, 因为全局只有一个single master, 从而保证了shard map的全局一致” 这个方案每次计算shard node的时候,必须先询问下master么?

是的。 在client端有一个shard map的cache, 每隔几秒钟可以refresh, 如果是复杂的实现,则可以是master 推送shardmap change。

Q7:多个机房的数据是sharding存储(就是每个机房只存储一部分用户数据),还是所有机房都有所有用户全量数据?

Uber现在的做法是每个机房有所有用户的数据。 facebook的做法是一个机房有一部分用户的数据。

Q10:Uber的消息系统是基于nodejs的吗?客户端长链接的性能和效率方面如何优化?

是基于nodejs的。我们没有特别优化性能,不过stress test看起来2个物理机可以保持800K连接

Q11:Uber消息系统协议自己DIY吗? 是否基于TLS? PUSH消息QPS能达到多少?

是的,基于HTTPS。 具体QPS我不太记得了。

Q12:riak的性能如何?主要存储哪些类型的数据呢?存储引擎用什么?raik的二级索引有没有用到呢?

riak性能我没测试过,跟数据类型和consistency level都有关系。 可能差别比较大。 我们现在用的好像是leveldb

Q13:应用层实现多机房数据一致的话,是同时多写吗? 这个latency会不会太长?

sql现在都是用在non-realtime系统里面,所以latency可能会比较长

Q14:Uber rpc用的什么框架,上面提到了Thrift有好的fail fast策略,Uber有没有在rpc框架层面进行fail fast设计?

Uber在RPC方面还刚开始。 我们一直是用http+json的,最近在朝tchannel+thrift发展, tchannel是一个类似http2.0的transport,tchannel 在github上能找到。我们的nodejs thrift 是自己实现的,因为apache thrift在node上做的不是很好,thrift的实现叫做thriftify https://github.com/Uber/thriftify正好推荐下我的开源项目哈。 在thrift server上我们没有做fail fast, 如何保护是在routing service中实现的。

Q15:Uber走https协议,有没有考虑spdy/http2.0之类的呢?在中国网速状况不是很好的,Uber有没有一些https连接方面的优化措施?

正在考虑迁移到HTTP2.0,这个主要是手机端有没有相应的client实现。 server端我们用的是nginx,nginx上有个experiemnt quality的extension可以支持spdy。 我们还考虑过用facebook的proxygen https://github.com/facebook/proxygen,proxygen支持spdy。 我在facebook的chat service是用proxygen实现的,而且facebook 几十万台PHP server都在proxygen上,所以可以说是工业级强度的基础设施,不过build起来要花点时间。

Q16:为了避免服务过载和cascade failure,除了在服务链的前端采用一些fail fast 的设计,还有没有其它的实践作法,比如还是想支持一部分用户或特定类型的请求,采用优先级队列等。 就这个问题,Uber,facebook在服务化系统中还有没有其它技术实践?另外出现大规模服务过载后的恢复流程方面,有没有碰到什么坑或建议?

“比如还是想支持一部分用户或特定类型的请求” 这个其实比较难实现 因为当服务过载的时候 在acceptor thread就停止接受新的connection了,那就不知道是哪个用户的请求 。这个需要在应】用层实现,比如feature flag可以针对一些用户关掉一些feature。 我发现有个很有用的东西就是facebook有个global kill switch,可以允许x%的流量,这个当所有service一起crash 重启的时候比较有用。

 

此文是根据赵磊在【QCON高可用架构群】中的分享内容整理而成。

 

分享到:
评论

相关推荐

    Uber平台架构设计介绍.docx

    Uber平台架构设计是一个复杂而巧妙的过程,旨在提供稳定、高效且可扩展的打车服务。最初,Uber的架构非常简洁,由手机应用、PHP业务逻辑和MySQL数据库组成。司机的位置信息每隔4秒更新,当用户请求时,PHP通过MySQL...

    优步 Uber APP 视觉设计规范手册(2016年版).pdf

    优步(Uber)是全球知名的共享出行平台,其在2016年发布的APP视觉设计规范手册对于开发者和设计师来说是一份重要的参考资料。本手册详细规定了如何在应用程序内(in-app)集成Uber服务时,遵循其品牌设计原则,以...

    【77】 2017年最新Uber车辆监控系统设计实战训练营高清视频教程全套附讲义代码 .txt

    根据给定文件的信息,我们可以提炼出的关键知识点主要围绕2017年Uber车辆监控系统的设计与实战训练。以下是对该主题进行的详细解读与扩展: ### Uber车辆监控系统概述 Uber车辆监控系统是一种用于实时追踪、监控并...

    Uber提出有创造力的POET:自行开发更困难环境和解决方案.docx

    标题中的“Uber提出有创造力的POET:自行开发更困难环境和解决方案”指的是Uber AI实验室提出的一种名为POET(Paired Open-Ended Trailblazer)的技术方案,它是一种开放式的方法,旨在自动创建越来越复杂的环境并...

    flink-shaded-hadoop-2-uber-2.7.5-10.0.jar.zip

    《Flink Shaded Hadoop 2 Uber Jar:深入解析与应用》 Apache Flink 是一个流行的开源大数据处理框架,而 `flink-shaded-hadoop-2-uber-2.7.5-10.0.jar.zip` 文件是针对 Flink 优化的一个特殊版本的 Hadoop 库。这...

    Android 仿Uber引导页

    本项目"Android 仿Uber引导页"旨在实现与Uber iOS版本相同的引导页效果,为开发者提供一个快速集成此类功能的解决方案。 首先,我们来了解一下如何在Android中构建这样的引导页。引导页通常由多个ImageView或自定义...

    Uber的欢迎界面

    《Uber欢迎界面设计与实现解析》 Uber,作为全球知名的出行服务平台,其用户界面设计一直备受业界关注。本文将深入探讨Uber的欢迎界面,也就是Android版的UberSplash,旨在揭示其设计背后的逻辑与技术实现。 首先...

    论文研究 - 折现现金流模型的Uber未来价值预测

    良好的估值可以在很多方面有所作为。 在本研究中,预测Uber估值的目的是获得Uber的未来自由现金流和股票价值,以便我们可以为Uber的未来发展战略提供信息,并提出可行的业务决策,然后提高Uber的未来价值。它。 ...

    hive-jdbc-uber-3.1.2+yanagishima-18.0

    《Hive JDBC Uber 3.1.2与Yanagishima:Kerberos环境下的即席查询解决方案》 在大数据处理领域,Apache Hive作为一款强大的数据仓库工具,被广泛用于存储、管理和分析大规模结构化数据。而Hive JDBC是连接Hive与...

    人工智能在Uber的外卖服务_Uber_Eats_中的应用.pdf

    **Uber Eats 人工智能概述** Uber Eats 是全球知名的在线外卖服务平台,由知名共享出行公司Uber推出。...随着AI技术的不断发展,我们可以期待Uber Eats在未来会有更多的创新和优化,进一步改善全球消费者的餐饮体验。

    Uber-ATG-Self-Driving-Safety-Report2018.pdf

    自2010年推出最初的Uber应用程序以来,公司已在全球超过65个国家的600多个城市提供服务,并且在某些地区还提供了自行车、滑板车以及与公共交通的无缝连接。这份信心驱使Uber在2015年成立了Advanced Technologies ...

    hive-jdbc-uber-2.6.5.0-292.zip

    《Hive JDBC Uber Jar:连接Hive与Java的桥梁》 在大数据处理领域,Hive作为基于Hadoop的数据仓库工具,被广泛用于大规模数据的离线分析。而Hive JDBC(Java Database Connectivity)则为Hive提供了一种标准的Java...

    Uber外卖平台国际化架构演化之路.pdf

    - 在国际化过程中,Uber Eats关注操作可靠性,例如采用主动-主动模式(Active-Active)在两个数据中心运行,通过三层缓解机制(DNS、数据中心和服务级别)提高容灾能力。 - 针对性能挑战,Uber Eats改进了存储系统...

    flink-shaded-hadoop-2-uber-2.6.5-10.0.zip

    5. **容错机制**:Flink的容错机制与Hadoop的检查点机制相结合,可以提供高可用性和数据一致性,尤其是在处理大规模数据时。 然而,需要注意的是,虽然Uber JAR简化了部署,但其体积较大,可能会增加网络传输的负担...

    Uber——Bring Consensus to Data Replication

    综上所述,Uber在其架构设计中深入探讨和实践了分布式系统的核心理论,解决了大规模数据复制中的一致性问题,通过采用复制状态机和共识协议维护了高可用性,并且在设计中采用了自动化来减少人为失误,最终实现了一个...

    Uber Go 语言编程规范 中文版.pdf

    在接口设计上,Uber规范建议谨慎使用接口,特别是考虑接口的接收者类型(receiver)。对于需要修改对象状态的方法,通常应使用指针接收者;而对于只读方法,可以使用值接收者。同时,避免使用无必要的Mutex,尽可能...

    Uber H3 封装

    **Uber H3封装** Uber H3 是一个开源的地理索引系统,由Uber开发并维护。这个库的主要目的是为了提供一种高效、空间连续且均匀的全球网格系统,它将地球表面划分为规则的六边形网格,使得数据的存储、查询和分析变...

    react-Base实现Base设计语言的React组件库uber公司开源

    4. **响应式设计**:React-Base支持响应式布局,适应不同设备和屏幕尺寸,确保应用在多平台上的良好表现。 5. **无障碍访问**:遵循Web无障碍(WCAG)标准,确保组件对特殊群体如视障用户的友好性。 6. **文档丰富...

    flink-shaded-hadoop-3-uber-3.1.1.7.1.1.0-565-9.0.jar.tar.gz

    "Uber jar"的主要作用是将多个jar包合并成一个,通过重命名或移除冲突的类,确保在运行时不会出现类装载异常。在这个特定的兼容包中,我们可以看到两个文件:flink-shaded-hadoop-3-uber-3.1.1.7.1.1.0-565-9.0.jar...

Global site tag (gtag.js) - Google Analytics