分布式数据库CAP原理与ACID,CAP+BASE

ACID

• A(Atomicity)原子性：事务不可分割，要么对数据的一系列操作同时完成，要么都不完成。
  • 比如A向B转账100元，分两步,1）A从账户取出100元，2）B账户增加100元
  • 这个两个步骤（事务）要么都执行，要么都不执行（回滚），否则如果A取出了100元成功，但是B账户增加失败，就会导致莫名其妙少了100元。
• C(Consistency)一致性：事务执行前后，数据完整性保持一致，是指事务的改变要保持约束条件始终成立。
  • 比如规定了a+b=10,那么如果a被改变，b也应该做出改变，始终保证a+b=10成立。
• I(Isolation)事务独立性：多个事务在访问和操作同一份数据时，事物之间不会相互影响。
  • 比如A正在从账户里取100元钱，此时另一个事务访问A账户时是看不到A账户少了100元钱的。
• D(Durability)持久性：事务一旦操作完成提交，那么数据就会保存到数据库。

CAP

• C(Consistency)强一致性：在分布式系统中所有节点和备份数据保持在同一时刻数据一致。
• A(Availablitiy)可用性：当集群的部分节点故障后，其他备份节点能否支持集群整体响应客户端的读写要求。
• P(Partition tolerance)分区容错性：当集群发生网络故障、机器故障、停电等特殊情况时，集群仍能满足系统正常工作，为了满足这个要求就必须对集群进行分区。

CAP理论

• 在分布式系统中不可能同时满足CAP要求，因为为了保证可用性（A），让发生故障时整个系统仍然能正常工作，我们就必须要对集群分区（P），而一旦分区就可能出现网络丢包的情况，就不能满足强一致性（C）。

• 所以在设计分布式集群的时候我们只能尽量保证AP或者CP,不能保证CAP。

• 因为分布式，就必须要保证P,A和C只能偏向性选择一个。该怎么选应该根据实际情况而定，如果强调数据的一致性必须保证就选择CP（一般在银行金融方面选择这类设计），如果强调功能必须保证就选择AP（比如淘宝、微博这种，对用户来说功能必须满足，一些（点击、浏览次数）统计数据就不必强调一致性）。

经典CAP原则图

BASE

BASE是经过大量分布式集群设计的实践和资料，根据CAP原则所总结出的结论，一种取舍方案。
BASE是指Basically Available（基本可用），Soft State（软状态），Eventually Consistent（最终一致性）
基本可用：就是在一部分节点发生故障时，仍然保证系统基本功能可用。
在发生故障时虽然基本可用，但是可能会导致响应时间增加，部分功能不可用。
软状态：在访问量过大时，允许数据在同步时发生延迟，但是必须保证不会影响功能使用。
最终一致性：在大量访问过后，一段时间内，所有数据会最终同步保证数据一致性。而不用实时保证数据一致性。