来源：http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu1/

本文首先介绍了 Cassandra 服务器的配置文件各个配置项的意义，接着讨论了它的启动过程，包括 Cassandra 在启动过程中主要都完成了那些操作，为什么要执行这些操作，最终达到什么状态等。接着介绍如果在集群情况下，集群中节点如何自治理，节点间如何通信、如何 控制数据在集群中的分布等关键问题。

Cassandra 的配置详解

了解一个软件的配置项的意义是使用这个软件的前提，这里详细介绍 Cassandra 的配置文件（storage-config.xml）中各个配置项的意义，这其中包含有很多配置参数，我们可以对其进行调整以达到理想的性能。为了节省篇 幅这里没有列出 storage-config.xml 文件的内容，你可以对照着这个文件看下面的内容。

ClusterName

Cluster Name 代表一个族的标识，它通常代表一个集群。这个配置项在 Cassandra 没有存储数据时就必须指定，当 Cassandra 第一次启动后，它就会被写到 Cassandra 的系统表中，如果你要修改 Cluster Name 必须要删除 Cassandra 中数据。

AutoBootstrap

这个配置项看起来十分简单，但是如果你对 Cassandra 没有深入了解的话，恐怕不知道当你改变这个配置项时 Cassandra 可能会发生什么？

我们知道 Cassandra 集群是通过维护一个自适应的 Token

NoSQL 存储提供了关系数据库的一个灵活的、可扩展的替换物，而且在众多诸如此类的存储中，Cassandra 是广受欢迎的选择之一。本文将超越众所周知的一些细节，探讨与 Cassandra 相关的不太明显的细节。您将检查 Cassandra 数据模型、存储模式设计、架构，以及与 Cassandra 相关的潜在惊喜。

Apache Cassandra 简介在数据库历史文章 “What Goes Around Comes Around”中，Michal Stonebraker 详细描述了存储技术是如何随着时间的推移而发展的。实现关系模型之前，开发人员曾尝试过其他模型，比如层次图和有向图。值得注意的是，基于 SQL 的关系模型（即使到现在也仍然是事实上的标准）已经盛行了大约 30 年。鉴于计算机科学的短暂历史及其快速发展的步伐，这是一项非凡的成就。关系模型建立已久，以至于许多年来，解决方案架构师很容易为应用程序选择数据存 储。他们的选择总是关系数据库。

诸如增加系统、移动设备、扩展的用户在线状态、云计算和多核系统的用户群之类的开发已经导致产生越来越多的大型系统。Google 和 Amazon 之类的高科技公司都是首批触及规模问题的公司。他们很快就发现关系数据库并不足以支持大型系统。

为了避免这些挑战，Google 和 Amazon 提出了两个可供选择的解决方案：Big Table 和 Dynamo，他们可以由此放松关系数据模型提供的保证，从而实现更高的可扩展性。Eric Brewer 的 “CAP Theorem”后来官方化了这些观察结果。它宣称，对于可扩展性系统，一致性、可用性和分区容错性都是权衡因素，因为根本不可能构建包含所有这些属性的系统。不久之后，