不完美定律

有个传说中的“不完美定律”：任何人都不能把所有好事占光。比如女人都希望未来的那位要貌比潘安、要富如盖茨、要忠诚不二。但是对不起，只能选2项。长得帅的又有钱，一定花心；有钱而忠诚的，一定是老头子；长得帅又忠诚的，一定是董永那样的穷鬼。

同样的，软件开发领域有个类似的不完美法则：

“You can have it fast, good, or cheap. But only pick two”。 即，快、好、省，只能实现2个。

这在项目管理中就是传说中的“项目管理三角”。“Fast”，就是快速交付，“Good”，就是产品质量高或做得东西多，“Cheap”, 就是成本低。要想做得又快又好，那就要付出更多money, 比如加班费或奖金激励；要不花钱又想做的快，那代价就是东西做得少或质量不高；或者不想花钱，但是要做得质量高，那对不起，就得要更长的时间。总之，“要想马儿跑，又想马儿不吃草”只有共产主义才能实现，如果经理在给员工洗脑时用这个说辞，大家千万不要相信。

其实今天重点是谈在分布式数据系统的不完美定律，即著名的CAP理论（最早由Eric Brewer于2000年在一个ACM会议上提出）。就是数据库的三个特性：Consistency（一致），Availability（可用），Partition tolerance (分区容忍)， 只能实现2个。Consistent就是所有节点都看到的是相同的数据。Availability是系统的灾难处理能力，即使某个节点出故障，数据还是能被读取。Partition tolerance：数据可以分散存储到不同的节点上，一个节点处故障，整个系统还能使用（故障的那个节点不保证能读取）。

也许有些心高气傲的同学从小就立下远大志向，决心长大后实现一个能满足这三个特性的分布式系统，摘取计算机领域上的皇冠。但是很遗憾，这个CAP理论2002年在数学上被证明是正确的（由MIT的Seth Gilbert和Nancy Lynch）。证明的过程嘛，大家有兴趣的话可以谷歌论文来拜读。

虽然三项特性不能同时达成，但是至少还是可以获得两种项特性的，目前流行的数据库实现中，可以按照这三类的两两组合来归类：

CA: 要实现一致性和可用性，就需要分布式事务的支持，比如2段式提交(2pc)。常用的关系型数据库如Mysql, SqlServer就属于这类。

CP: 要实现一致性和分区，常用的手段是sharding。但是万一某个sharding所在的阶段出现故障，那个片区的数据就不可用了。Google Bigtable和其衍生的一些产品，如mongoDB, Hypertable, Redis等属于此类。

AP: 要实现可用性和分区，就是要能保证数据在不同的节点能有冗余备份，某个节点不幸挂了，剩下的节点还能得到所有的数据信息。但是这就不能保证数据总是正确的。Amazon的Dynamo和其衍生的Cassandra、CouchDB、Voldemort等产品属于此类。

除了分布式数据库外，分布式文件系统也有类似的CAP，CA就不说了，CP如Lustre、MongoDB’s GFS的文件系统，数据分区保存，组成一个大硬盘，如果某个节点崩溃，整个系统还能运行，但是崩溃的那个节点的数据就无法读出。AP如Hadoop的DFS, 一个节点系统崩溃，整个系统能运行，所有数据都有机会读出，但是不一定保证正确性。

在实现分布式存储或架构，需要根据具体的情况来实现不同搭配，是要追求事务？还是要追求稳定的大容量？还是要追求所有数据数据全天候可访问？上帝造人都是不完美的，重点是实现其中最满足业务需要的特性，然后去此基础上尽可能提高非重要的特性。

 

转自：http://ptc.35.com/?p=123