Cassandra一致性级别ONE下全副本同步更新的疑问

我在cqlsh会话中将一致性级别设置为ONE，对Cassandra中的记录执行更新操作，并启用了追踪功能分析写入性能。

1. Keyspace创建语句 #

CREATE KEYSPACE jesi WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'}  AND durable_writes = true;

2. 更新操作语句 #

cqlsh:jesi> update reference_id set number_sequence = '0000503' where id = '54';

3. 追踪日志 #

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

4. 一致性级别确认 #

cqlsh:jesi> consistency
Current consistency level is ONE.

问题 #

尽管一致性级别设置为ONE，但从追踪日志中可以看到数据正在更新到全部三个副本（即出现3次Appending to commitlog和Adding to reference_id memtable操作）。按照一致性级别ONE的预期，是否应该仅一个副本在会话a099c320-40d4-11ee-943a-ab6b7cb26b14中接收更新，其余副本在后台获取更新而非作为同一会话的一部分？

解答 #

这是完全正常的Cassandra行为，核心混淆点在于写入一致性级别ONE定义的是客户端等待的确认数，而非实际写入的副本数：

• 一致性级别ONE仅要求coordinator节点收到至少1个副本的写入成功确认后，就立即向客户端返回操作成功，不需要等待所有副本完成写入。
• 但coordinator节点的核心职责是保证数据的最终一致性，所以它会主动把更新请求发送到所有副本（对应replication_factor=3的配置），所有副本都会执行写入操作（写入commitlog和memtable）。
• 追踪日志记录的是coordinator节点处理整个请求的完整流程，包括它与所有副本的交互，所以会看到所有副本的写入操作。客户端会话的结束时间点是在第一个副本返回确认时（对应日志里的Request complete时间），但其他副本的处理仍会在coordinator的会话流程中继续，只是客户端不需要等待这些结果。

简单来说：ONE是客户端的等待门槛，不是限制coordinator只发请求给一个副本，所有副本都会同步收到更新，只是客户端不用等全量确认。

内容的提问来源于stack exchange，提问作者user101