Apache Cassandra3.X 系列，第 1 部分 Cassnadra3.X 特性概述-2

look_w

排序方式在 Cassandra 的每一个 Row 中，所有 Column 按照 Name 自动进行排序，排序的类型有        BytesType、UTF8Type、LexicalUUIDType、TimeUUIDType、AsciiType 和 LongType，不同的排序类型，会产生不同的排序结果，如清单        1 所示。
清单 1. BytesType        排序结果{name:123,value:"hello there"}{name:832416,value:"fhefhwie"}{name:3,value:"101010101010"}{name:976,value:"cnebfeiw"}采用 LongType 排序类型，结果如清单 2 所示。
清单 2. LongType        排序结果{name:3,value:"101010101010"}{name:123,value:"hello there"}{name:976,value:"cnebfeiw"}{name:832416,value:"fhefhwie"}采用 UTF8Type 排序类型，结果如清单 3 所示。
清单 3. UTF8Type        排序结果{name:123,value:"hello there"}{name:3,value:"101010101010"}{name:832416,value:"fhefhwie"}{name:976,value:"cnebfeiw"}分区策略Cassandra 中，Token 是用来分区数据的关键。每个节点都有一个唯一的 Token，表明该节点分配的数据范围。节点的 Token 形成一个 Token 环。例如使用一致性        Hash 进行分区时，键值对将 genuine 一致性 Hash 值来判断数据应当属于哪个 Token。
根据分区策略的不同，Token 的类型和设置原则也有所不同。Cassandra（V3.10 版本）本身支持四种分区策略：

• Murmur3Partitioner：这个是默认的分区器，它是根据 Row Key 字段的 HashCode 来均匀分布的，这种策略提供了一种更快的哈希函数。
• RandomPartitioner：这个分区器也是随机分区器，基本特性和 Murmur3Partitioner 类似，只是通过 MD5          计算哈希值，可用于安全性更高的场合。
• ByteOrderedPartitioner：采用的是按照 Row Key 的字节数据来排序，这个分区器支持 Row Key 的范围查询。
• OrderPreservingPartioner：这个分区器也是支持 Row Key 范围查询的。它采用的是 Row Key 的 UTF-8 编码方式来排序。

数据副本Cassandra 在多个节点上存储副本以确保可用性和数据容错。副本策略决定了副本的放置方法。集群中的副本数量被称为复制因子，复制因子为 1 表示每行只有一个副本，复制因子为 2        表示每行有两个副本，每个副本不在同一个节点。所有副本同等重要，没有主次之分。作为一般规则，副本因子不应超过在集群中的节点的树木。当副本因子超过节点数时，写入不会成功，但读取只要提供所期望的一致性级别即可满足。目前        Cassandra 中实现了不同的副本策略，包括：

• SimpleStrategy：复制数据副本到协调者节点的 N-1 个后继节点上；
• NetworkTopologyStrategy：用于多数据中心部署。这种策略可以指定每个数据中心的副本数。在同数据中心中，它按顺时针方向直到另一个机架放置副本。它尝试着将副本放置在不同的机架上，因为同一机架经常因为电源、制冷和网络问题导致不可用。

多数据中心集群最常见的两种配置方式是：

• 每个数据中心 2 个副本：此配置容忍每个副本组单节点的失败，并且仍满足一致性级别为 ONE 的读操作。
• 每个数据中心 3 个副本：此配置可以容忍在强一致性级别 LOCAL_QUORUM 基础上的每个副本组 1 个节点的失败，或者容忍一致性级别 ONE          的每个数据中心多个节点的失败。

数据一致性Cassandra 被称为"最终一致性"，有点误导人，Cassandra 一致性是可以调整的。
那么什么是一致性？现实世界是按照一致性的级别进行衡量的，最终一致性是几种一致性模型的其中一种：

• 严格一致性（Strict          Consistency）：所有的请求必须按照线性方式执行。读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现；
• 顺序一致性（Sequential Consistency）：所有使用者以同样的顺序看到对统一数据的操作，但是该顺序不一定是实时的；
• 因果一致性（Causal          Consistency）：只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看作是对顺序一致性功能的一种优化，但是在实现时必须建立与维护因果依赖图，是相当困难的；
• 管道一致性（PRAM/FIFO          Consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序感知到，而从不同使用者中来的写操作则无需保证顺序，就像一个一个的管道一样。相对来说比较容易实现；
• 弱一致性（Weak          Consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性，是全局可见的，且只有当没有写操作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据；
• 释放一致性（Release Consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区，释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者          acquire 该对象，写完后 release，acquire-release 之间形成了一个临界区，提供释放一致性也就意味着当 release          操作发生后，所有使用者应该可以看到该操作；
• 最终一致性（Eventual          Consistency）：所有的复制都会在分布式系统内部传播数据，但是需要花点时间，最终所有节点的副本数据会实现一致。当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，也就是说，使用者在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求，需要用户可以接受读出陈旧数据；
• Delta 一致性：系统会在 Delta 时间内达到一致。这段时间内会存在一个不一致的窗口，该窗口可能是因为日志迁移的过程导致的。

最终一致性的几种具体实现：

• 读不旧于写一致性（Read-your-writes consistency）：使用者读到的数据，总是不旧于自身上一个写入的数据。
• 会话一致性（Session Consistency）：比读不旧于写一致性更弱化。使用者在一个会话中才保证读写一致性，启动新会话后则无需保证。
• 单读一致性（Monotonic Read Consistency）：读到的数据总是不旧于上一次读到的数据。
• 单写一致性（Monotonic Write Consistency）：写入的数据完成后才能开始下一次的写入。
• 写不旧于读一致性（Writes-follow-reads Consistency）：写入的副本不旧于上一次读到的数据，即不会写入更旧的数据。

Cassandra        把一致性级别的决定权交到了客户端手中，这意味着客户决定每一次操作的一致性级别，即决定写入操作过程中集群内部必须有多少份副本完成才能响应读请求。如果客户设置的一致性级别的值小于设置的副本数量值，那么即便一些节点宕机，更新依然成功。