分布式系统的可靠、延时、一致性等问题是一般性问题，不局限于数据库，而Cassandra提供了一个很好的解决思路。
Cassandra号称能做到跨数据中心的数据库访问的高效访问，它的实现方式其实是把延时、吞吐量与一致性的权衡交给了用户来选择。Cassandra提供了两种访问级别: LOCAL_QUORUM和EACH_QUORUM，其中
因此不难想象EACH_QUORUM由于需要跨datacenter访问，所以延时会很大，且带宽、吞吐量相应的也会性能降低。
---------------ref：http://www.packtpub.com/article/apache-cassandra-working-multiple-datacenter-environments
Most applications use Cassandra for its capability to perform low-latency read and write operations. When a cluster is all located in a single physical location, the network latency is low and bandwidth does not (typically) have a cost. However, when a cluster is spread across different geographical locations, latency and bandwidth costs are factors that need to be considered. Cassandra offers two consistency levels: LOCAL_QUORUM and EACH_QUROUM. This recipe shows how to use these consistency levels.
The consistency levels LOCAL_QUORUM and EACH_QUORUM only work when using a datacenter-aware strategy such as the NetworkTopologyStrategy. See the recipe Scripting a multiple datacenter installation for information on setting up that environment.
READ.LOCAL_QUORUM returns the record with the most recent timestamp once a majority of replicas within the local datacenter have replied.
READ.EACH_QUORUM returns the record with the most recent timestamp once a majority of replicas within each datacenter have replied.
WRITE.LOCAL_QUORUM ensures that the write has been written to <ReplicationFactor> / 2 + 1 nodes within the local datacenter (requires network topology strategy).
WRITE.EACH_QUORUM ensures that the write has been written to <ReplicationFactor> / 2 + 1 nodes in each datacenter (requires network topology strategy).
Each datacenter-aware level offers tradeoffs versus non-datacenter-aware levels. For example, reading at QUORUM in a multi-datacenter configuration would have to wait for a quorum of nodes across several datacenters to respond before returning a result to the client. Since requests across a WAN link could have high latency (40ms and higher), this might not be acceptable for an application that returns results to the clients quickly. Those clients can use LOCAL_QUORUM for a stronger read then ONE while not causing excess delay. The same can be said for write operations at LOCAL_QUORUM, although it is important to point out that writes are generally faster than reads.
It is also important to note how these modes react in the face of network failures. EACH_ QUORUMwill only succeed if each datacenter is reachable and QUORUM can be established in each.LOCAL_QUORUM can continue serving requests even with the complete failure of a datacenter.
ref：http://www.datastax.com/docs/0.7/operations/datacenter
---------------------------------------------
毫无疑问，当使用EACH_QUORUM时，可以保证全局数据的一致性；这点不再赘述。
但是，使用LOCAL_QUORUM时，又如何保证全局数据一致性？例如两个DATACENTER“同时”（在足够短的时间内）写一条数据时，就很可能出现数据冲突。
举个DataStax Enterprise的例子：
The required end result is for users in the US to contact one datacenter while UK users contact another to lower end-user latency. An additional requirement is for both of these datacenters to be a part of the same cluster to lower operational costs. This can be handled using the following rules:
ref：http://planetcassandra.org/blog/post/datastax-developer-blog-multi-datacenter-replication-in-cassandra/
----------------------------
上面都是写入的情况，当读的时候，其实也是类似的处理。Cassandra对读操作也提供了LOCAL_QUORUM和EACH_QUORUM的两个级别，对于这两个级别的定义是类似的。读操作存在一致性问题是因为各个datacenter之间是异步复制的，所以数据更新后的某个时间窗口（数秒），在不同datacenter读取到的数据是可能不一样的，所以才需要这样的一致性级别要求。一般情况下，DataStax的例子中，他们说吧“reading and writing”都固定到一个datacenter中了。
如果你也看过google的spaner， 你会发现虽然google用了原子钟这种高大上的工具，把写的延时“稍微”降了一些，但是，同样的道理，它也提供了很大的空间给用户配置，例如选择离用户最近的datacenter，讲“大多数”的副本放在离“大多数”用户最近的地方。 我归结为，无论多强大，都无法超越光速的限制。
Cassandra 如何处理跨数据中心的数据库延时问题,布布扣,bubuko.com
原文：http://www.cnblogs.com/zwCHAN/p/3853765.html