Cassandra 一致性 ONE 更新所有副本

问题描述 投票：0回答：1

我正在 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.1


cqlsh:jesi> consistency
Current consistency level is ONE.

即使一致性设置为

ONE
。在跟踪日志中，我们看到数据正在更新到所有三个副本（即 3 次出现 
Appending to commit log
和 
Adding to reference_id memtable
）。 有了一致性，ONE 不仅应该只有一个副本接收会话的更新 
a099c320-40d4-11ee-943a-ab6b7cb26b14
，所有其他副本都应在后台获取更新，但不作为同一会话 id 的一部分？

cassandra datastax cassandra-3.0
1个回答
0
投票

按照设计，请求将发送到所有副本，无论请求中发出的一致性级别 (CL) 如何。

在 Apache Cassandra 中，一致性级别确定有多少副本必须确认读取或写入操作才能被视为成功。

一致性级别与会话ID没有直接关系。会话 ID 通常用于识别客户端与服务器的会话，而一致性级别是一种配置

在您的情况下，

jesi
键空间表将始终根据保存数据的定义具有
3
副本。

在 Apache Cassandra 中使用 

ONE
一致性级别时，这意味着只有一个副本需要确认写入操作才能被视为成功。然而，这并不意味着只有一个副本会接收数据。

其工作原理如下：

  1. 写请求：当发出一致性级别为

    ONE
    的写请求时，协调节点（接收客户端的请求）会将写请求发送到负责数据的所有副本。

  2. 确认：从客户端的角度来看，只有一个副本需要确认写入操作才能被视为成功。一旦一个副本确认写入，协调器将立即响应客户端。

  3. 复制：即使只需要一个确认，写入仍然会发送到负责该数据的所有副本。其他副本最终将接收并应用写入，确保所有副本之间的数据一致。

  4. 提示切换：如果任何副本已关闭或无法响应，协调器可能会存储一个“提示”，以便在这些副本再次可用时重播对这些副本的写入。这有助于确保最终的一致性。

会话ID在此过程中不起直接作用。它可能用于识别客户端与协调器的会话，但它不会影响数据复制到副本的方式。

总之，即使一致性级别为

ONE
，所有负责数据的副本最终都会收到写入。一致性级别仅控制有多少副本必须确认写入，从客户端的角度来看写入才被视为成功。底层复制机制确保所有副本都能接收数据，从而提供最终一致性。

TIP：最好使用 

LOCAL_ONE | LOCAL_QUORUM
作为 CL 值，这样当您将来向集群添加更多 DC 时，您的请求不需要跨数据中心。通过更改应用程序节省时间。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.