结构简介
Cassandra 被设计成可以处理跨多个节点的大数据量工作负载，没有单点故障。它的体系结构是基于这样的理解，系统和硬件故障可以和确实发生。Cassandra解决这种故障的方式是，采用点对点的分布式系统，把数据均匀的分布在集群的所有节点之中。每一个节点通过点对点的通信协议gossip，来频繁的和集群中的其他节点交换自己的状态信息。一个顺序写的文件commit log在每个节点上捕获写操作，以保证数据的持久性。同时数据会被索引，然后写入到一个叫做memtable内存结构里，这类似于写回缓存。每当这个内存结构满了，数据就会被写进磁盘一个叫做SSTables的数据文件里。所有的写入都会自动分区并在整个集群中复制。Cassandra定期的合并SSTables，采用一种称作compaction的过程，丢弃过期数据，删除墓碑数据。为了确保整个集群所有数据保持一致，采用了不同的修复机制。
Cassandra是一个分区行存储数据库，行通过主键被组织成表格。Cassandra的架构允许任何被授权的用户连接任何数据中心的任何节点，并使用CQL语言访问数据。为方便使用，CQL使用了和SQL类似的语法和操作表格数据的方法。开发者可以通过cqlsh,DevCenter,和应用语言的驱动程序来访问CQL。通常，一个集群的每个应用有一个由很多table组成的keyspace。
客户端的读或写请求可以发送到集群中的任何节点。当一个客户端发送请求连接到一个节点时，该节点作为该特定客户端的协调者(coordinator)。Coordinator扮演着客户端应用程序和所请求的数据节点之间的代理服务器的角色。协调者基于集群的配置，决定环中的哪些节点应该收到该请求。
主要的结构
• 节点
你存储数据的地方。这是Cassandr的基础组件。
• 数据中心
相关节点的集合。一个数据中心可以是一个物理的数据中心，或者是虚拟的数据中心。不同的工作负载应该使用独立的数据中心，无论是物理的或虚拟的。复制是由数据中心设置的。使用独立的数据中心，可以防止Cassandra的事务受到其他工作负载的影响，保持互相之间请求有更低的延时。取决于复制因子，数据可以写入多个数据中心。数据中心必须永远不会跨越物理位置。
• 集群
一个集群包含一个或多个数据中心。它可以跨越物理位置。
• Commit log
为了持久化，所有数据首先写入commit log里。当它所有的数据都被刷新到SSTables以后，它可以存档，删除或回收。
• SSTable
排序字符串表(SSTable)是一个不可变的数据文件，Cassandra会定期的把memtables写入进来。SSTables只能追加，在磁盘上顺序存储的，而且由每个Cassandra表格保持着。
• CQL 表
表行获取的有序列的集合。一个表由列组成，并有一个主键。
Cassandra配置的主要组件
• Gossip(流言协议)
一个点对点通信协议，用来发现和共享Cassandra集群中其他节点位置和状态信息。Gossip的信息也在每个节点上持久化在本地，这样当一个节点重启的时候就能马上使用。
• 分区器
一个分区器决定哪个节点接收数据的第一份副本，以及如何把其他的副本分配到集群的其他节点上。每一行数据通过一个主键唯一标识，可能有相同的分区键(partition key)，但是会包含不同的聚集列(clustering columns)。分区器利用哈希函数从每一行的主键中提取token值。分区器使用这个token值，决定集群中的哪些节点接收这些行的副本。Murmur3Partitioner是新的Cassandra集群默认的分区策略，几乎在新集群所有的案例中都是正确的选择。
你必须为每个节点设置分区器和分配虚拟节点的值。你分配的这个token的数量是由系统的硬件能力决定的。如果你不使用虚拟节点，那就需要配置initial_token。
• 复制因子
集群的整个副本的总数。副本因子为1，意思是每一行只有一个副本，只存在于一个节点上。副本因子为2，意思是每一行有两个副本，每一个副本存在于不同节点上面。所有的副本是同等重要的，没有主副本和从副本。每一个数据中心都需要定义一个副本因子。一般来讲，你应该把复制策略设置成大于1，但不超过集群的节点数量。
• 副本放置策略
Cassandra的副本数据存储在多个节点上确保可靠性和容错性。复制策略决定要将副本放置在哪个节点上。数据的第一个副本是仅仅就是第一份备份，它在任何意义上都不是唯一的。在大部分部署中，强烈推荐NetworkTopologyStrategy策略，因为当未来需要扩展时，它更容易扩展到多个数据中心。当创建一个keyspace时，你必须指定副本放置策略和副本的数量。
• Snitch(告密者)
snitch 把一组机器分为了数据中心和机架(拓扑结构)，复制策略用于放置副本。
当你创建集群的时候，必须配置snitch。所有的snitch使用一个动态的snitch层，用来监控性能和选择最好的副本来读。它是默认启用，建议在大多数部署中使用。在cassandra.yaml配置文件中为每一个节点配置动态snitch的阀指。
默认的SimpleSnitch并不识别数据中心或者机架的信息。只有在部署单数据中心或者在公共云的单个区域的时候才使用它。建议生产中使用GossipingPropertyFileSnitch。它定义了一个节点的数据中心和机架，并使用流言协议(gossip)传播这些信息到其他节点。
• cassandra.yaml配置文件
设置集群的初始化属性，缓存表的参数，性能调优和资源利用，超时设置，客户端连接，备份和安全的主要配置文件。
默认情况下，一个节点在cassandra.yaml文件里配置数据存储的文件路径。
在生产环境中集群部署，你可以把commitlog-directory的路径修改成和data_file_directories.不同磁盘下面。
• 系统keyspace和table属性
你在每一个keyspace或者每一个table上的配置属性都会保存起来，基础编程或使用
一个客户端应用程序，如CQL。
相关参考
在71页cassandra.yaml配置文件
相关信息
在68页安装位置
节点间通信(gossip)
Gossip是一个点对点通信协议，在该协议中，节点定期交换他们自己的和他们所知道的其他节点的状态信息。Gossip进程每秒运行一次，和集群中多达三个以上的节点交换状态信息。这些节点交换关于自己的和通过流言获取到的其他节点的信息，所以所有的节点很快了解到集群中所有其他节点的信息。一个gossip有一个关联的版本，所以当他在gossip交换信息期间，旧的信息在一个特定的节点上会被最新的状态覆盖掉。
为了防止在gossip通信期间出现问题，在一个集群所有节点上使用相同的种子节点，在节点第一次启动的时候尤其重要。默认情况下，一个节点会记住它已经通过gossiped协议通信过的其他节点。种子节点的指定没有其他目的，绝不是因为新节点加入集群而自启动gossip进程。种子节点没有单点故障，在集群的操作中没有其他特殊的目的，除了引导节点。
注意：在有多个数据中心的集群中，最好从每个数据中心中选出至少一个节点作为种子节点的一员。
为了容错性，建议每个数据中心指定一个以上的种子节点。否则，在引导一个节点启动的时候，gossip需要和其他数据中心通信。不建议把每个节点都当成种子节点，因为增加了维护的难度和降低了gossip的性能。Gossip优化并不是很关键，建议不要使用太多种子节点(一个数据中心大概3个左右)。
故障检测和恢复
故障检测是一种通过gossip的状态和历史在本地确定系统中的其他节点是否已经关闭或已恢复的方法。Cassandra利用这个信息来避免路由客户端的请求在任何时候到达不可达节点(Cassandra也可以通过动态告密者snitch来避免路由客户端到达那些虽然在线，但是性能差的节点)。
Gossip的过程跟踪其他节点的状态，既有直接的(节点直接的Gossip过程)也有间接地(节点通过二手的、三手的或者更多手来通信)。标记一个节点是失败的没有一个固定临界值，Cassandra使用了一个动态增长机制来计算一个节点的临界值，而且还要考虑网络性能，工作负载和历史状况。在gossip协议在交换信息的过程中，每个节点保持着一个滑动窗口，记录集群中其他节点的gossip消息到达的时间。通过配置phi_convict_threshold属性，调整故障探测器的灵敏度。值越小，反应迟钝的节点就越可能被标记为宕机，值越大，导致节点故障的短暂故障的可能性越小。大多数情况下使用默认值，当使用亚马逊的EC2的时候，把它增大到10或者12(由于经常遇到网络阻塞)。在不稳定的网络环境中(比如说EC2有时候)，把值增大到10或者12可以防止假失败。不建议设置成大于12和小于5.
节点故障可能由多种原因导致的，比如硬件故障和网络中断。节点中断往往是短暂的，但是可以持续较长时间。因为一个节点中断很少意味着永久离开集群，它不会自动的从环中永久删除。其他节点将定期尝试重新建立与失败的节点的联系，看看他们是否恢复。要永久性地更改集群中的节点的成员身份，管理员必须明确的使用nodetool工具来把节点从Cassandra集群中添加或删除。
当一个节点在中断后返回联机时，它可能错过了本应写到它上面的副本数据。修复机制的存在会恢复丢失数据，如暗示切换和nodetool repair手动修复。中断的长度将决定使用哪种修复机制来保持数据的一致性。
数据分布和复制
在Cassandra里，数据的分布和复制是一起的。数据是由表组织的，并且通过主键来决定将数据存储在哪个节点上。副本是行的备份。当数据第一次写的时候，它也被称为第一个副本。
Factorsinfluencing replication include:
影响复制的因素包括：
• 虚拟节点:将数据所有权分配给物理机器
• 分区器:分区整个集群的数据
• 复制策略:决定每行数据的副本数量
• 嗅探器:定义复制策略用来放置副本的拓扑信息
一致性哈希
一致性哈希允许数据在集群中分布，当添加或删除节点时，尽量减少重组。一致性哈希是基于分区键来把数据分区的。(想看分区键和主键的解释，请看Cassandra 2.2和以后版本的CQL数据模型的例子)
例如，如果你有以下数据：
| name | age | car | gender |
| jim | 36 | camaro | M |
| carol | 37 | bmw | F |
| johnny | 12 |
| M |
| suzy | 10 |
| F |
Cassandra为每一个分区键分配一个哈希值：
| Partition key | Murmur3 hash value |
| jim | -2245462676723223822 |
| carol | 7723358927203680754 |
| johnny | 6723372854036780875 |
| suzy | 1168604627387940318 |
集群中的每一个节点负责一个哈希值的范围。
图：集群中四个节点的哈希值
Cassandra根据分区键的哈希值和节点负责的哈希值范围，把数据分配到不同的节点上。例如，在一个四个节点的集群中，数据的分布如下所示：
| Node Partition | Start range | End range | Partitionkey | Hash value |
| A | 9223372036854775808 | -4611686018427387904 | johnny | -6723372854036780875 |
| B | -4611686018427387903 | -1 | jim | -2245462676723223822 |
| C | 0 | 4611686018427387903 | suzy | 1168604627387940318 |
| D | 4611686018427387904 | 9223372036854775807 | carol | 7723358927203680754 |
虚拟节点
虚拟节点，也称作Vnodes，可以更容易的实现在更细的粒度下分发数据，如果计算出token值。在Cassandra里，虚拟节点简化了很多的任务：
•token值是自动算出来的，然后分配到每一个节点上
•当添加和删除节点时，重新平衡一个集群是自动完成的。当一个节点加入集群，它承担集群中其他节点的一部分数据的责任。如果一个节点出现故障时，负载均匀的分散到集群中的其他节点。
•重建一个死亡节点速度更快，因为它涉及到集群中其他的每一个节点。
•集群中的每一个机器的虚拟节点的比例可以被指定，那么不管是比较小的还是比较大的计算机都可以用来组建集群。
有关更多信息，请参考文章Virtual nodes in Cassandra 1.2。在已存在的集群上面配置虚拟节点，请参考Enabling virtual nodes on anexisting production cluster的102页。
数据是如何分布在集群中(使用虚拟节点)
Cassandra1.2之前，你必须计算，然后为集群中每一个节点分配一个token值。每个节点通过他的哈希值来确定在环中的节点位置，和它的部分数据。在Cassandra 1.2和后来的版本中，每个节点允许有多个token值。最新的范例叫做虚拟节点(vnodes)。虚拟节点允许每个节点在集群中拥有大量的小的token分布范围。虚拟节点也是用一致性哈希算法来分发数据，但是不需要token生成和分配。
图：虚拟和单token的架构
最上面的一幅图表示没有虚拟节点的集群。在这个范例中，每个节点分配了一个代表了在环中的位置的token值。每个节点存储的数据是由范围在上个节点和指定值之间的分区键的token值决定的。
每个节点也可以包含集群中其他节点的每一行的副本。举个例子，如果副本因子是3，那么E的副本会分布到5号和6号和1号节点上。注意，一个节点拥有在环空间上一个连续的分区范围。
最下面一幅图显示了有虚拟节点的环。在一个集群里，虚拟节点是随机选取的，而且是不连续的。行的位置是由分区键的哈希值决定的，在每个节点的很多较小的分区范围内。
数据副本
Cassandra在多个节点上面存储副本来保证可靠性和容错性。一个副本策略决定了副本放在哪些节点上。在节点上面的副本的总数称作复制因子。复制因子为1，意味着集群上的每行数据只有一份备份。如果包含了这一行数据的节点宕机了，这行数据就无法恢复。复制因子为2，意味着每行数据有两份备份，而且每个备份在不同节点上。所有副本是同等重要的，没有主键或主副本。作为一个通用规则，副本因子不应该超过集群中的节点数。然而，你可以增加复制因子的数量，然后添加所需的节点。
两种复制策略：
• SimpleStrategy:只用于单数据中心和单机架。如果你打算使用不止一个数据中心，那么使用
NetworkTopologyStrategy
• NetworkTopologyStrategy:高度推荐使用于大多数的部署，因为当未来需要扩展时，它更容易扩展到
多个数据中心。
SimpleStrategy
只用于单数据中心和单机架。SimpleStrategy把第一份备份放在由分区器决定的节点上。余下的备份被放在环的顺时针方向的下面的节点上，而不考虑拓扑结构(机架或数据中心的位置)。
NetworkTopologyStrategy
当你已经(或者计划)将你的集群部署成多数据中心的时候，使用NetworkTopologyStrategy策略。这个策略需要指定在每个数据中心有多少个副本数量。
NetworkTopologyStrategy通过走环的顺时针方向把副本放置在同一个数据中心上，直到另一个机架的第一个节点。NetworkTopologyStrategy试图把副本放置在不同的机架，因为在同一个机架上的节点(或者类似物理分组)经常在同一时间发生故障，因为压力，冷却或者网络问题。
当决定在每个数据中心配置多少个副本的时候，两个主要考虑的因素：（1）能够满足本地读取，而不会产生跨数据中心的延迟 （2）失败的情况。两种最常用的配置多数据中心集群的方法是：
•每个数据中心两份副本：这种配置允许其中一个节点的副本组失效，并在一致性级别为1的情况下
仍然允许本地的读取。
•每个数据中心三份副本：这种配置允许其中一个节点的副本组失效，仍然有着强一致性级别LOCAL_QUORUM，或者每个数据中心多个节点失效，仍然可使用一致性级别1。
不对称复制分组也是可行的。比如说，在一个数据中心有3个副本来服务实时应用程序请求，在其
他地方使用1个副本来运行分析程序。
每一个keyspace都有一个复制策略，是在keyspace创建的时候设置的。如何创建keyspace，详见
creating akeyspace。
更多复制策略选项信息，请看126页的Changing keyspace replication strategy。
分区器
分区器决定了数据是如何分布在集群的节点上的(包括副本)。基本上，分区器通过一个行的分区键
提取出token值来，通常是通过哈希函数。然后每行数据通过这个token值来分布在集群上面的。
无论是Murmur3Partitioner还是RandomPartitioner都是用token值来帮助把数据均匀的分配到每个
节点上面，均匀的分配数据从整个环中的所有的表和其他的组例如keyspace。这个分布真的很均匀，
即使表使用不同的分区键，比如用户名或者时间戳。此外，对于集群的读和写请求分布的也很均匀，
负载平衡被简化，因为哈希值的范围的每个部分平均接收相同的行数。有关更详细的信息，请参见
第14页的Consistenthashing。
两种不同分区器的主要差别是生成哈希值的方式。RandomPartitioner使用了加密哈希的方式，这需
要比Murmur3Partitioner花费更多的时间生成。Cassandra并不真的需要一个加密哈希，所以使用
Murmur3Partitioner导致性能提高3-5倍。
Cassandra提供了以下的分区器，都可以在cassandra.yaml文件里设置：
• Murmur3Partitioner(默认的)：基于MurmurHash的哈希值，数据均匀的分布在集群里。
• RandomPartitioner:基于MD5的哈希值，数据均匀的分布在及群里
• ByteOrderedPartitioner:基于词汇的关键字节，保持数据的有序分布。
Murmur3Partitioner在Cassandra 1.2和后来的版本中是默认的分区策略，几乎在所有的情
况下对于新集群都是正确的选择。然而，分区器是不兼容的，用一个分区器分区的数据不能简单的
转换成另一个分区器。
注：如果你使用虚拟节点(vnodes)，你就不需要计算token值。如果你不使用虚拟节点，你必须计
算token值分配给cassandra.yaml文件里的initial_token参数。见108页的生成token方法和你使
用的分区器类型。
Relatedinformation相关信息
安装位置在68页
Murmur3Partitioner
Murmur3Partitioner是默认的分区器。Murmur3Partitioner提供了更快的哈希算法和比
RandomPartitioner更好的性能。Murmur3Partitioner可以使用虚拟节点。然而，如果你不使用虚拟
节点，你就必须用生成token的方法计算token值。
在新的集群中使用Murmur3Partitioner分区器，你就不能改变现有集群的分区器。
Murmur3Partitioner使用了MurmurHash方法。这种哈希算法创建了分区键的64位哈希值。
哈希值的可能范围在-2∧63和+2∧63-1.之间。
使用Murmur3Partitioner的时候，你可以用CQL的token方法浏览所有行。
RandomPartitioner
RandomPartitioner是Cassandra1.2之前版本的默认分区器。它是向后兼容的。
RandomPartitioner可以使用虚拟节点(vnodes)。然而，如果你不使用虚拟节点，你必须用Generating
tokens.描述的方法来计算token值。RandomPartitioner把数据均匀分布在各个节点上面，使用
的是行健的MD5哈希值。哈希值的可能范围在0到2∧127-1之间。
使用RandomPartitioner的时候，你可以用CQL的token方法浏览所有行。
ByteOrderedPartitioner
Cassandra为有序分区提供了ByteOrderedPartitioner。它是向后兼容的。这个分区器按照行的关健
字节来排序的。你是通过查看数据分区键的实际值来计算token值的，使用的是一种领先的十六进
制表示的字符。比如说，如果你想把行按照字母顺序分区，你可以使用A的十六进制数41分配给A
的token值。
使用顺序分区键，允许通过主键来顺序扫描。这意味着，你可以扫描行，虽然你只是通过传统的索
引移动光标。例如，如果你的应用程序使用用户的名字作为分区键，那么你就可以扫描那些名字在
Jake和Joe之间的用户。这种类型的查询在RandomPartitioner中是不可能的因为里面的主键
是按照MD5哈希值的顺序存储的(不按顺序)。
虽然有序分区器有能力对行范围扫描听起来是一个可取的特点，但是使用表索引可以实现相同的功
能。
不推荐有序分区器的理由如下：
困难的负载平衡
需要更多的管理开销来平衡集群负载。有序分区器需要管理员根据分区键分布的大概情况来手动计
算分区范围。在实践中，一旦被加载，就需要积极移动节点的token值来适应数据的实际分布情况。
顺序写可能会导致热点
如果你的应用程序倾向于在同一个时间里写或者更新一个顺序的行，那么写操作可能不会分散到集
群中，而是会集中到一个节点上。在程序处理时间戳数据的时候，这经常成为一个问题。
多表的负载不平衡
如果你的应用程序有多个表，那么很有可能这些表有不同的行健和不同的数据分布。有序分区器可
能导致在一个集群中，一个表的平衡会导致另一个表有热点和分布不平均。
告密者(Snitches)
Snitch决定了节点属于哪个数据中心和机架。他们告诉Cassandra网络拓扑，这样一来，路由请求
更有效率，而且允许Cassandra把机器分组到数据中心和机架里来分布副本。具体而言，复制策略
是基于新的告密者提供的信息来存放副本的。所有的节点必须返回到相同的机架和数据中心。
Cassandra也最好不要在同一个机架有多个副本(在物理位置上来说是没有必要的)。
注:如果你改变了告密者，你可能需要执行额外的步骤，因为告密者会影响副本的存放位置。参考124页的Switching snitches。
动态告密者(Dynamic snitching)
Monitors the performanceof reads from the various replicas and chooses the best replica based on thishistory.
默认情况下，所有告密者还是用了一个动态snitch层，用来监视读延迟，如果可能的话，让路由请
求远离性能差的节点。动态告密者是默认启用的，建议在大多数部署中使用。有关如何工作的信息，见Dynamicsnitching in Cassandra: past, present, and future。在cassandra.yaml文件中为每个节点配置动态告密者的临界值。有关更多信息，参见14页的故障检测和恢复中列出的属性。
简单告密者(SimpleSnitch)
The SimpleSnitch is usedonly for single-data center deployments.
SimpleSnitch(默认的)只在单数据中心的部署中使用。它不识别数据中心或机架信息，只用于单数据中心部署或者公共云的单一区域。它把策略顺序当成相近的，这样当禁用读恢复时，它可以提高缓存局部性。
使用SimpleSnitch，你在创建keyspace时要使用SimpleStrategy策略，还要指定复制因子。
RackInferringSnitch
RackInferringSnitch决定了在机架和数据中心的相近的节点，假设分别对应于节点IP的第三和第二个字节。这种告密者最好用于比如写一个自定义的告密者的类(除非这恰好符合你的部署)。
PropertyFileSnitch
Determines the locationof nodes by rack and data center.
这种告密者决定的距离由机架和数据中心决定的。它使用了位于cassandra-topology.properties文件中的网络详细信息。当使用这种告密者，你可以定义的你的数据中心的名字为你任何想要的名字。确保数据中心的名字和keyspace中定义的数据中心的名称相关联。集群中的每一个节点都应该在cassandra-topology.properties文件中有描述，而且这个文件应该在集群中每个节点上都完全一样。
步骤
如果你有不一致的IP和两个物理数据中心，每个数据中心有两个机架，还有第三个逻辑上的数据中心用来复制分析数据的，cassandra-topology.properties文件可能看起来像这样：
注:数据中心和机架名是区分大小写的
# DataCenter One
175.56.12.105=DC1:RAC1
175.50.13.200=DC1:RAC1
175.54.35.197=DC1:RAC1
120.53.24.101=DC1:RAC2
120.55.16.200=DC1:RAC2
120.57.102.103=DC1:RAC2
# DataCenter Two
110.56.12.120=DC2:RAC1
110.50.13.201=DC2:RAC1
110.54.35.184=DC2:RAC1
50.33.23.120=DC2:RAC2
50.45.14.220=DC2:RAC2
50.17.10.203=DC2:RAC2
#Analytics Replication Group
172.106.12.120=DC3:RAC1
172.106.12.121=DC3:RAC1
172.106.12.122=DC3:RAC1
#default for unknown nodes
default=DC3:RAC1
GossipingPropertyFileSnitch
这种告密者是生产中推荐的。它使用本地节点的机架和数据中心的信息，在cassandra-rackdc.properties中定义的，而且是通过流言协议(gossip)和其他节点传播信息的。
GossipingPropertyFileSnitch的配置包含在cassandrarackdc.properties文件里。
要使用GossipingPropertyFileSnitch配置一个节点，编辑cassandra-rackdc.properties如下：
•定义包含此节点的数据中心和机架。默认配置：
dc=DC1
rack=RAC1
注:Datacenter and rack names are case-sensitive.数据中心和机架名是大小写敏感的。
• 为了节省带宽，添加prefer_local=true选项。这个选项告诉Cassandra，当通信不在不同的数据中心的时候，使用本地的IP地址。
从PropertyFileSnitch迁移到GossipingPropertyFileSnitch
允许从PropertyFileSnitch迁移，GossipingPropertyFileSnitch使用cassandratopology.properties文件。迁移完成后删除该文件。更多关于迁移的信息，参考124页的Switching snitches。
注:当cassandra-topology.properties文件存在时，GossipingPropertyFileSnitch总是去加载它。从新集群上或者任何从PropertyFileSnitch迁移过来的集群上的每个节点删除该文件。
Ec2Snitch
在亚马逊EC2的单一集群部署中使用Ec2Snitch，在上面，集群中所有节点都是在单一区域。
在EC2的部署中，区域的名称可以看做数据中心的名称，可用区域可以看做一个数据中心里的机架。比如说，如果一个节点在us-east-1区域，us-east就是数据中心名称，而1就是机架的位置(机架对于副本的分布很重要，但是对于数据中心命名不重要)。由于私有IP的使用，这种告密者并不跨区域使用。
如果你只是使用单数据中心，你不用指定任何属性。
如果你需要多数据中心，.在cassandra-rackdc.properties文件中设置dc_suffix选项。忽略其他的行。
比如说，在us-east区域里的每一个节点，在cassandrarackdc.properties文件里指定数据中心：
注:数据中心名称是区分大小写的。
• node0
dc_suffix=_1_cassandra
• node1
dc_suffix=_1_cassandra
• node2
dc_suffix=_1_cassandra
• node3
dc_suffix=_1_cassandra
• node4
dc_suffix=_1_analytics
• node5
dc_suffix=_1_search
这将影响该区域的三个数据中心：
us-east_1_cassandra
us-east_1_analytics
us-east_1_search
注:在这个例子中数据中心命名的规矩是基于工作负载。你可以使用其他规则，比如DC1, DC2或者100, 200。
Keyspace 策略选项
当定义你的keyspace strategy options时，使用EC2的区域名称，比如``us-east``作为你的数据中心名称。
Ec2MultiRegionSnitch
Use theEc2MultiRegionSnitch for deployments on Amazon EC2 where the cluster spansmultiple regions.
在亚马逊EC2上面的集群跨越多个区域的时候，使用Ec2MultiRegionSnitch部署。当使用Ec2MultiRegionSnitch时，你必须要同时配置cassandra.yaml和cassandrarackdc.properties文件。
为跨区域通信配置cassandra.yaml
Ec2MultiRegionSnitch使用broadcast_address选项指定的公共IP允许跨区域连接。配置每个节点如下：
1. 在cassandra.yaml文件中，把listen_address设置成私有节点的IP地址，broadcast_address设置成节点的公共IP地址
这就允许一个EC2区域上的Cassandra节点可以绑定另一个区域的节点，从而可以支持多个数据中心。对于区域内的通信，Cassandra在建立连接后切换到私有IP。
2. 在cassandra.yaml文件里种子节点的地址设置成公共IP。私有IP在网络中是不可路由的。例如：
seeds: 50.34.16.33, 60.247.70.52
为了在EC2的每个种子节点中找到共有IP：
$ curl http://instance-data/latest/meta-data/public-ipv4
注:不要使所有节点都变成种子节点,参考13页的Internode communications (gossip)
3. 确保公共IP防火墙上，storage_port和ssl_storage_port是开的状态。
跨区域通信配置告密者
在EC2部署中，区域名被视为数据中心名称，可用区域被视为一个数据中心里的机架。例如，如果一个节点在us-east-1区域，us-east就是数据中心名称，1就是机架位置。(机架对于副本的分布很重要，但是对于数据中心命名不重要)
对于每一个节点，在cassandra-rackdc.properties文件中指定他的数据中心。dc_suffix选项定义了由告密者使用的数据中心。其他行被忽略。
The data center namingconvention in this example is based on the workload. You can use other
conventions, such asDC1, DC2 or 100, 200. (Data center names are case-sensitive.)
在下面的例子中，有两个数据中心，每个数据中心是由它的负载来命名的。这个例子中的数据中心的命名规则是基于它的工作负载的。你也可以使用其他的规则，比如DC1, DC2或者 100, 200。(数据中心的名称是区分大小写的)
| Region: us-east | Region: us-west |
| Node and data center: • node0 dc_suffix=_1_cassandra • node1 dc_suffix=_1_cassandra • node2 dc_suffix=_2_cassandra • node3 dc_suffix=_2_cassandra • node4 dc_suffix=_1_analytics • node5 dc_suffix=_1_search
This results in four us-east data centers: us-east_1_cassandra us-east_2_cassandra us-east_1_analytics us-east_1_search | Node and data center: • node0 dc_suffix=_1_cassandra • node1 dc_suffix=_1_cassandra • node2 dc_suffix=_2_cassandra • node3 dc_suffix=_2_cassandra • node4 dc_suffix=_1_analytics • node5 dc_suffix=_1_search
This results in four us-west data centers: us-west_1_cassandra us-west_2_cassandra us-west_1_analytics |
Keyspace 策略选项
当定义你的keyspace策略选项时，使用EC2区域名，比如``us-east``作为你的数据中心名称。
相关信息
Install locations 在68页。
GoogleCloudSnitch
使用GoogleCloudSnitch在跨一个或多个区域的google云平台上面部署Cassandra。这个区域被视为数据中心，可用区被视为集群中的机架。所有的通信发生在同一个逻辑网络内的私有IP地址上。
区域名称被视为数据中心的名称，区被视为一个集群中的机架。比如说，如果一个节点在us-central1-a区域，us-central1就是数据中心的名称，a是机架的位置。(机架对于副本的分布很重要，但是对于数据中心命名不重要)这种告密者可以跨多区域工作，而不用额外的配置。
如果你仅仅使用单数据中心，你不需要制定任何属性。
如果你需要多数据中心，在cassandra-rackdc.properties文件中配置dc_suffix选项。其他行忽略。
例如，对于在us-central1区域里的每个节点，在cassandrarackdc.properties文件里指定数据中心：
注:数据中心名称是区分大小写的
• node0
dc_suffix=_a_cassandra
• node1
dc_suffix=_a_cassandra
• node2
dc_suffix=_a_cassandra
• node3
dc_suffix=_a_cassandra
• node4
dc_suffix=_a_analytics
• node5
dc_suffix=_a_search
注:数据中心和机架名称是区分大小写的
CloudstackSnitch
Use the CloudstackSnitchfor Apache Cloudstack environments.
在Apache Cloudstack的环境中使用CloudstackSnitch。因为在Apache Cloudstack中，区域的命名是自由形式的，这种告密者使用被广泛使用的<country> <location> <az>符号。
147
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
