我在Cassandra中更新了一条记录，我在cqlsh会话中将一致性设置为ONE。我已启用跟踪以分析写入性能。
CREATE KEYSPACE jesi WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'} AND durable_writes = true;cqlsh:jesi> update reference_id set number_sequence = '0000503' where id = '54';Tracing session: a099c320-40d4-11ee-943a-ab6b7cb26b14
activity | timestamp | source | source_elapsed | client
------------------------------------------------------------------------------------------------------------+----------------------------+------------+----------------+-----------
Execute CQL3 query | 2023-08-22 10:14:06.675000 | 172.17.0.3 | 0 | 127.0.0.1
Parsing update reference_id set number_sequence = '0000503' where id = '54'; [Native-Transport-Requests-1] | 2023-08-22 10:14:06.677000 | 172.17.0.3 | 2921 | 127.0.0.1
Preparing statement [Native-Transport-Requests-1] | 2023-08-22 10:14:06.681000 | 172.17.0.3 | 6190 | 127.0.0.1
Determining replicas for mutation [Native-Transport-Requests-1] | 2023-08-22 10:14:06.686000 | 172.17.0.3 | 11466 | 127.0.0.1
Sending MUTATION_REQ message to /172.17.0.2:7000 message size 94 bytes [Messaging-EventLoop-3-1] | 2023-08-22 10:14:06.688000 | 172.17.0.3 | 12989 | 127.0.0.1
Appending to commitlog [MutationStage-2] | 2023-08-22 10:14:06.689000 | 172.17.0.3 | 14357 | 127.0.0.1
Adding to reference_id memtable [MutationStage-2] | 2023-08-22 10:14:06.689001 | 172.17.0.3 | 14557 | 127.0.0.1
Sending MUTATION_REQ message to /172.17.0.4:7000 message size 94 bytes [Messaging-EventLoop-3-1] | 2023-08-22 10:14:06.690000 | 172.17.0.3 | 14955 | 127.0.0.1
MUTATION_REQ message received from /172.17.0.3:7000 [Messaging-EventLoop-3-2] | 2023-08-22 10:14:06.696000 | 172.17.0.4 | 1133 | 127.0.0.1
Appending to commitlog [MutationStage-2] | 2023-08-22 10:14:06.700000 | 172.17.0.4 | 5546 | 127.0.0.1
Adding to reference_id memtable [MutationStage-2] | 2023-08-22 10:14:06.700001 | 172.17.0.4 | 5872 | 127.0.0.1
Enqueuing response to /172.17.0.3:7000 [MutationStage-2] | 2023-08-22 10:14:06.705000 | 172.17.0.4 | 10539 | 127.0.0.1
MUTATION_REQ message received from /172.17.0.3:7000 [Messaging-EventLoop-3-1] | 2023-08-22 10:14:06.708000 | 172.17.0.2 | 1072 | 127.0.0.1
Appending to commitlog [MutationStage-1] | 2023-08-22 10:14:06.721000 | 172.17.0.2 | 23532 | 127.0.0.1
Sending MUTATION_RSP message to /172.17.0.3:7000 message size 34 bytes [Messaging-EventLoop-3-3] | 2023-08-22 10:14:06.722000 | 172.17.0.4 | 27269 | 127.0.0.1
MUTATION_RSP message received from /172.17.0.4:7000 [Messaging-EventLoop-3-3] | 2023-08-22 10:14:06.723000 | 172.17.0.3 | 78 | 127.0.0.1
Adding to reference_id memtable [MutationStage-1] | 2023-08-22 10:14:06.727000 | 172.17.0.2 | 29943 | 127.0.0.1
Enqueuing response to /172.17.0.3:7000 [MutationStage-1] | 2023-08-22 10:14:06.728000 | 172.17.0.2 | 31492 | 127.0.0.1
Processing response from /172.17.0.4:7000 [RequestResponseStage-2] | 2023-08-22 10:14:06.729000 | 172.17.0.3 | 5809 | 127.0.0.1
Sending MUTATION_RSP message to /172.17.0.3:7000 message size 34 bytes [Messaging-EventLoop-3-1] | 2023-08-22 10:14:06.738000 | 172.17.0.2 | 40877 | 127.0.0.1
MUTATION_RSP message received from /172.17.0.2:7000 [Messaging-EventLoop-3-2] | 2023-08-22 10:14:06.739000 | 172.17.0.3 | 29 | 127.0.0.1
Processing response from /172.17.0.2:7000 [RequestResponseStage-3] | 2023-08-22 10:14:06.740000 | 172.17.0.3 | 402 | 127.0.0.1
Request complete | 2023-08-22 10:14:06.711784 | 172.17.0.3 | 36784 | 127.0.0.1cqlsh:jesi> consistency
Current consistency level is ONE.即使一致性设置为ONE。在跟踪日志中，我们看到数据正在更新到所有三个副本（即3次出现Appending to commit log和Adding to reference_id memtable）。在一致性的情况下，不是只有一个副本应该接收会话a099c320-40d4-11ee-943a-ab6b7cb26b14的更新，所有其他副本都应该在后台获得更新，而不是作为同一会话id的一部分？
2条答案
按热度按时间euoag5mw1#
根据设计，请求将被发送到所有副本，而不管请求中发出的一致性级别（CL）如何。
在Apache Cassandra中，一致性级别决定了有多少副本必须确认读或写操作才被认为是成功的。
一致性级别与会话ID没有直接关系。会话ID通常用于标识客户端与服务器的会话，而一致性级别是一种配置
在您的例子中，
jesi键空间表将始终按照保存数据的定义拥有3副本。当在Apache Cassandra中使用
ONE一致性级别时，这意味着只有一个副本需要确认写入操作才能被视为成功。但是，这并不意味着只有一个副本将接收数据。它的工作原理如下：
1.写请求：当一致性级别为
ONE的写请求发出时，协调器节点（接收客户端的请求）将写请求发送给负责数据的所有副本。1.鸣谢：从客户端的Angular 来看，只有一个复制副本需要确认写入操作才被视为成功。协调器将在一个副本确认写入后立即响应客户端。
1.复制：即使只需要一个确认，写入仍然会发送到负责该数据片段的所有副本。其他复制副本最终将接收并应用写入，确保数据在所有复制副本之间保持一致。
1.* 酒店：如果任何副本停机或无法响应，协调器可以存储一个“提示”，允许它在这些副本再次可用时重放对这些副本的写入。这有助于确保最终的一致性。
会话ID在此过程中不起直接作用。它可能用于标识客户端与协调器的会话，但它不会影响数据复制到副本的方式。
总之，即使一致性级别为
ONE，负责数据的所有副本最终也会收到写入。一致性级别只是控制必须有多少个副本确认写入，才能从客户端的Angular 将其视为成功。底层复制机制确保所有副本都接收数据，从而提供最终的一致性。LOCAL_ONE | LOCAL_QUORUM作为CL值，这样当您将来向集群添加更多DC时，您的请求就不需要跨节点了。时间与应用程序的变化。v440hwme2#
你所描述和观察到的是工作作为广告。
写入请求的一致性级别决定了必须通过确认写入成功来响应协调器的副本数量。需要知道的关键是，无论副本或DC的数量如何，协调器都会将变化（写入）发送到所有数据中心的所有副本。
例如，假设我们有一个集群，其中有2个DC，每个DC有5个节点。对于所有DC的复制因子为3的密钥空间，总共有6个副本（2个DC x 3个副本/DC）。
一致性级别为
ONE的写入请求将只等待来自一个节点（最快的节点）的响应，写入将被视为成功。CL为LOCAL_QUORUM的写入请求，本地DC中的两个副本必须确认写入。相反，读请求的一致性级别决定了将为数据请求的副本数量。对于CL为
LOCAL_ONE的读请求，协调器将只查询本地DC中的一个节点。对于LOCAL_QUORUM的CL，协调器将查询两个副本（RF=3的quorum是2）--一个使用实际数据，另一个仅使用摘要请求。与您的理解相反，对所有副本的复制是实时发生的，而不是在后台。
如果您感兴趣，Apache Cassandra网站上的Dynamo Architecture页面对此进行了更详细的解释。干杯！干杯！