走进cassandra 之一 CAP和分布式

文章来源：http://blog.csdn.net/qinzhihu/article/details/8621545

我决定share一下我的cassandra学习成果，写一些博客，跟大家共同分享一下，准备写10篇文章，内容分别涉及

分布式存储概述及CAP,
数据模型,
分区器，
副本机制，
存储机制，
数据读写删，
最终一致性，
gossip,
cassandra的实际应用，
学习总结。

先写第一篇，先说咋理解分布式。

这术语解释起来拗口，举个例子就比较好理解了。
比如说参与cloudtask这个项目的人，有好几拨，有王薇 team，有徐超 team， 有韶涵 team， 有田萌 team, 有红艳 team.
为啥分成几拨人来做呢？
为啥不是james大侠（CTO）一力承担？

因为james智慧再高超，本领再强大，也没有办法一个人处理所有事情。
计算机里有两个词，一个叫纵向扩展，一个叫横向扩展，james加班加点看代码，这个是纵向扩展，这个扩展是有限的，扩展到24个小时，就到头了。
因为此，较为可行的办法是横向扩展，就是如前所说的，分成几拨人来做，这就是分布式了。

分布式的优点是大大的，最明显的就是可以同时处理很多事情，可以同时响应很多请求。
分布式万岁！

且慢！
啥东西也不是光有优点，分布式的缺点也是大大的。
这缺点，其实很容易想到，刚才的例子中，工作分了几拨人来做，每人都是James吗？ ＮＯ。每人都会有自己的认知，每人的认知都不同，分成５波人来做，５波人就有５个认知，所以要怎么办呢？

沟通。

需要花费不少时间精力来沟通，这就是分布式的缺点。

沟通到大家认识在一个水平，这叫同步。
沟通的时候有部分人没有完全理解，这叫信号丢失。
沟通的时候，发现开发组和测试组思路完全不一样，这就等同于俩数据中心。

如上所述，分布式的优点大大的，缺点也是大大的，下面就是你如何取舍了。
想要鱼还是想要熊掌。

为了让你取舍有个标准，有位大师研究出一个理论，ＣＡＰ理论。

这位大师就是EricBrewer教授，他提出,在设计和部署分布式应用的时候,存在三个核心的系统需求：

C: Consistency 一致性

A: Availability 可用性

P:Partition Tolerance分区容错性

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

总而言之，三个只能取其二。

对应的业界的名言就是　一个软件，可以很好，也可以很快，也可以很便宜，但是这三个，你永远只能要求两个。

那么ＣＡＰ到底是咋个回事呢？
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（可用性不仅包括读，还有写）
● 分区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务.
对比我们上面的例子，比如james写了一个push的需求，你不管去问王薇还是韶涵，结果必须是一样的。
可用性就是，即使今天徐超请假了，工作仍不能耽误，项目继续进行。
分区容忍性，典型的例子就是，如果中美之间海底电缆断了，北京和总部已经不能沟通，你这项目还能继续往下做。
就像我们说过的，这三个特性，你只能要俩。

在数据库的世界里面，关系型数据库讲究的是 ACID，什么意思呢？
原子性(Atomicity).
事务中的所有操作,要么全部成功,要么全部不做.
一致性(Consistency)
在事务开始与结束时,数据库处于一致状态.
隔离性(Isolation).
事务如同只有这一个操作在被数据库所执行一样.
持久性(Durability).
在事务结束时,此操作将不可逆转.

在分布式领域，有一个对应的模型叫 BASE.

Basically Available（基本可用）
Soft state（柔性状态）
状态可以有一段时间不同步，异步
Eventually consistent（最终一致）
最终数据是一致的就可以了，而不是时时一致

我们使用的 mysql, 遵循的是 ACID， 现在使用的  cassandra,遵循的是BASE。
BASE的基础，就是CAP理论。
cassandra在CAP里面，取的是AP，舍的是C，注意：并不是完全不要C，而是要了一个弱化的C。
也就是最终一致，不是时时一致。