Apache Cassandra介绍

Apache Cassandra 是一个开源的，分布式的，无中心的，具有弹性并且可以扩展性，高可用性，容错性，一致性可调，面向列的数据库。

它基于Amazon Dynamo的分布式设计和Google BigTable的数据模型，它有Facebook创建，目前在很多最流行的网站上应用。 Cassandra是分布式的，这意味着它能够运行在很多机器上面，然后呈现给用户一个统一的整体的样子。在事实上，在一个节点上运行Cassandra没有多大的意义。它的很多设计和实现让系统不仅可以在多节点上运行，更为多机架部署进行了优化，甚至一个Cassandra集群可以运行在分散于各地的多个数据中心上，可以放心地把数据写到集群中的任意一个机器上，Cassandra都会得到数据。 对于很多存储系统（如MySQL，BigTable）,一旦开始扩展它就要把某些节点设为主节点，其他则为从节点。但是，Cassandra是无中心的，也就是说每个节点都是一样的，没有节点用于承担特殊的管理任务。与主从结构相反，Cassandra使用的是P2P协议，而且使用gossip来维护存活或死亡节点的列表。

无中心这一事实意味着Cassandra不会存在单点失效。Cassandra集群中的所有节点的功能完全一样，有时这被叫做“服务器对称”。与你见过的MySQL，BigTable这样的主从结构式的系统不同，这是因为Cassandra的所有节点的工作内容都是相同的，从根本上就没有一个特殊的机器作为主节点来承担协调任务。

总之无中心架构有两个关键的优势，不仅比主从结构更简单，而且可以避免系统宕机。比起主从结构的数据存储系统来说，无中心架构的维护更方便，因为所有节点都可以一视同仁。这也就意味着你不必要为扩展来考虑更多的东西，搭建一个50个节点的系统和搭建一个单节点的系统没什么区别。也没有什么配置上的特别需要来支持单节点扩展。更进一步，对于主从结构来说主节点很容易出现单点失效来支持节点扩展。更进一步对于主从结构来说，主节点很容易出现单点失效（SPOF）。要想避免单点失效，常常需要增加系统的复杂度，构成多主节点。而因为所有的Cassandra节点都是一样的，损失任何一个节点对于系统服务都没什么大影响。

综上所述，由于Cassandra是分布式的，无中心的，因此他不会有单点失效，能拥有高可用性。 从一般的结构的角度考虑，系统的可用性是满足请求的能力来量度的。但计算机可能会有各种各样的故障，从硬件故障到网络中断都有可能。计算机都可能发生这种情况。当然有某些非常复杂或者复杂昂贵的计算机可以自己应付很多情况，它们一般都会用在硬件上的冗余，并且在发生故障事件的时候会自动响应并进行热切换。但是任何人都可能会偶然碰到以太网线断连，这时候一个单独的数据中心就会有灾难发生，这是无法避免的。所以对于一个需要高搞可用的系统，它必须有多台联网的计算机构成，并且运行于其上的软件也必须能够在集群条件下工作，有设备能够识别节点故障，并将发生故障的中断的功能在剩余系统上进行修复。

Cassandra就是高可用的。你可以在不中断系统的情况下替换故障地点，还可以把数据分布到多个数据中心里，从而提高更好的本地访问性能，并且在某以数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。 可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展行的手段，而水平扩展则需要增加更多机器每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。

弹性可扩展是指水平扩展的特性，意即你的集群可以不间断服务地扩展或缩减规模。要做到这点，集群必须能够在不大幅修改或重新配置的情况下，接收那些新加入，获得全部或部分数据的节点，让它们开始提供服务。不需要重新启动进程，不必修改应用的查询，也无需自己手工重新均衡数据分布。在Cassandra里，你只要加入新的计算机，Cassandra就会自动地发现它并开始让它工作。 当然缩减规模意味着要从集群中移走部分处理能力，当应用要迁移到别的平台上，或者应用失去用户，你不得不卖掉部分硬件的时候，你可能不得不这么做。让我们祈祷这永远不发生。不过如果发生了，使用Cassandra无需为规模的缩减而引起系统的混乱。 一致性的基本含义是读操作一定会返回最新写入的结果。考虑电子商务网站的两个客户同时要把一个商品放到他们的购物车里的情景。如果我在你刚刚拿走最后一个商品的时候也要把商品放到自己的购物车里，那么你应该得到这个商品，而我应该被告知商品已经售完了。在把状态一致地写到所有有此数据的节点的时候，这点是得到保证的。

但是天下没有免费的午餐，后面我们可以看到，扩展数据存储系统就意味着我们不得不在数据一致性，节点可用性和分区耐受性之间做某些折中。Cassandra使用的一致性常被称作是“最终一致性”，这实际有些让人误解。简单的来说，Cassandra牺牲了一些一致性来换取完全的可用性。但是Cassandra的一致性准确表述为“可调一致性”，它允许选定需要的一致性水平与可用性水平，在二者之间找到平衡。

先让我们解释一下“最终一致性”，这个词曾经引起业界的震动。

有些人对“最终一致性”的系统很不放心。

对于“最终一致性”，批评最终一致性的人有个说法。也许最终一致性对社交应用可能还可以，因为数据并非那么重要。毕竟早餐吃了一块蛋糕等等这样的数据丢了并不会太重要。但有些数据非常重要，在我的数据模型里，绝对不会允许最终一致性这种可笑的事情发生。 可是事实上，大部分流行的网络应用都在使用这一模型。它有其可取之处，这些数据对运营它们的公司来说应该是非常重要的，因为这是它们赖以生存的产品，而且这些公司在竞争如此激烈的世界里已经成长为数十亿美元盈收的巨头，拥有几十亿用户。或许真的有系统可以保障在 这样一个高流量、接入不同网络的系统里，能够得到即时有保障而且完美的一致性，不过现在还找不到这样完美的系统。

严格一致性。有时也叫做顺序一致性，是最严格的一致性要求。它要求所有读操作总是返回最新的写结果。这听起来似乎很好，好像就是我们所需要的。但是再仔细看看，我们还会看到什么？“最新的写结果”到底意味着什么？最新写给谁的？在一个单处理器的机器里，不会看出任何问题，因为无论如何操作都会逐一顺序进行。但是，当系统分布在位置分散的多个数据中心的时候就变得不那么可顺序进行。但是，当系统分布在位置分散的多个数据中心的时候就变得不那么可靠。要达到严格一致性，需要某种全局锁机制来给每个操作加上一个时间戳，不论数据位于何处，用户位于何处，也不论得到响应需要访问多少服务，而且服务还可能是分散的。

因果一致性。这种一致性模型比严格一致性稍弱。这种模型消除了幻想中的需要同步一切操作的单一的全局锁。避免了无法承受的瓶颈。因果一致性不依赖于时间戳，它使用更为语义化的方法，尝试去判断事件的原因，并按照因果关系来达到一致性。这意味着潜在相关的写操作必须被顺序读出。如果两个彼此无关的不同操作同时写同一个域，那么这些写操作可以被推断为并不是因果相关的。而如果一个操作紧接着另一个进行，这就可能是因果相关的了。因果一致性要求相关的写操作必须别顺序读出。 弱一致性（最终一致性）

最终一致性从单词的意思解释是更新最终将传播到整个分布式系统的各个角落，但这需要一定的时间。最终，所有的副本都会是一致的。

当考虑需要如何才能达到更好的一致性的情况，最终一致性可能会变得很有吸引力。在考虑一致性、可用性和分区可用性时，对于一个给定的系统……