Apache Cassandra入门指南[长期连载]

jieforest

SimpleStrategy

The SimpleStrategy is the default strategy and blindly writes the data to subsequent nodes along the ring. In the previous example with a replication factor of 2, this would result in the following storage allocation.

jieforest

NetworkTopologyStrategy

The NetworkTopologyStrategy is useful when deploying to multiple data centers. It ensures data is replicated across data centers.

Effectively, the NetworkTopologyStrategy executes the SimpleStrategy independently for each data center, spreading replicas across distant racks. Cassandra writes a copy in each data center as determined by the partitioner. Data is written simultaneously along the ring to subsequent nodes within that data center with preference for nodes in different racks to offer resilience to hardware failure. All nodes are peers and data files can be loaded through any node in the cluster, eliminating the single point of failure inherent in master-slave architecture and making Cassandra fully fault-tolerant and highly available.

jieforest

Given the following ring and deployment topology:

With blue nodes (N1-N3) deployed to one data center (DC1), red nodes (N4-N6) deployed to another data center (DC2), and a replication factor of 4, Cassandra would write a row with key “lisa” as follows.

NOTE:
Cassandra attempts to write data simultaneously to all target nodes then waits for confirmation from the relevant number of nodes needed to satisfy the specified consistency level.

Consistency Levels

One of the unique characteristics of Cassandra that sets it apart from other databases is its approach to consistency. Clients can specify the consistency level on both read and write operations trading off between high availability, consistency, and performance.

jieforest

Write

jieforest

Read

jieforest

NETWORK TOPOLOGY

As input into the replication strategy and to efficiently route communication, Cassandra uses a snitch to determine the data center and rack of the nodes in the cluster.  A snitch is a component that detects and informs Cassandra about the network topology of the deployment.
  
The snitch dictates what is used in the strategy options to identify replication groups when configuring replication for a keyspace.

jieforest

The following table shows the four snitches provided by Cassandra and what you should use in your keyspace configuration for each snitch.



SimpleSnitch

The SimpleSnitch provides Cassandra no information regarding racks or data centers.  It is the default setting and is useful for simple deployments where all servers are collocated.

jieforest

PropertyFileSnitch

The PropertyFileSnitch allows users to be explicit about their network topology.  The user specifies the topology in a properties file, cassandra-topology.properties.  

The file specifies which nodes belong to which racks and data centers.  Below is an example property file for our sample cluster.

1. # DC1   
   
2. 192.168.0.1=DC1:RAC1
   
3. 192.168.0.2=DC1:RAC1
   
4. 192.168.0.3=DC1:RAC2
   
5. # DC2
   
6. 192.168.1.4=DC2:RAC3
   
7. 192.168.1.5=DC2:RAC3
   
8. 192.168.1.6=DC2:RAC4
   
9. # Default for nodes
   
10. default=DC3:RAC5

复制代码

jieforest

RackInferringSnitch

The RackInferringSnitch infers network topology by convention.  From the IPv4 address (e.g., 9.100.47.75), the snitch uses the following convention to identify the data center and rack:

jieforest

EC2Snitch

The EC2Snitch is useful for deployments to Amazon’s EC2.  It uses Amazon’s API to examine the regions to which nodes are deployed.  It then treats each region as a separate data center.

EC2MultiRegionSnitch

Use this snitch for deployments on Amazon EC2 where the cluster spans multiple regions. This snitch treats data centers and availability zones as racks within a data center and uses public IPs as broadcast_address to allow cross-region connectivity. Cassandra nodes in one EC2 region can bind to nodes in another region, thus enabling multi-data center support.