CAP BASE ACID

Posted 2021-06-27 Lindbergh_

CAP定理： 也称布鲁尔定律。

他指出一个在集群上运行的分布式数据库系统，只能提供以下三个属性中的两个。

如果不是分布式的情况就可以同时满足CAP三个属性

• 一致性（Consistency）
  • 从任何节点的读操作应得到相同的结果
• 可行性（Availability）
  • 任何一个读/写请求总能得到成功或是失败的相应（意思是只要收到用户的请求，服务器就必须给出回应）
• 分区容忍（Partition tolerance）
  • 数据库系统可以容忍通信中断（可以允许出现线路故障，即集群中的某一台坏了，系统仍可用）
  • 大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

C+A 一般不选择

当我们追求一致性和可行性，必须放弃分区（分区会产生一个隔离，把两个复制的数据隔离开，当数据隔离开就会造成数据的不一致）

弃用的原因

因为可能通信失败（即出现分区容错）。

如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。

如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

因为线路故障是很难避免的，特别是集群这种情况，操作是需要多个副本同步，这样他们就会有时间差，就会有延时，还可能有故障（线路断了），所以很难保证P

C+P

当我们追求一致性和分区容忍，会造成有时候访问没有效果，因为不知道是对还是错。

也就是满足一致性和容错性，舍弃可用性。如果你的系统允许有段时间的访问失效等问题，这个是可以满足的。就好比多个人并发买票，后台网络出现故障，你买的时候系统就崩溃了。

A+P 最常用

当我们追求可行性和分区容忍，就没法保证一致性，会造成数据的不同步。

BASE

根据CAP定律而来的数据库设计原则，它采用了分布式技术的数据库系统。

• 基本可用（Basically Available）
  • 用户A和用户B即使因为数据库由于网络故障被分区，仍可以使用数据库。（可读，但是此时的数据并没有同步）
• 软状态（Soft State）
  • 软状态意味着一个数据库当读取数据时可能会处于不一致的状态。（不同分区在未全部同步时访问，造成数据不一致）
• 最终一致性（Eventaul Consistency）
  • 最终所有分区数据会一致，但数据库只有当更新变化传播到所有的节点后才能达到一致。且在此之前，他就是处于软状态

更多强调可用性（A+P），即牺牲一致性确保可用性（上锁）

ACID

是事务管理的形式，利用悲观并发控制来确保一致性

是基于传统关系型数据库

• 原子性（Atomicity）
  • 确保所有操作总是换成或彻底失败
• 一致性 （Consistency）
  • 保证数据库总是保持在一致的状态，数据库的完整性没有被破坏
    • 这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。（进入数据库的数据必须符合所有约束条件）
• 隔离（lsolation）
  • 确保事务的结果对其他操作而言是不可见的，直到事务完成为止
• 持久性（Durability）
  • 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。