远方的灯塔 - 专注于服务端技术分享 远方的灯塔 - 专注于服务端技术分享
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)

Terwer Green

一个后端老菜鸟
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 文章分类
  • 文章标签
  • 文章归档
  • 《C程序设计语言》
心情随笔
友情链接
给我留言 (opens new window)
关于我
GitHub (opens new window)
  • JavaSE

  • 开源框架

  • Linux

  • Struts2

  • Hibernate

  • Webservice

  • 分布式

    • RPC架构设计及IO模型
    • NIO编程及其三大核心原理
    • NIO三大核心之缓冲区(Buffer)
    • NIO三大核心之通道(Channel)
    • NIO三大核心之选择器(Selector)
    • Netty核心原理
    • 线程模型以及传统IO阻塞模型
    • Reactor模型
    • Netty线程模型
    • Netty核心API介绍
    • Netty入门与异步模型
    • Netty高级进阶之Netty编解码器
    • Netty高级进阶之基于Netty的群聊天室案例
    • Netty高级进阶之基于Netty的HTTP服务器开发
    • Netty高级进阶之基于Netty的Websocket开发网页聊天室
    • Netty高级进阶之Netty中的粘包和拆包的解决方案
    • Nety源码剖析
    • 自定义RPC框架之分布式架构网络通信理论
    • 自定义RPC框架之基于Netty实现RPC框架
    • 分布式架构理论
    • 分布式理论之数据一致性
    • 分布式理论之CAP定理
      • 分布式理论之BASE定理
      • 分布式一致性协议之两阶段提交协议(2PC)
      • 分布式一致性协议之三阶段提交协议(3PC)
      • 分布式一致性协议之NWR协议
      • 分布式一致性协议之Gossip协议
      • 分布式一致性协议之Paxos协议
      • 分布式一致性协议之Raft协议
      • 分布式一致性协议之Lease机制
      • 分布式系统设计策略之心跳检测
      • 分布式系统设计策略之高可用
      • 分布式系统设计策略之容错性
      • 分布式系统设计策略之负载均衡
      • 分布式架构服务调用
      • 分布式服务治理之服务协调
      • 分布式服务治理之服务削峰
      • 分布式服务治理之服务降级
      • 分布式服务治理之服务限流
      • 分布式服务治理之服务熔断
      • 分布式服务治理之服务链路追踪
      • 架构设计基本原则之开闭原则(OCP)
      • 架构设计基本原则之单一职责原则(SRP)
      • 架构设计基本原则之接口隔离原则(ISP)
      • 架构设计基本原则之里式替换原则(LSP)
      • 架构设计基本原则之依赖倒置原则(DIP)
      • 架构设计基本原则知识扩展
      • 分布式架构知识拓展与总结
    • 分布式框架

    • 后端开发
    • 分布式
    terwer
    2022-04-28
    目录

    分布式理论之CAP定理

    # CAP定理

    # CAP定理介绍

    CAP定理(CAP Theorem),又称布鲁尔定理(Brewer's throrem)。它指出,对一个分布式系统来说,不可能同时满足以下三点:

    选项 具体意义
    一致性(Consistency) 所有节点访问时都是同一份最新的数据副本
    可用性(Availability) 每次请求都能获取到非错的响应,但是不保证获取数据为最新数据
    分区容错性(Partition tolarence) 分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境发生了故障
    • 一致性(Consistency)- C

      指的是强一致性

      在写操作完成后开始的任何读操作都必须返回该值,或者后续写操作的结果。

      就是说,在分布式系统中,一旦客户端将值写入任何一台服务器并获得相应,那么之后client从其他服务器读取的都是刚写入的数据。

    image-20220317230127717

    • 客户端向G1写入数据,并等待响应

    • 此时,G1服务器的数据是v1,G2服务器的数据是v0,不一致

    • 在返回数据到客户端之前,G2服务器会自动同步G1服务器的数据,使G2服务器的数据也是v1

    • 一致性保证了,不管向哪台服务器(比如G1)写入数据,其他服务器都能实时同步数据

    • G2已经同步了G1的数据,会告诉G1,我已经同步了

    • G1接收了同步的报告,将”写入成功“的信息返回给client

    • client在发起请求,读取G2的数据

    • 此时读取到的响应值是v1

    • 可用性(Availability)- A

      系统中非故障性节点的每个请求都必须有响应。

      可用系统中,如果客户端向服务端发送请求,并且服务器未崩溃,则服务器必须最终响应客户端,不允许服务端忽略客户端的请求。

    • 分区容错性(Partition tolarence) - P

      允许网络丢失从一个节点到另一个节点的任意条消息,即不同步。

      就是说,G1和G2发送给客户端的任意消息都可以放弃。

      G1和G2可能会因为各种意外状况,导致无法成功同步,分布式系统能容忍这种情况。

    image-20220317232109808

    # CAP三者不能同时满足结论

    假设存在三者都能满足的系统

    1、那么做的第一件事就是分区我们的系统,由于满足分区容错性,也就是说,可能因为网络通信不佳,导致G1和G2不同步

    image-20220317233342357

    2、接下来,我们的客户端将v1写入G1,但是G1和G2之间是不同步的,所以如下,G1是v1的数据,G2是v0的数据

    image-20220318095813714

    3、由于要满足可用性,即一定要返回数据,所以G1必须在数据没有同步给G2的前提下返回数据给client,如下

    image-20220318101516244

    接下来,client请求的是G2服务器,由于G2服务器的数据是v0,那么client得到的数据也是v0

    image-20220318101730019

    结论:G1返回的是v1的数据,G2返回的是v0的数据,不满足C。因此得证,CAP不可能同时出现。

    image-20220318102130059

    # CAP三者如何平衡

    # 三选二利弊如何
    • CA(Consistency + Availability),关注一致性和可用性,他需要非常严格的全体一致性协议。

      CA系统不能容忍网络错误或者节点错误,一旦出现这样的问题,系统就会拒绝写请求。

      因为它并不知道哪个节点挂掉了或者只是网络故障问题。

      唯一安全的做法是把自己变成只读的。

    image-20220318102935087

    • CP(Consistency + Pattition tolerance),关注一致性和分区容错性。他关注的是系统中大部分人的一致性协议。这种系统只需要保证大多数节点数据一致,少数节点在没有同步到最新数据时,变成不可用状态。

      这样能够提供一部分可用性。

    image-20220318103603711

    • AP(Availability +Pattition tolerance),关系可用性和分区容错性。

      这样的系统不能保证一致性,需要给出数据冲突,给出数据冲突就需要维护数据版本。

    image-20220318105221075

    # 三选二如何选择
    	放弃了一致性,满足容错,那么节点之间可能失去联系,为了高可用,每个节点只能使用本地数据提供服务,而这样容易导致全局不一致性。
    
    	对于互联网应用来说,机器数量庞大,节点分散,网络故障很正常,此时就是保障AP,放弃C的场景。实际理解就是,网站偶尔没有一致性是可以接受的,但是不能访问问题就很大。
    

    image-20220318105337120

    	对于银行来说,C必须存在,那么只能用CA和CP两种情况。当保障一致性和可用性时(CA),那么一旦出现通信故障,系统将完全不可用。如果保障了一致性和分区容错性(CP),那么就具备了部分可用性。需要根据实际情况抉择,如果只是查看不做更新,那么不如直接拒绝服务。
    

    image-20220318110449358

    编辑 (opens new window)
    #rpc#cap#consistency#availability#partition#tolarence
    上次更新: 2023/02/22, 13:47:25
    分布式理论之数据一致性
    分布式理论之BASE定理

    ← 分布式理论之数据一致性 分布式理论之BASE定理→

    最近更新
    01
    解决css部分border被圆角切掉之后圆角的边框消失问题
    03-18
    02
    使用TypeScript开发一个自定义的Node-js前端开发脚手架
    03-08
    03
    Github-Actions使用release-please实现自动发版
    03-06
    更多文章>
    Theme by Vdoing | Copyright © 2011-2023 Terwer Green | MIT License | 粤ICP备2022020721号-1 | 百度统计
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式