Cassandra的读写请求，主要包括两部分，client端如何找到节点，请求何时成功返回，以及本地的读写是如何完成的，本地的读写，会在后续的博客中不断给出。本文主要解析前面两个问题。 【正文开始】 Cassandra集群中的所有节点都是对等的。客户端的读写请求可能会发送给集群中的任一节点。当客户端连接了某一个节点，并且开始发送读写请求，那个这个节点因为承担了客户端的操作，就被称为“协调者”。 协调者的工作是充当客户端应用和存储实际请求数据的节点之间的代理。协调者根据数据划分、复制的策略来决定，将实际的读写请求发送到确定的节点。 写请求 协调者会将些请求发送到所有应该存储这条数据的节点（也就是所有的复制份数都会写）。只要这些节点都处在可用的状态，它们都会接受到写的请求，无论客户端的consistency level设置为哪一种。那Consistency level（一致性等级）主要的作用是什么呢？写的一致性等级主要是用来决定有几个节点成功返回了，才认为这次写请求成功了。 举个例子，一个集群有10个节点，复制份数设置为3。那意味着，每次写请求都要写入三个节点。如果客户端写的一致性等级设置为ONE，第一个完成写操作的节点就会发送成功响应给协调者节点，这样协调者的发送成功响应给客户端应用。一致性等级ONE意味着，如果被请求的三个节点中有两个宕机了，这两个是不会处理写请求的。但同样返回成功。如果写操作丢失了，稍后会通过Cassandra的数据一致性机制进行恢复：hinted handoff，read repir或者anti-entropy node repair。这三种机制，第一种有时间窗口限制，第二种有一定概率完成，第三种需要手工触发，需要深入了解这三种机制，才会保证在运维过程中不丢数据。
具体某一节点上，数据是如何写入的，会再后续的文章中介绍。 跨数据中心的些请求 在跨中心部署的情况下，Cassandra通过在每一远程的数据中心选择一个节点作为协调者的角色来优化写得性能。这每一个协调者负责将写请求发送到及群众需要写入的节点。与客户端应用连接的协调者节点只需要将写请求转发到自己所属集群中的一个节点上既可。 如果设置了一致性等级为ONE或者LOCAL_QUORUM，有一个数据中心的协调者节点确认成功既可。这种方式保证了不会因为地理位置的原因影响了客户端请求响应时间。 
读请求 对于读请求，会有两种不同类型的读请求从协调者节点发送到真正存储数据的节点：直接读取数据的请求和后台的read repair（读修复）请求。直接读取数据的读请求会根据客户端设定的读一致性等级来选取节点读取数据，节点数量也是由此决定。后台读修复的请求会发送到哪些没有接受到直接读取请求的节点。读修复请求主要是为了保证所有复制份之间是一致的。 因此，协调者会根据一致性等级的设定首先找到需要访问的节点。然后，协调者会将请求发送到当前反映最迅速的节点。接受到请求的节点会将请求数据返回。如果发送请求到多个节点，那每一个节点的返回数据会在内容中进行比较是否是一致的。如果不是，会根据时间戳，返回最新的数据给请求的客户端。 为了保证频繁被读取的数据是一致的，协调者也会发送请求到其他的节点，并将返回的数据进行a比较。如果他们是不一致的，会将最新的数据写入过期数据的节点。这个过程就是读修复。读修复可以针对每一个column family进行配置，配置项为：read_repair_chance，而且默认是打开的。而且，这个配置项并不是打开关闭这么简单，它是一个概率，比如0.1，0.2等。意思是每10次读操作，会有一次或者两次触发读修复。这个充分考虑了对读性能的影响。 举例，集群的复制份数设置为3，读一致性等级为QUORUM，也就是说，在三份中，必须要读到两份才算成功。假设读到的数据具有不同的版本，最新的那一份数据会作为响应返回（其实也不一定，往往需要对数据进行合并）。在后台，第三份数据会与前两份数据进行一致性检查，如果需要，最新的数据会写入数据过期的节点。 具体本地如何读数据，如何合并，会在后续的博客中介绍。 【完】
转载于：https://www.cnblogs.com/sing1ee/archive/2012/06/29/2765052.html