基于CAP原理的ACID和BASE模型介绍

最新推荐文章于 2024-04-14 12:47:24 发布

pholien

最新推荐文章于 2024-04-14 12:47:24 发布

阅读量517

点赞数

文章标签： cap原理 acid base

本文链接：https://blog.csdn.net/FQiang2011/article/details/52413797

版权

本文介绍了数据库的ACID特性，包括原子性、一致性、隔离性和持久性，并提到了为了实现这些特性所采用的技术，如WAL预写式日志和阴影页。此外，还提及了数据库的功能划分和分区策略——sharding。

摘要由CSDN通过智能技术生成

 
 分布式领域CAP理论， 

 
 Consistency(一致性),  
 一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多点的数据是否一致。 

 
 Availability(可用性), 好的响应性能， 
 可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。而这种可用性是不关乎结果的正确与否，所以，如果服务一致返回错误的结果，其实也可以称为其是可用的。 

 
 Partition tolerance(分区容错性) 可靠性， 
 Partition这个词不是常说的操作系统或数据库中的用语，而是指网络的分区。网络中的两个服务结点出现分区的原因很多，比如网络断了、对方结点因为程序bug或死机等原因不能访问。 

 
 定理：任何 
 分布式 
 系统只可同时满足二点，没法三者兼顾。 

 
 忠告：架构师不要将精力浪费在如何设计能满足三者的完美 
 分布式 
 系统，而是应该进行取舍。？？？？ 

 
 cap理论创立者最新论文说，架构师在设计分布式系统时不要直接就抛弃一点，而是在先考虑尽量满足三者，然后再在三者中做个平衡，定理中说满足两点并不是说完全抛弃第三点，比如一个分布式数据库肯定满足了 Partition tolerance，再满足avaibility，那么它可能完全抛弃数据一致性吗，显然不可能嘛，只是在降低了对数据一致性的要求，并不需要数据时刻保持一致。 

 
 基于CAP理论，有acid 和base模型，acid实线了ca，base 实现了ap。 

 
 ACID，现代关系型数据库基本都是基于这个原理，是数据库事务正确执行的四大基本元素，包含： 

原子性（Atomicity）：一个事务包含多个操作，这些操作要么不完成，要么全部完成，如果在执行过程中发生错误，那么系统会回滚到事务开始的状态。
一致性（Consistency）：事务在开始和结束时，系统的状态必须一样，不管给定的并发数，系统就像串行的执行这些并发操作一样，主要特征是保护性和不变性（Preserving and Invariant），其实可以理解为结果正确性。
隔离性（Isolation）：隔离状态执行事务，两个相同的事务执行就像串行的执行一样，事务间不会相互影响。
持久性（Durability）：事务执行完毕之后，结果将会保存在数据库里，不会再做回滚操作。

  实现acid 的方式有两种： 

WAL（write-ahead logging）
shadow paging

  相对于WAL（write ahead logging）技术，shadow paging技术实现起来比较简单，消除了写日志记录的开销恢复的速度也快(不需要redo和undo)。shadow paging的缺点就是事务提交时要输出多个块，这使得提交的开销很大，而且以块为单位，很难应用到允许多个事务并发执行的情况——这是它致命的缺点。 

  WAL 的中心思想是对数据文件 的修改（它们是表和索引的载体）必须是只能发生在这些修改已经 记录了日志之后 -- 也就是说，在日志记录冲刷到永久存储器之后． 如果我们遵循这个过程，那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘，因为我们知道在出现崩溃的情况下， 我们可以用日志来恢复数据库：任何尚未附加到数据页的记录 都将先从日志记录中重做（这叫向前滚动恢复，也叫做 REDO） 然后那些未提交的事务做的修改将被从数据页中删除 （这叫向后滚动恢复 - UNDO）。 

 
 BASE，base模型时一个反acid模型，牺牲了数据库的高一致性，来取得高可用性： 

  basically available 基本可以，支持分区失败 

  soft state 软状态，状态可以在一段时间不同步， 

  Eventually Consistency 最终一致性，只要数据最终一直就可以了，并不需要数据时刻保持一致 

  所以说base牺牲了高一致性，并不是说它完全抛弃了数据一致性，如果数据库完全牺牲数据一致性就太可怕了，那样的数据库拿来也没什么用，base只是在一致性和可用性间做了一个取舍， 

  base的实现方式有两种： 

按功能划分数据库
sharding碎片：

  sharding基本原理：一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列 