加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

一文详解:如何设计出高可用的分布式架构?

发布时间:2018-08-14 11:28:51 所属栏目:教程 来源:佚名
导读:【资讯】本文作者将与大家分享目前主流的分布式架构、分布式架构中常见理论以及如何才能设计出高可用的分布式架构。 在分布式架构中,SOA 和微服务架构是最常见的两种分布式架构,而且目前服务网格的概念也越来越火了,我们就先从这些常见的架构开始。 SOA

  但客户端 B 无法立即读取到 V 的最新值,而需要在一段时间之后才能读取到。这再正常不过了,因为数据库复制之间是存在延时的。

  一文详解:如何设计出高可用的分布式架构?

  所谓分布式一致性的问题,就是指在分布式环境中引入数据复制机制后,不同数据节点之间可能会出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。

  简单来说, 数据一致性就是指在对一个副本数据进行变更的时候,必须确保也能够更新其他的副本,否则不同副本之间的数据将出现不一致。

  那么如何去解决这个问题呢?按照正常的思路,我们可能会想到既然是网络延迟导致的问题,那么我们就把同步动作进行阻塞,用户 2 在查询的时候必须要等数据同步完成以后再来做。

  但这个方案会非常影响性能。如果同步的数据比较多或比较频繁,那么阻塞操作可能会导致整个新系统不可用。

  故我们没有办法找到一种既能够满足数据一致性、 又不影响系统性能的方案,所以就诞生了一个一致性的级别:

  强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入的是什么,读出来的也要是什么,用户体验好,但实现起来往往对系统的性能影响较大。

  弱一致性:这种一致性级别约束了系统在写入成功后, 不保证立即可以读到写入的值,也不保证多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(如秒级别)后,数据能够达到一致状态。

  最终一致性:最终一致性其实是弱一致性的一个特例,系统会保证在一定时间内,能够达到数据一致的状态。

  这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。

  CAP 理论

  CAP 理论是一个经典的分布式系统理论。它告诉我们:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求,最多只能同时满足其中两项。

  CAP 理论在互联网界有着广泛的知名度,也被称为“帽子理论”,它是由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的一个著名猜想。

  一致性(Consistency)、可用性(Availability)、分区容错 (Partition-tolerance)三者无法在分布式系统中被同时满足,并且最多只能满足两个:

  一致性:所有节点上的数据时刻保持同步。

  可用性:每个请求都能接收一个响应,无论响应成功或失败。

  分区容错:系统应该持续提供服务,即使系统内部(某个节点分区)有消息丢失。

  比如交换机失败、网址网络被分成几个子网,形成脑裂、服务器发生网络延迟或死机,导致某些 server 与集群中的其他机器失去联系。

  分区是导致分布式系统可靠性问题的固有特性,从本质上来看,CAP 理论的准确描述不应该是从 3 个特性中选取两个,所以我们只能被迫适应,根本没有选择权。

  CAP 并不是一个普适性原理和指导思想,它仅适用于原子读写的 NoSQL 场景中,并不适用于数据库系统。

  BASE 理论

  从前面的分析中我们知道:在分布式(数据库分片或分库存在的多个实例上)前提下,CAP 理论并不适合数据库事务。

  因为更新一些错误的数据而导致的失败,无论使用什么高可用方案都是徒劳的,因为数据发生了无法修正的错误。

  此外 XA 事务虽然保证了数据库在分布式系统下的 ACID (原子性、一致性、隔离性、持久性)特性,但同时也带来了一些性能方面的代价,对于并发和响应时间要求都比较高的电商平台来说,是很难接受的。

  eBay 尝试了另外一条完全不同的路,放宽了数据库事务的 ACID 要求,提出了一套名为 BASE 的新准则。

  BASE 全称为 Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写。相对于 CAP 来说,它大大降低了我们对系统的要求。

  Basically Available(基本可用)

  表示在分布式系统出现不可预知的故障时,允许瞬时部分可用性:

  比如我们在淘宝上搜索商品,正常情况下是在 0.5s 内返回查询结果,但是由于后端的系统故障导致查询响应时间变成了 2s。

  再比如数据库采用分片模式,100W 个用户数据分在 5 个数据库实例上,如果破坏了一个实例,那么可用性还有 80%,也就是 80% 的用户都可以登录,系统仍然可用。

  电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

  Soft-state(软状态)

  表示系统中的数据存在中间状态,并且这个中间状态的存在不会影响系统的整体可用性,也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时。

  比如订单状态,有一个待支付、支付中、支付成功、支付失败,那么支付中就是一个中间状态,这个中间状态在支付成功以后,在支付表中的状态同步给订单状态之前,中间会存在一个时间内的不一致。

  Eventually consistent(数据的最终一致性)

  表示的是所有数据副本在一段时间的同步后最终都能达到一个一致的状态,因此最终一致性的本质是要保证数据最终达到一致,而不需要实时保证系统数据的强一致。

  BASE 理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

  分布式架构下的高可用设计

  避免单点故障:

  负载均衡技术(failover/选址/硬件负载/ 软件负载/去中心化的软件负载(gossip(redis- cluster)))

  热备(Linux HA)

  多机房(同城灾备、异地灾备)

  应用的高可用性:

  故障监控(系统监控(CPU、内存)/链路监控/日志监控) 自动预警

  应用的容错设计、(服务降级、限流)自我保护能力

  数据量(数据分片、读写分离)

  分布式架构下的可伸缩设计:

  垂直伸缩

  提升硬件能力

  水平伸缩

  增加服务器

  加速静态内容访问速度的 CDN

  CDN 全称是 Content Delivery Network,中文释义是内容分发网络。

  CDN 的作用是把用户需要的内容分发到离用户最近的地方进行响应,这样用户能够快速获取所需要的内容。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读