架构实战篇:认识一下ZooKeeper和CAP及一致性原则

懂点代码的大叔 2018-05-25 16:17:39 ⋅ 249 阅读

一、CAP理论概述

CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

  • 一致性(C:Consistency)

  • 可用性(A:Available)

  • 分区容错性(P:Partition Tolerance)

这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

一致性(C:Consistency)

在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进行了更新操作并且更新成功后,其他节点上的数据也应该得到更新,并且所有用户都可以读取到其最新的值,那么这样的系统就被认为具有强一致性(或严格的一致性,最终一致性)。

可用性(A:Available)

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有效的时间内”是指,对于用户的一个操作请求,系统必须能够在指定的时间(即响应时间)内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的

“返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。

分区容错性(P:Partition Tolerance)

分区容错性约束了一个分布式系统需要具有如下特性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障

网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络等)中,由于一些特殊的原因导致这些子网络之间出现网络不连通的状况,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是,组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

由于一个分布式系统无法同时满足上面的三个需求,而只能满足其中的两项,因此在进行对CAP定理的应用的时候,需要根据业务的要求抛弃其中的一项,下表所示是抛弃CAP定理中任意一项特性的场景说明。

因此,将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的,应该根据应用场景进行适当取舍。

二、一致性的分类

一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性的分类为如下几种:

强一致性:(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。

单调一致性:(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,可获取的数据顺序必是单调递增的。

会话一致性:(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值,会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。

最终一致性:(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。

弱一致性:(weak consistency)。用户无法在确定时间内读到最新更新的值。

三、ZooKeeper提供的一致性服务

ZooKeeper从以下几点保证了数据的一致性

顺序一致性来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说,如果一个客户端将Znode z的值更新为a,在之后的操作中,它又将z的值更新为b,则没有客户端能够在看到z的值是b之后再看到值a(如果没有其他对z的更新)。

原子性每个更新要么成功,要么失败。这意味着如果一个更新失败,则不会有客户端会看到这个更新的结果。

单一系统映像一个客户端无论连接到哪一台服务器,它看到的都是同样的系统视图。这意味着,如果一个客户端在同一个会话中连接到一台新的服务器,它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障,导致它的一个客户端需要尝试连接集合体中其他的服务器时,所有滞后于故障服务器的服务器都不会接受该 连接请求,除非这些服务器赶上故障服务器。

持久性一个更新一旦成功,其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

实时性:在特定的一段时间内,客户端看到的系统需要被保证是实时的(在十几秒的时间里)。在此时间段内,任何系统的改变将被客户端看到,或者被客户端侦测到。

四、用CAP理论来分析ZooKeeper

CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

  • 一致性(C:Consistency)

  • 可用性(A:Available)

  • 分区容错性(P:Partition Tolerance)

这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中

在此ZooKeeper保证的是CP

分析:可用性(A:Available)

不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

参考:https://www.cnblogs.com/xrq730/p/4944768.html

参考:https://blog.csdn.net/xiangxizhishi/article/details/78469027


关注我们

更多精彩内容请关注“IT实战联盟”公众号哦~~~


全部评论: 0

    我有话说:

    架构实战认识微服务架构

    微服务是一个新兴的软件架构,就是把一个大型的单个应用程序服务拆分为数十个的支持微服务。

    SpringBoot+zk+dubbo架构实践):本地部署zookeeper

    SpringBoot+zk+dubbo架构实践系列实现目标:自己动手搭建微服务架构

    微服务架构学习笔记():重新认识微服务

    微服务(Microservice)是服务化思路的种最佳实践方向,遵循SOA的思路,各个企业在服务化治理的道路上走的时间长了,踩的坑多了,整个软件交付链路上各个环节的基础设施逐渐成熟了,微服务

    SpringBoot+zk+dubbo架构实践(二):SpringBoot 集成 zookeeper

    不啰嗦,本完成两件事:1、搭建SpringBoot 框架;2、基于spring boot框架访问zookeeper

    架构实战:一个可供中小团队参考的微服务架构技术栈

    作者近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据我个人的一线实践经验我平时对Spring Cloud的调研,我认为Spring Cloud技术栈中的有些组件离生产级开发尚有

    Java Web架构实战:聊聊前后端分离架构

    RESTful思想Json数据标准的出现,使得这种交互日益便利。Vue.js 用于构建用户界面的渐进式框架

    架构实战(十):Spring Boot 集成企业级搜索引擎 SolrCloud

    Solr是以Lucene为基础实现的文本检索应用服务。Solr部署方式有单机方式、多机Master-Slaver方式、Cloud方式。

    架构实战(五):Spring Boot 表单验证异常处理

    为了让API 能够更好的提供服务,表单数据验证异常的处理是必不可少的,让我们来看看怎么处理......

    分钟认识服务网关zuul案例实操

    在微服务架构模式后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。

    精品推荐:微服务架构静态数据通用缓存机制

    在分布式系统中,特别是最近很火的微服务架构,有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案,这文章将结合一些实际的研发经验,尝试理清其中存在的关键问题以及探寻通用的解决之道。

    架构实战(三)-Spring Boot架构搭建RESTful API案例

    之前分享了Spring Boot 整合Swagger 让API可视化前后端分离架构 受到了大家一致好评 ,本节就接着上节的代码做了详细的查询代码的补充完善并搭建RESTful API架构案例。

    聊分布式场景redismemcached,各自经典使用场景优缺点

    在BAT里,redis已经逐渐取代了memcached,成为分布式场景广泛使用的缓存方案。接下来,我们就分析,redis是如何取代memcached,成为开发者的宠儿的。

    架构实战(十四):Spring Boot 多缓存实战

    多场景的不同缓存策略解决方案

    SpringBoot+zk+dubbo架构实践(三):部署Dubbo-admin管理平台

    本系列架构实践不做深入探讨,主旨是带领大家能够快速踏入微服务架构门槛,能够轻松的搭建套属于自己的微服务架构。——写代码我们是认真滴!

    Java Web实战:增强for循环实现原理for循环实战性能优化

    Iterator是工作在一个独立的线程中,并且拥有一个 mutex 锁。 Iterator被创建之后会建立一个指向原来对象的单链索引表......

    架构实战:MyBatis一级、二级,并整合ehcache分布式缓存的使用,附演示实例

    ehcache是一个纯Java的进程内缓存框架,是种广泛使用的开源Java分布式缓存,具有快速、精干等特点,是Hibernate中默认的CacheProvider。

    WeCube 2.7.1 发布,站式 IT 架构管理运维管理工具

    WeCube简介 微众银行在分布式架构实践的过程中,发现将银行核心系统构建于分布式架构之上,会遇到一些与传统单体应用不同的痛点(例如,服务器增多,部署难度大;调用链长,全链路跟踪困难; 系统复杂

    架构实战(四):Spring Boot整合 Thymeleaf

    Thymeleaf 是种模板语言。那模板语言或模板引擎是什么?

    架构实战(十三):Spring Boot Logback 邮件通知

    日志对于应用程序来说是非常重要的,当你的程序报错了,而你又不知道是多么可怕的件事情,本文使用logback把程序报错信息邮件到开发者