way-to-architect
  • 前言
  • Java
    • Java关键字
      • Java中四种修饰符的限制范围
      • static和final
    • 容器
      • 容器概述
        • 容器:综述
        • Iterator原理及实现
        • fast-fail机制
        • 比较器Comparator
        • Collections工具类
      • List
        • List综述
        • ArrayList原理分析
        • ArrayList在循环过程中删除元素的问题
        • 常用的小技巧
        • CopyOnWrite
      • Set
        • Set综述
        • HashSet
        • LinkedHashSet
        • TreeSet
      • Queue
        • Queue综述
        • ArrayBlockingQueue实现原理
        • LinkedBlockingQueue实现原理
        • 高性能无锁队列Disruptor
      • Map
        • Map综述
        • HashMap
          • HashMap实现原理
          • HashMap中的位运算
          • HashMap其他问题
        • LinkedHashMap
        • TreeMap
        • ConcurrentHashMap
          • ConcurrentHashMap实现原理JDK1.7
          • ConcurrentHashMap实现原理JDK1.8
        • ConcurrentSkipListMap
        • Map中key和value的null的问题
    • 线程
      • 线程
        • 创建线程
        • 线程状态及切换
        • 线程中断的理解
        • 几种方法的解释
        • 用户线程与守护线程
        • 线程组ThreadGroup
      • 线程池
        • 线程池工作原理及创建
        • Executor
        • 如何确保同一属性的任务被同一线程执行
      • ThreadLocal
        • ThreadLocal原理
        • ThreadLocal之父子线程传值
        • InheritableThreadLocal
      • 同步与锁
        • 线程安全与锁优化
        • synchronize关键字
        • Lock
          • 队列同步器
            • 同步状态的获取与释放
            • 使用方式
            • 示例:Mutex
            • 示例:TwinsLock
          • 重入锁和读写锁
          • LockSupport
          • Condition
          • 并发工具类
        • CAS
          • CAS的理解
          • Java中原子操作类
        • 3个经典同步问题
      • fork/join的理解
    • I/O
      • I/O概述
        • 磁盘I/O与网络I/O
        • 主要接口
        • 输入流和输出流的使用示例
        • InputStream的重复读
        • BufferdxxxxStream
        • Serailizable
        • File常用方法
        • Files和Path
        • RandomAccessFile
        • 通过零拷贝实现有效数据传输
        • 正确地处理文件
      • NIO基础
      • NIO2
      • Netty
        • Java I/O的演进之路
        • 为什么是Netty
        • 更多
      • I/O调优
    • 异常
      • 异常体系及为什么要有这种异常设计
      • 多catch的执行情况
      • try catch finally 与reture
      • 异常处理的误区
      • Preconditions:方法入参校验工具
    • 枚举
      • 常见用法
      • 枚举类在序列化中的问题
    • 注解
      • 概述
      • Spring中的组合注解的条件注解
      • 常用注解
        • JSR-330标准注解
    • 反射
      • 概述
      • 内部类的反射
      • 反射中需要注意的地方
    • 流程控制
      • switch case without break
      • Java: for(;;) vs. while(true)
    • JVM
      • JVM内存结构
      • Java内存模型
      • 垃圾收集器和内存分配策略
      • 四种引用类型区别及何时回收
      • 类文件结构
      • 类初始化顺序
      • 类加载机制
      • 虚拟机执行引擎
      • 逃逸分析
      • JVM常用配置
      • GC日志分析
      • Java8 JVM 参数解读
      • 垃圾收集器和内存分配策略
    • 面向对象
      • Object类中的方法
      • Class类中的方法
      • 值传递还是引用传递?
      • 接口和抽象类的区别
      • 深拷贝和浅拷贝
      • Integer.parseInt()与Interger.valueof()
      • hashCode()与equal()
      • String
        • String池化及intern()方法的作用
        • 关于字符串
    • 序列化
      • Java序列化的方式有哪些?
    • 新特性
      • 流 Stream
        • Stream是什么
        • Stream API详解
        • Stream进阶
        • 流编程
        • 其他事项
      • lambda表达式
      • 默认方法(Default Methods)
      • @FunctionalInterface注解
    • SPI
      • 理解SPI
    • 字节码
      • javaagent
      • 字节码操纵
      • 如何查看类编译后的字节码指令
      • 字节码指令有哪些
  • Python
    • 异常处理
  • Go
  • 数据结构与算法
    • 数据结构
      • 概述
        • 线性表
        • 栈
        • 队列
        • 串
        • 树
        • 图
      • Java的一些实现
      • 红黑树
      • 双缓冲队列
      • 跳表SkipList
    • 算法
      • 概述
      • 常见算法
        • 基本排序
        • 高级排序
        • 动态规划
  • 框架或工具
    • Spring
      • Spring基础
        • Spring整体架构
        • 什么是IoC
        • Ioc容器的基本实现
        • Spring的MainClass
          • Spring的BeanFactory
          • Spring的Register
          • Spring的Resource和ResourceLoader
          • Spring的PropertySource
          • Spring的PropertyResolver
          • Spring的PropertyEditor
          • Spring的Convert
          • Spring的BeanDefinition
          • Spring的BeanDefinitionReader
          • Spring的BeanDefiniton其他Reader
          • Spring的BeanDefinition其他Reader2
          • Spring的Aware
          • Spring的BeanFctoryPostProcessor
          • Spring的BeanPostProcessor
          • Spring的Listener
        • Xml格式的应用启动
          • Xml格式的应用启动2
          • Xml格式的应用启动3
          • Xml格式的应用启动4
          • Xml格式的应用启动5
          • Xml格式的应用启动6
          • Xml格式的应用启动7
        • Spring中的设计模式
        • 什么是AOP
        • Spring中AOP的实现
      • Spring应用
        • Spring的事务控制
        • @Transactional注解在什么情况下会失效
        • 如何在数据库事务提交成功后进行异步操作
        • Spring中定时任务的原理
    • SpringMVC
      • Controller是如何将参数和前端传来的数据一一对应的
      • 请求处理流程
    • Zookeeper
      • Zookeeper是什么
      • Zookeeper能干啥
    • Shiro
    • druid
    • Netty
    • Consul
      • Consul是什么
    • etcd
    • confd
    • Akka
      • Actor模型是什么
  • 数据库
    • 基本概念
    • MySQL
      • 基本配置
      • MySQL数据类型
      • MySQL存储引擎
      • MySQL事务
        • MySQL事务概念
      • MySQL索引
        • MySQL中的索引类型
        • B-Tree/B+Tree概述
        • 为什么使用B+Tree
        • MySQL中的B+Tree索引
        • MySQL高性能索引策略
      • MySQL查询
        • MySQL查询过程
        • MySQL查询性能优化
        • 使用EXPLAIN
      • MySQL锁
        • MySQL中锁概述
        • InnoDB的并发控制
        • MySQL乐观锁
      • MySQL分库分表
        • 分库/分表
        • 跨库JOIN
        • 跨库分页
        • 分库分表后的平滑扩容
        • 分区表
        • 分布式ID生成方法
      • MySQL实战
        • 在线表结构变更
        • MySQL优化规则
        • MySQL问题排查
        • 常见查询场景
    • Redis
    • Hbase
    • OpenTSDB
    • rrd
    • MongoDB
    • 连接池
  • 系统设计
    • 一致性Hash算法
    • 限流
      • 限流是什么
      • 限流算法
      • 应用内限流
      • 分布式限流
      • 接入层限流
        • ngx_http_limit_conn_module
        • ngx_http_limit_req_module
        • lua_resty_limit-tarffic
      • 节流
    • 降级
      • 降级详解
      • 人工降级开关的实现
      • 自动降级的实现:Hystrix
    • 负载均衡
      • 概述
      • 互联网架构下的负载均衡
      • Nginx负载均衡(七层)
      • Nginx负载均衡(四层)
      • Nginx动态配置
    • 超时与重试机制
      • 什么地方要超时与重试
      • 代理层超时与重试
      • Web容器超时
      • 中间件客户端超时与重试
      • 数据库超时
      • NoSQL客户端超时设置
      • 业务超时
      • 前端请求超时
    • 网关
    • CAP
      • 什么是CAP
      • CAP理解
    • 生产者-消费者模型
      • 使用notify/wait方式
      • 使用await/signal实现
      • 使用阻塞队列实现
      • 使用信号量实现
      • 使用管道流实现
      • 无锁队列Disruptor
      • 双缓冲队列
    • 缓存
      • 缓存概述
      • 数据库缓存
      • 应用缓存
      • 前端缓存
      • 本地缓存
    • 秒杀
    • LRU
  • 版本控制
    • Git
      • Git常用命令
      • 场景命令
    • Svn
  • 计算机操作系统
    • Linux
      • Linux中重要概念
      • 常用命令
      • 查看日志
      • 权限管理
      • 登录或传输
      • 防火墙
      • 配置ssh免密
      • 进程
      • 防火墙
    • Mac
    • 计算机基础
      • 进制
      • Java中的位运算
      • 计算机存储系统结构
  • 网络
    • TCP三次握手和四次挥手
    • 网络术语
      • 网关、路由器、交换机、IP等
      • VLAN
      • LAN
  • 设计模式
    • 设计模式概述
    • 创建型
      • 单例模式
      • 工厂模式
      • 建造者模式
      • 原型模式
      • 享元模式
    • 行为型
      • 观察者模式
      • 策略模式
      • 模板模式
      • 责任链模式
      • 命令模式
      • 外观模式
      • 迭代器模式
      • 中介者模式
        • 中介模式续
      • 状态模式
        • 状态模式实例
        • 状态模式思考
      • 访问者模式
        • 访问者实例1
        • 访问者模式续
    • 结构型
      • 组合模式
        • 组合模式续
      • 装饰模式
        • 装饰模式续
      • 代理模式
      • 备忘录模式
      • 桥接模式
        • 桥接模式实例一
  • 构建工具
    • Maven
      • 常用命令
      • Maven生命周期
      • Maven中的变量和属性
      • 不同环境的如何配置不同的变量
      • 常用插件及配置
      • 其他问题
      • dependencies与dependencyManagement的区别
    • Gradle
  • 大数据
    • Hadoop
    • Storm
    • Spark
  • 服务器
    • Tomcat
      • server.xml配置详解
      • 线程池和连接数配置
      • Maven远程部署
      • 一些小技巧
      • Tomcat类加载机制分析
      • Tomcat的日志
      • Tomcat架构
        • 概述
        • Server 的启动流程
        • 请求处理流程
    • Nginx
      • 常用命令
      • 基本配置
      • Lua
    • Tengine
  • 中间件
    • 任务调度
      • 为什么需要任务调度
    • 消息队列
      • 为什么需要消息队列
      • 消息队列关键点
      • 消息中间件需要解决的问题
      • 不同消息队列产品对比
      • RocketMQ
        • 快速入门
        • 整体架构
        • 部署方式
          • Broker部署方案
        • 客户端使用
          • 客户端使用指南
          • 快速开始
          • 简单示例
          • 有序消息示例
          • 广播消息示例
          • 定时消息示例
          • 批量消息示例
          • 过滤消息示例
          • 日志输出配置示例
        • 关键点实现
          • 顺序消息的实现
        • 最佳实践
          • Broker的最佳实践
          • 生产者最佳实践
            • 生产者最佳实践续
          • 消费者最佳实践
            • 消费者最佳实践续
          • 名称服务最佳实践
          • JVM/kernel配置的最佳实践
          • 新特性 Filter Server
          • 其他事项
      • RabbitMQ
      • Kafka
    • 分布式事务
      • 什么是分布式事务
      • 解决方案
    • 服务治理
      • RPC概念
      • RPC最简实现
      • 为什么需要服务治理
      • Dubbo
        • Dubbo整体架构
      • Java RMI
    • 分布式锁
      • 如何设计分布式锁
        • 基于zookeeper
        • 基于Redis
    • 注册中心
      • 注册中心的职责
      • 不同注册中心的比较
    • 配置中心
      • 概述
      • 配置中心的实现与选型
  • Web开发
    • Http请求类型及区别
    • 常见的content-type
    • 如何处理跨域
    • Restful最佳实践
    • HTTP状态码
    • Http下载原理
  • 测试
    • 压测:apache bench
    • 压测:Jmeter
