微信公众号商城网站开发,湖南省新闻最新消息十条,如何建立网络平台,开发者是什么意思对于开发或设计分布式系统的架构师、工程师来说#xff0c;CAP 是必须要掌握的基础理论#xff0c;CAP 理论可以帮助架构师对系统设计中目标进行取舍#xff0c;合理地规划系统拆分的维度。下面我们先讲讲分布式系统的特点。
分布式系统的特点
随着移动互联网的快速发展CAP 是必须要掌握的基础理论CAP 理论可以帮助架构师对系统设计中目标进行取舍合理地规划系统拆分的维度。下面我们先讲讲分布式系统的特点。
分布式系统的特点
随着移动互联网的快速发展互联网的用户数量越来越多产生的数据规模也越来越大对应用系统提出了更高的要求我们的系统必须支持高并发访问和海量数据处理。 分布式系统技术就是用来解决集中式架构的性能瓶颈问题来适应快速发展的业务规模一般来说分布式系统是建立在网络之上的硬件或者软件系统彼此之间通过消息等方式进行通信和协调。 分布式系统的核心是可扩展性通过对服务、存储的扩展来提高系统的处理能力通过对多台服务器协同工作来完成单台服务器无法处理的任务尤其是高并发或者大数据量的任务。 除了对可扩展性的需求分布式系统还有不出现单点故障、服务或者存储无状态等特点。 单点故障Single Point Failure是指在系统中某个组件一旦失效这会让整个系统无法工作而不出现单点故障单点不影响整体就是分布式系统的设计目标之一 无状态是因为无状态的服务才能满足部分机器宕机不影响全部可以随时进行扩展的需求。 由于分布式系统的特点在分布式环境中更容易出现问题比如节点之间通信失败、网络分区故障、多个副本的数据不一致等为了更好地在分布式系统下进行开发学者们提出了一系列的理论其中具有代表性的就是 CAP 理论。
CAP 代表什么含义
CAP 理论可以表述为一个分布式系统最多只能同时满足一致性Consistency、可用性Availability和分区容忍性Partition Tolerance这三项中的两项。 一致性是指“所有节点同时看到相同的数据”即更新操作成功并返回客户端完成后所有节点在同一时间的数据完全一致等同于所有节点拥有数据的最新版本。
可用性是指“任何时候读写都是成功的”即服务一直可用而且是正常响应时间。我们平时会看到一些 IT 公司的对外宣传比如系统稳定性已经做到 3 个 9、4 个 9即 99.9%、99.99%这里的 N 个 9 就是对可用性的一个描述叫做 SLA即服务水平协议。比如我们说月度 99.95% 的 SLA则意味着每个月服务出现故障的时间只能占总时间的 0.05%如果这个月是 30 天那么就是 21.6 分钟。
分区容忍性具体是指“当部分节点出现消息丢失或者分区故障的时候分布式系统仍然能够继续运行”即系统容忍网络出现分区并且在遇到某节点或网络分区之间网络不可达的情况下仍然能够对外提供满足一致性和可用性的服务。 在分布式系统中由于系统的各层拆分P 是确定的CAP 的应用模型就是 CP 架构和 AP 架构。分布式系统所关注的就是在 Partition Tolerance 的前提下如何实现更好的 A 和更稳定的 C。
CAP 理论的证明
CAP 理论的证明有多种方式通过反证的方式是最直观的。反证法来证明 CAP 定理最早是由 Lynch 提出的通过一个实际场景如果 CAP 三者可同时满足由于允许 P 的存在则一定存在 Server 之间的丢包如此则不能保证 C。 首先构造一个单机系统如上图Client A 可以发送指令到 Server 并且设置更新 X 的值Client 1 从 Server 读取该值在单点情况下即没有网络分区的情况下通过简单的事务机制可以保证 Client 1 读到的始终是最新值不存在一致性的问题。 我们在系统中增加一组节点因为允许分区容错Write 操作可能在 Server 1 上成功在 Server 2 上失败这时候对于 Client 1 和 Client 2就会读取到不一致的值出现不一致的情况。如果要保持 X 值的一致性Write 操作必须同时失败 也就是降低系统的可用性。 可以看到在分布式系统中无法同时满足 CAP 定律中的“一致性”“可用性”和“分区容错性”三者。 在该证明中对 CAP 的定义进行了更明确的声明 Consistency一致性被称为原子对象任何的读写都应该看起来是“原子”的或串行的写后面的读一定能读到前面写的内容所有的读写请求都好像被全局排序 Availability对任何非失败节点都应该在有限时间内给出请求的回应请求的可终止性 Partition Tolerance允许节点之间丢失任意多的消息当网络分区发生时节点之间的消息可能会完全丢失。
CAP 理论的应用
CAP 理论提醒我们在架构设计中不要把精力浪费在如何设计能满足三者的完美分布式系统上而要合理进行取舍CAP 理论类似数学上的不可能三角只能三者选其二不能全部获得。 不同业务对于一致性的要求是不同的。举个例来讲在微博上发表评论和点赞用户对不一致是不敏感的可以容忍相对较长时间的不一致只要做好本地的交互并不会影响用户体验而我们在电商购物时产品价格数据则是要求强一致性的如果商家更改价格不能实时生效则会对交易成功率有非常大的影响。 需要注意的是CAP 理论中是忽略网络延迟的也就是当事务提交时节点间的数据复制一定是需要花费时间的。即使是同一个机房从节点 A 复制到节点 B由于现实中网络不是实时的所以总会有一定的时间不一致。
CP 和 AP 架构的取舍
在通常的分布式系统中为了保证数据的高可用通常会将数据保留多个副本Replica网络分区是既成的现实于是只能在可用性和一致性两者间做出选择。CAP 理论关注的是在绝对情况下在工程上可用性和一致性并不是完全对立的我们关注的往往是如何在保持相对一致性的前提下提高系统的可用性。 业务上对一致性的要求会直接反映在系统设计中典型的就是 CP 和 AP 结构。 CP 架构对于 CP 来说放弃可用性追求一致性和分区容错性。
我们熟悉的 ZooKeeper就是采用了 CP 一致性ZooKeeper 是一个分布式的服务框架主要用来解决分布式集群中应用系统的协调和一致性问题。其核心算法是 Zab所有设计都是为了一致性。在 CAP 模型中ZooKeeper 是 CP这意味着面对网络分区时为了保持一致性它是不可用的。关于 Zab 协议将会在后面的 ZooKeeper 课时中介绍。 AP 架构对于 AP 来说放弃强一致性追求分区容错性和可用性这是很多分布式系统设计时的选择后面的 Base 也是根据 AP 来扩展的。
和 ZooKeeper 相对的是 EurekaEureka 是 Spring Cloud 微服务技术栈中的服务发现组件Eureka 的各个节点都是平等的几个节点挂掉不影响正常节点的工作剩余的节点依然可以提供注册和查询服务只要有一台 Eureka 还在就能保证注册服务可用只不过查到的信息可能不是最新的版本不保证一致性。
