hadoop学习笔记之二：分布式系统中的CAP理论

清疚 2022-07-15 04:40 108阅读 0赞

from:http://divinedm.iteye.com/blog/2252845  
  
首先，**CAP理论**描述的对象是一个**分布式系统**，其中   
**C：**从客户端来的读请求访问任何一个分布式系统节点，一定能读到最近的一次写请求的结果   
**A：**访问任何一个还存活的分布式系统节点，一定能够在一个时间范围内返回一个肯定的结果（成功或者失败，不能是超时或者错误）   
**P：**分布式系统允不允许不同节点间的网络消息丢失。

关于P特性，他的概念不像A和C那样直观，网上书上有很多错误的理解。想弄明白请读下面这段话。   
  
关于P特性我有话要说，一个常见的定义，你肯定非常熟悉：“如果网络异常将一个分布式系统分成了不能通信的两个子组，那么P特性就是要求分布式应用在每一个子组内都能正常处理请求”，这个定义并不是特别的准确，我稍后解释。网络上还有很多中文文章都是抄来抄去再加上抄的人自己的错误理解的例子就太多了，不胜枚举，甚至还有更夸张明显是错误的版本，比如<从paxos到zookeeper>中分区容错的错误定义Page11，该书将P特性定义成“分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务”，简直就是胡说八道。想弄明白P特性，还是要看英文文档。这里推荐一个链接[http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/][http_blog.cloudera.com_blog_2010_04_cap-confusion-problems-with-partition-tolerance]，这篇文章援引了2002 SIGACT paper中对p的准确定义。即P特性本质上描述的是对网络的一个限制要求--网络中允不允许节点间消息传递丢失。如果你的分布式系统允许网络的P特性，那么你必然不能同时满足一致性和可用性（试想，网络出现问题，如果还想保证不同group的数据一致，势必服务需要报错，从而不满足可用性。如果追求可用，在给定时间内有成功响应，那么也就失去了一致性），如果不允许，那么是能做到一致性和可用性的。满足P特性就是要求你在C和A中必须做出取舍，换一个等式也许更容易理解   
Possibility of Network Partitions => not(availability and consistency)   
这样的等式没有CAP现在的3选2这么简洁，但这也是很多人都错误理解CAP的原因所在。回过头来再看我提到的那个非常熟悉的定义，它看上去更像是在描述A特性（如果一个写请求到了某一个group，它会如何响应？）   
  
上面这三点对CAP分别得定义是正确理解cap theory的精髓所在！！！！！   
  
再回到流传最多的白话版本，Brewer的CAP理论证明了：**对于任何一个分布式系统，最多只能满足cap三点中的两点，不可能同时满足全部。**   
  
这是因为，从实践的角度来看，网络是一个不稳定的存在，对于一个分布式系统而言，如果网络出现问题，系统就不能服务，这显然是不能接受的，因此，P特性往往是分布式系统首先需要满足的条件。   
  
以此为基础，我们接下来看一下下面两种组合   
  
**1 CP **

系统追求了C特性和P特性，也就是容忍了A的不足。也就是说，如果节点间网络出现问题，为了追求数据的一致性，允许读请求超时或者返回错误。   
来个例子加深理解，考虑一个分布式系统由n1、n2两个节点构成，如果n1、n2之间的网络出现了问题，导致n1、n2数据同步停止，此时一个readrequest过来访问到n2节点，n2需要和n1协商谁的数据是最新的，但是由于网络中断，一直不能得出协商的结论，最后以超时或者错误返回给客户端（具体是超时还是错误由应用方而定，并没有要求）   
  
**2 AP **  
系统追求了A特性和P特性，也就是允许C的不足。也就是说，如果节点间网络出现问题，为了每个节点都可以及时响应不报错，那么就允许了读请求拿得不是最新更新后的数据。   
来个例子加深理解，和上面一样的分布式系统，如果n1、n2之间的网络出现了问题，导致数据同步停止。这时候一个readrequest过来访问n2节点，由于不需要和n1协商谁的数据最新，因此n2可以直接响应返回，不会超时或者报错，但是返回的数据就可能不会是最新的了，也就失去了c特性

[http_blog.cloudera.com_blog_2010_04_cap-confusion-problems-with-partition-tolerance]: http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/