Powered by GitBook
On this page
  • 概述
  • CAP分别是指什么
  • 一致性
  • 可用性
  • 分区容错性
  • CAP定理
  • 三中取二原则
  • BASE模型
  • 一致性
  • 基本可用
  • 软状态
  • 内容来源
  1. 系统设计
  2. CAP

什么是CAP

概述

在计算机科学中, CAP 理论又称之为布鲁尔定理(Brewer's theorem),目前已成为分布式系 统设计与构建的重要理论基石。它是加州伯克利分校计算机科学家埃里·布鲁尔(Eric Brewer) 在 1998 年提出一个假说,并在 2000 年的分布式 计算原则研讨会上发表。这个假说是 Brewer 及 其同事在横向可扩展分布系统设计方面多年辛 勤劳动的结晶。在 2002 年,麻省理工学院的赛 斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)又完成了布鲁尔假说的证明,使之脱离 了唯像学说而成为一个定理,但吉尔伯特和林奇证明的布鲁尔定理比布鲁尔假说狭义。

CAP分别是指什么

在分布式的环境下,设计和部署系统时主要考虑下述 3 个重要的核心系统需求。

  • 一致性(Consistency):所有节点在同一 时间具有相同的数据。

  • 可用性(Availability):保证对于每个请 求的成功或者失败都有响应。

  • 分区容错性(Partition Tolerance):系统中信息的丢失或失败并不影响系统的运行。

上述 3 个重要的核心系统需求又简称为 CAP。

一致性

在分布式系统中,数据存在多个副本。一致性是指对某数据操作之后,存在各副本中的该数据始终保持一致。通常将这种操作称为一致性操作,一致性操作是原子性的操作,即对数据的操作(增、删、改)结果是对所有数据副本全部成功才算操作成功,否则为失败。如果操作失败, 则回退到一致性操作前的状态。

如果一个存储系统能够保证一致性,那么客户读取的数据可以保证是最新的数据,不会发生两个客户端在不同存储节点读取到不同的数据副本。

假设:N1、N2 为网络中的两个节点,共享同一数据 V,即一个是主本,另一个是副本,其初始值为 V0。N1 节点上有一个算法 A, N2 上有一 个类似的算法B,利用A算法可以将新值写入V, 而利用 B 算法可以读取 V 的值。

1)数据保持一致性情况:① A 写入新的V值,称作V1;② N1发送信息给N2,更新 N2的V值;③ B 读取N2的V值,读取到的值将是V1。

