• 原文
  • 概念
    • CAP定理
      • CAP定理,指的是在一个分布式系统中,三个要素最多只能同时实现两点,不可能三者兼顾
        • 一致性 - Consistency:强一致性
          • 在分布式系统中的所有数据备份,在同一时刻是否同样的值。并不是指整个系统能提供最新的一致的数据。
        • 可用性 - Availability:100%的可用性
          • 客户端无论访问到哪个没有宕机的节点上,都能在有限的时间内返回结果,并不是指整个系统处于可用状态
        • 分区容错性-Partition tolerance
          • 网络中允许丢失一个节点发送给另一个节点的任意多的消息,即对网络分区的容忍。在发生网络分区时,能继续保持可用性或者一致性。
          • 一个系统要求在运行过程中不发生网络分区,那么这个系统就不具备分区容错性
      • CAP定理中的可用性和一致性与用户感知的可用性和一致性不是一个概念。
        • 我们追求的应该是用户感知的可用性
    • BASE定理
      • BASE是对一致性和可用性权衡所得的结果
      • 在某些场景中,无需做到强一致性,以保证系统的可用性,同时每个应用可以采用适当的方式使系统数据达到最终一致性。
      • BASE分别是指:
        • 基本可用 - Basically Available
          • 分布式同在出现故障的时候,允许损失部分可用性,但不等于系统不可用。
          • 例如:响应时间的损失,功能上的降级
        • 软状态 - Soft State
          • 允许系统中的数据存在中间状态,并认为该状态不会影响系统整体可用性
          • 允许节点之间的数据同步存在延时
        • 最终一致性 - Eventually Consistent
          • 本质是指系统需要事数据最终达到一致性,而不需要实时使数据达到一致性
    • ACID
      • ACID中中一致性(C)的定义
        • 如果事务执行前数据库处于一致状态,那么当事务结束的时候,数据库也会处于一致性状态
          • 第一层意思,数据库内部的完整性
            • 实体完整性、域完整性、参数完整性、用户自定义完整性
            • 使用外检、检查约束等,来保证事务执行不会产生违背数据完整性的数据。例如:使用唯一约束的列不会出现两个一样的值
            • A transaction must preserve database consistency - if a transaction is run atomically in isolation starting from a consistent database, the database must again be consistent at the end of the transaction.
          • 第二层意识,对开发者的要求,数据库中的每一行和每一个值必须与其所描述的现实保持一致
            • 例如银行转账,不能只一方扣钱或者一方加钱,我们的代码应该是,一方加钱一方扣钱
            • Ensuring consistency or a individual transaction is the responsibility of the application programmer who codes the transaction
  • 为什么CAP三者不可兼得
    • 网络分区是必然存在的
      • 什么是网络分区
        • 在一个分布式系统里面,节点组成的网络本来应该是连通的,然而可能因为一些故障(网络设备failure、节点failure),使得有些节点之间不连通了,整个网络分成了几块独立的区域(子集)
      • 在分布式系统中,各个组件必然部署在不同的节点上,必然出现网络分区,同时网络本身是不可靠的,一定存在延迟和数据丢失。
      • 分区容错性是分布式系统必须要面对和解决的问题
    • 在P要素必须存在的情况下
      • CP架构:如果坚持保持各节点之间的数据一致性(C),需要等待网络分区恢复后,将数据同步完成,才可以向外部提供服务。因期间网络分区不能对外提供服务,保证不了可用性(A)。
      • AP架构:如果选择可用性(A),发生网络分区的节点,依然需要向外提供服务。但是由于网络分区,同步不了罪行的数据,所以它返回的数据,可能不是最新的,保证不了数据一致性(C)。
    • CAP不可兼得是指在容忍网络分区的情况下,才需要在A和C之间选择。而在集群正常运行是,A和C是都可以保证的。
  • ACID与CP、BASE与AP,它们的关联关系?
    • CP、AP两者是对ACID、BASE的延伸
    • CP和ACID都是为了保证数据准确性。但解决的问题不一样
      • CP描述的是发生网络分区时,保证数据准确性
        • 外部一致性,分布式系统中,针对客户端的请求,无论访问哪个节点,都能活动最新的相同的值
      • ACID解决的是多个事务并发下,保证数据准确性
        • 可以理解为不出现脏读、幻读、不可重复读的问题
          • 脏读:事务T1读取了T2更改的x,但是T2在实际存储数据时出错回滚了,这是T1读取的实际是无效的数据
          • 不可重复读:在T1读取x时,中间T2更改了x,后T1重新读取x,T1前后两次读取的x值不行同,产生了不可重复读
          • 幻读:在T1读取符合某个条件的所有记录时,T2增加了一条符合该条件的记录,但因为某些原因回滚了,导致T1读取的数据中多了不在数据库中的值
        • 内部一致性,解决的是数据库内部的一致性问题
    • AP和BASE都是对可用性的研究
      • BASE要求的是基本可用,允许损失部分可用性
        • 响应时间上的损失
          • 在发生故障时,允许在限定时间之外给用户响应
        • 功能上的损失
          • 在请求高峰时,可以选择一部分请求降级
      • AP对一致性要求低,所以保证的可用性会更高
    • eureka属于AP系统吗,它明明没有放弃一致性
      • AP代表:eureka
        • eureka各个节点相互独立、平等,各节点都提供查询和注册服务(读、写请求)。
        • 当发生网络分区时,eureka各节点依旧可以接收和注册服务。并且当丢失过多客户端时,节点会进入自我保护(接收新服务注册,不删除过期服务)。在该种模式下,eureka集群剩下最后一个节点,也可以向外提供服务,尽管向外提供的数据可能是过期的数据
      • CP代表:zookeaper
        • zookeaper采用的过半原则,由leader处理写请求
        • 当发生网络分区时,leader由于丢失过半的follow,从而处理不了客户端的请求,需要重新选举新的leader,期间服务将不可用
        • 糟糕的是,如果就去年中没有过半的节点存货,将选举不出新leader,服务将一直处于不可用状态
      • 无奈轮式eureka还是zookeaper,这两者选择AP、CP的架构,一定是在发生了网络分区的情况下。集成正常运行,各节点之间可以正常通讯、保持心跳、复制数据,并不会出现可用性和一致性的互斥场景。当发生了网络分区,eureka确实选择了可用性,放弃了一致性;zookeaper选择了一致性,放弃了可用性
  • NWR
    • NWR是一种在分布式存储系统中用于控制一致性级别的一种策略
      • N:分布式系统汇总,一个有多少副本数据
      • W:处理一次写请求,需要更新多少个副本数据
      • R:处理一次读请求,需要读取多少个副本数据
    • NWR不同的设值,会产生不同的一致性效果
      • W + R > N,整个系统对于客户端的请求能保证强一致性
        • 写请求和读请求一定存在一个香蕉的副本,读取的时候返回该副本的数据即可
      • W + R <= N,整个系统对于客户端的请求不能保证强一致性
    • 基于NWR的形式,可以动态调节系统的一致性效果,也可以根据业务场景动态调节响应速度
    • W、R的大小,直接营销其对应的处理效率。同时,读写请求的效率取决于最慢的副本处理速度。
  • paxos算法,可以容忍少数集合节点宕机,可以认为paxos挺了比较高的可用性服务,同时又实现了一致性,那么是否违背了CAP定理
    • 没有违背。CAP定理中的可用性是100%可用
    • 当发生网络分区时,使paxos集群形成了多数派集群和少数派集群
    • 当客户端访问多数派节点时,能收到正常的反馈,但少数派集群的节点则不能
  • 参考:

思维导图: