侯波林的blog

原文: http://www.kafka0102.com/2010/04/86.html
此外:
http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html
这篇文章也非常详细的说明了CAP理论.

CAP
CAP理论是由Brewer远在2000年的PODC会议上提出来的。CAP指的是：Consistency、Availability和Partition Tolerance，下面简述此三者：

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

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

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

对于CAP三者，Brewer给出的结论是三者在分布式环境中不能鼎力，一个分布式系统只能有限的实现两者要求，并且这个结论又被另一高人证明了一番。
一致性问题

一致性可分为强一致性和弱一致性，弱一致性又称为最终一致性。

在单机环境中，强一致性可以由数据库的事务保证。但在多机环境中，强一致性就很难做到。尽管可以使用2PC来实现分布式事务，但它的低性能（很多情况下满足不了可用性需求）使得不适合于互联网应用。这种强一致性效果的取得，其实是让提交处理过程同步化。

在多机环境中，通过使提交处理半同步半异步、或者全异步，取得最终一致性效果。例如数据库中的主从复制，在提交时就是主库同步从库异步，这对从库复制进度落后不多的场景很简单有效，但在从库落后主库很多时，如果应用还从从库读数据，就会读出脏数据，可以通过监控从库复制进度来选择读哪个从库以避免这个问题。在NOSQL模式下，以Dynamo为例，可以通过确定NRW的不同取值，可以做到同步、半同步半异步、或者全异步的效果。

最终一致性使得数据的提交效果具有延时性，而在一定的延时性范围内（比如1秒以内），应用的可用性就是OK的，比如提交后在客户端通过JS等停一段时间刷新页面就是要取得这种效果。
像数据库这样的主从系统有着广泛的应用，它很适合于提交压力不会使得从库复制明显落后的场景。它的缺点是，当主从提交压力增大、或者存在耗时长的提交命令时，从库复制进度会明显落后于主库。在Cache+DB的应用场景下，Cache的填充时机和策略也会受到主从模式影响。如果在一个Session 中提交DB后作废Cache，而由后续的（或并发的）另一个Session来再次设置Cache、并且数据是从从库获取，就很有可能缓存住脏数据，如果 Cache时间很长，那问题可能就很严重了。可以变通的策略是，在一个Session中提交DB后不是作废Cache，而是更新Cache，并且数据是从主库获取或者直接从应用环境获取。主从的另一个问题是，它有提交单点，但是，如果主从能满足应用需要，在具有完备的主备切换的保证下，这个单点问题并不见得有多大。

因为Dynamo的时兴，对等系统成为另一种选择。对等系统解决了单点问题，有着高分区容忍性，但它的效果仍得商榷。NRW的不同取值会影响读写数据效果，多点提交带来的冲突解决也是个问题，尽管通常采用高版本替换低版本的粗暴策略。现在的NOSQL对等系统存储的是简单的kv，并且可以采用加机器来扩容，所以性能方面应该是可接受的（尽管常见的单机kv存储性能要比数据库高很多，但在对等系统中，因为其复杂性，换算下来单机的性能并不见得有多高）。

SQL和NOSQL各有其优缺点。如果存储一些实体数据并且查询提交只是根据唯一标识来，使用NOSQL也许就很合适。但像复杂的关系数据，使用 SQL就更合适些。而就提交模式来说，如果并发提交的数据隔离性不好（比如需要同时对同一个数值做更新），那么对等系统的提交冲突就会增多，数据的正确性就会受到影响。
BASE

上面提到，在分布式环境中，CAP只能取两者。但是，因为网络分区的情况不可避免，并且它对可用性有着重要影响，所以互联网中的分布式系统多在一致性方面做些折中。虽然不能达到强一致性，但可以根据应用特点采用适用的手段来达到够用的一致性效果。比如，对于微博系统，当用户新增一条消息，能够达到用户能看到刚才发的消息、而他的follower们能在尽快时间看到他新发的消息的效果就可以了。而在实现时，就可以结合同步和异步多种策略、 SQL+NOSQL多种存储方案来满足应用需要。

BASE（Basically Available、Soft state、Eventually consistent）是对CAP中的AP的延伸。

在单机环境中，ACID是数据的属性；而在分布式环境中，BASE就是数据的属性。ACID有“尖刻”之含义，所以单机环境的数据有着很高的要求。而因为分布式环境的网络分区性及复杂性，对数据也只能有“基本”的要求了。

从ACID到CAP和BASE，从单机到分布式，从SQL到NOSQL，互联网应用的大规模发展促使不断出现可替代旧方案的新技术。在技术选型方面，重要的是根据自己的应用特点选择自己能驾驭的技术。而现实的应用场景，也大多是多种技术方案的结合。