2)数据出现不一致性情况:如果网络断开(分区),从 N1 无法发送信 息到 N2,那么在第上面第③步的时候,N2 就会包含 一个与 N1 中的不一致的 V 值,即在 N1 中的 V= V1,在 N2 中的 V= V0。

可用性

可用性是指客户端访问数据时,可以得到响应,但系统可用并不代表存储系统的所有节点提供的数据一致。比如,客户端想要读取文章评论,存储系统可以返回客户端数据,但评论缺少最新的 一条。在这种情况下,我们仍然可以说系统可用。对不同的应用,可以设定一个定长响应时间,超过这个定长响应时间的服务认为不可用。 可用性只表明服务可用,主要标志是可以完成或不能完成上述操作。比如,当用户购书时希望得到反馈,而不是看到浏览器报告网站无法连接的信息。

分区容错性

在分布系统中,为了提高系统性能,可以将同一数据的副本分布地存放在不同地点。分区容错性是指分布系统的容错性。

更确切地说,除非网络的全部节点都出现故障,否则所有子集合节点的故障都不能导致整个系统的不正确响应。显然,将数据分布在不同节点上,就有形成分区的风险。如果网线被切断,分区就形成,两节点之 间无法进行通信。网络分区是指由于某种原因网 络被分成若干个孤立的互不相通区域。

