笔记--强一致性、若一致性、最终一致性

这两天在准备面试,今天学习了下CAP原理,顺便做个笔记加深印象:
在分布式系统中会涉及到CAP原理,来保证数据的一致性,
1.什么是CAP:
一致性(Consistency)
可用性(Availability)
分区容忍性(Partition tolerance)
CAP原理是说这三个要素最多只能同时满足两点,不可能同时兼顾三点,因此在分布式架构设计时必须进行取舍,而分布式数据系统,分区容忍性是最基本的要求,否则就失去了价值,因此只能在一致性和可用性之间取一个平衡。其实对于大多数web系统并不需要强一致性,因此牺牲一致性,换取高可用性是现在多数分布式数据库产品的方向。
牺牲一致性并不是完全不管数据的一致性,否则数据混乱了可用性再高,分布式再好也就没有了意义。牺牲一致性只是不再要求关系型数据库中的强一致性,而是只要系统能达到最终一致性即可。考虑到客户体验,这个最终一致性的时间窗口要尽可能的对用户透明,也就是需要保障‘用户感知到的一致性’。通常通过数据的异步复制来达到系统的高可用和数据的最终一致性。‘用户感知到的一致性’的时间窗口取决于数据复制到一致性状态的时间。
最终一致性(eventually consistent)
对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。一致性是因为有并发读写才有的问题,因此在理解一致性的问题时,一定要注意结合考虑并发读写的场景。
强一致性
对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性,如果能容忍后续的部分或者全部访问不到,则是弱一致性。如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

从服务端角度,如何尽快将更新后的数据分布到整个系统,降低达到最终一致性的时间窗口,是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统:

  • N — 数据复制的份数
  • W — 更新数据是需要保证写完成的节点数
  • R — 读取数据的时候需要读取的节点数

如果W+R>N,写的节点和读的节点重叠,则是强一致性。例如对于典型的一主一备同步复制的关系型数据库,N=2,W=2,R=1,则不管读的是主库还是备库的数据,都是一致的。

如果W+R<=N,则是弱一致性。例如对于一主一备异步复制的关系型数据库,N=2,W=1,R=1,则如果读的是备库,就可能无法读取主库已经更新过的数据,所以是弱一致性。

对于分布式系统,为了保证高可用性,一般设置N>=3。不同的N,W,R组合,是在可用性和一致性之间取一个平衡,以适应不同的应用场景。

  • 如果N=W,R=1,任何一个写节点失效,都会导致写失败,因此可用性会降低,但是由于数据分布的N个节点是同步写入的,因此可以保证强一致性。
  • 如果N=R,W=1,只需要一个节点写入成功即可,写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据,因此是弱一致性。这种情况下,如果W<(N+1)/2,并且写入的节点不重叠的话,则会存在写冲突  
 原文地址:https://blog.csdn.net/aosica321/article/details/48769913

相关推荐