分布式理论基石CAP理论

比眉伴天荒 2022-05-18 00:55 234阅读 0赞

**一 传统数据库的ACDI理论**

*  原子性（atomicity）：一个事务必须视为一个不可分割的最小工作单元，要么都执行要么都不执行。
 *  一致性（consistency）：一个事务执行会使数据从一个一致状态切换到另外一个一致状态。也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束例如：小明和小华账户余额均为5，无论他们之间怎么转账，他们余额之和始终为10块。
 *  永久性（durability）事务一旦提交，对数据的改变是永久性的。
 *  隔离性（isolation）：事务与事务之间互不干扰。

**二 CAP:在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），只能三选二。**

**Consistency：节点之间数据传递允许延时、阻塞、抛异常，但是必须实时准确。**

*  如果数据更新后，并发访问下可立刻感知该更新成为强一致性。
 *  如果允许部分或者全部感知不到该更新成为弱一致性。
 *  若一段时间后，一定可以感知到更新称为最终一致性。

**Availability：节点之间数据传递不允许超时或响应错误，但是可以返回假或者旧数据，要求有求必应。和一致性冲突。**

**Partition tolerance：某个节点挂掉不影响其它节点对外提供服务。**

*  CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。（如传统Oracle数据库）
 *  CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。（大多数网站架构的选择）
 *  AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。（Redis、Mongodb）

**三 在NOSQL中P分区容错性是必须要满足的,所以能调整的地方就在C和A上。那么它们该怎么选择呢？**

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。  
数据库的写实时性和读实时性需求  
　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。  
对复杂的SQL查询，特别是多表关联查询的需求   
　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

**四 BASE方案**

**     ** **Basically Available（基本可用性）+Soft state（软状态）+Eventually consistent（最终一致性） 。**

*  基本可用性：分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如说用户查询数据的相应时间延长了，或者浏览高峰期时去掉很多非必须功能给用户相应一个简化版的页面。
 *  软状态:允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。
 *  最终一致性:所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。