分区容错性也可以理解为系统在存在网络分区的情况下仍然可以接受满足一致性或可用性的请求。

CAP定理

CAP 定理:在一个分布式系统构建中, 不可能同时满足一致性、可用性和分区容错性三个系统需求,最多只能同时满足两个。

对所设计系统的强调点不同,采用的策略也不一样。 分布式系统在小规模、低压力、小延迟的情况 下,CAP 定理还不足以对系统总体性能造成影响, 但随着活动增加与吞吐量上升将凸显其重要性。 对大型网站来说,可用性与分区容错性的优先级高于数据一致性,一般放弃一致性,尽量朝着可用性和分区容错性的方向设计,然后通过其他方法来保证一致性的需求(即满足最终一致性)。

架构设计师不要将主要精力用在如何设计能同时满足三者的完美分布式系统,如社交 SNS 网站可以容忍相对较长时间的不一致性,但需要最终一致性。

CAP 的证明很简单,假设两个节点集 {G1, G2},由于网络分片导致 G1 和 G2 之间所有的通讯都断开了,如果在 G1 中写,在 G2 中读刚写入 的数据, G2 中返回的值不可能是 G1 中的写入值。 由于可用性的要求,G2 一定要返回这次读请求,由于分区容错性的存在,导致不一致性。但由于 一致性的要求,G2 一定要返回这次读请求的一 致性结果,由于分区容错性的存在,导致了长期等待,出现了不可用性。

三中取二原则

CAP 定理阐明分布系统构建中的 3 个核心系统需求不能够全部同时满足:

  • 强调一致性:需要处理因为系统不可用而导致的写操作失败的情况;

  • 强调可用性:系统的读操作可能不能精确的读取到写操作写入的最新值。

因此系统的强调点不同,相应采用的策略也不一 样,只有真正理解了系统的需求,才有可能合理使用 CAP理论。 目前互联网中的很多分布式系统是基于首要满足可用性和分区容错性而设计。当处理 CAP 的问题时,存在下述几个选择。

1、放弃可用性

如果选择分区容错性和一致性,放弃了可用性,那么即使节点损坏,为保证一致性,必须百分之百地保证所有节点之间有很好的连通性,这是很难做到的。最好的办法就是将所有数据放到同一个节点中,但显然这种设计一旦遇到分区事件,受影响的服务需要等待数据一致,在等待期间就无法对外提供服务。

在多个节点上控制数据一致相当复杂,而且恢复的节点需要处理逻辑, 以便平滑地返回服务状态。

满足一致性与分区容错性的系统主要是一些键值数据库, 典型代表为 Google 的 BigTable 等系统。

2、放弃分区容错性

如果要满足一致性和可用性,必须要有回滚操作。这样,系统显然无法容忍分区,当同一数据的两个副本分配到了两个无法通信的分区上并需要回滚操作时,将会返回错误的数据。 满足一致性和可用性的系统通常在可扩展性方面不太强,如传统的关系数据库系统 MySQL 等。

3、放弃一致性。

如果选择分区容错性和可用性,放弃了一致性,当节点损坏时,遇到分区事件,受影响的服务不需要等待数据一致,就可以对外提供服务, 保证了可用性。

满足可用性与分区容错性的系统主要是一 些面向文档的适用于分布式系统的数据库,如 SimpleDB。 两个节点分处分区两侧,允许至少一个节点更新状态将导致数据不一致,即丧失了一致性。 除非两个节点可以互相通信,才能既保证一致性又保证可用性,这又会导致丧失分区容错性。

对于跨区域的系统,设计者无法舍弃分区容错性, 那么就只能在数据一致性和可用性上做一个艰难选择。一般说来,NoSQL 的主题是创造可用性优先、数据一致性其次的方案;而传统关系数据库保持 ACID 特性(原子性、一致性、隔离性和 持久性)。

BASE模型

BASE:Basically Available, Soft-state,Eventually consistent,即基本可用,软状态,最终一致。

BASE 模型在 20 世 纪 90年代末提出, 基于同性质之间的取舍,考虑了高可用性的设计。BASE思想主要强调基本的可用性,显然 BASE 支持最终一致的概念。BASE 是 ACID 的反面,BASE 要求牺牲高一致性,获得可用性或可靠性。BASE 理论是 CAP 理论结合解决实际问题的产物。

大规模跨区域分布的系统, 包括云在内,也运用了这种思路:通过牺牲一致性来提高可用性和系统性能。

一致性

基于程度的不同,一致性可有下面表述。

  • 强一致性:又称为即时一致性, 假如 A 操作先写入了一个值到存储系统,存储系统保证后续 A、B、C 的读取操作都将返回最新值。

  • 弱一致性:假如 A 先写入了一个值到存 =储系统,存储系统不能保证后续 A、B、C 的读取操作能读取到最新值,即 A 写完的数据并不能立刻读到。

  • 最终一致性:最终一致性是弱一致性的一种特例,是指系统需要在某一时刻后达到一致性要求。假如 A 首先写了一个值到存储系统,存储系统保证如果在 A、B、C 后续读取之前没有其他写操作更新同样的值,最终所有的读取操作都将读取到 A 写入的最新值。即最终数据是一致的就可以了,而不是时时一致。最终一致性方面最典型的系统可以说是DNS系统,当更新一个 域名的 IP 以后,根据配置策略以及缓存控制策 略的不同,所有的客户最终都会看到最新的值。

基本可用

基本可用的含义是系统能够基本运行、始终提供服务。BASE 模型与 ACID 模型相反,通过牺牲高一致性,获得可用性和分区容错性。

软状态

软状态是指系统不要求一直保持强一致状态,可以有一段时间不同步。软状态也可以理解为无连接的,而硬状态是有连接的。

内容来源

PreviousCAPNextCAP理解

Last updated 6 years ago

分布系统设计的 CAP 理论