简析Cassandra的BATCH操作

2021-09-02 00:58:29

cassandra中批量写入的操作称为batch，通过batch操作可以将多个写入请求合并为一个请求。这样有如下好处：

把多次更新操作合并为一次请求，减少客户端和服务端的网络交互。
batch中同一个partition key的操作具有隔离性。
默认的LOGGED类型可以保证batch中的所有操作要么（最终）全部成功，要么全部失败。也就是原子性。

本文介绍batch的使用和注意事项。并分析batch操作原子性的实现。

batch使用

cqlsh中使用batch

在cqlsh中如下语句可以提交一个batch（例子来自cassandra官方文档）：

BEGIN BATCH
   INSERT INTO users (userid, password, name) VALUES ('user2', 'ch@ngem3b', 'second user');
   UPDATE users SET password = 'ps22dhds' WHERE userid = 'user3';
   INSERT INTO users (userid, password) VALUES ('user4', 'ch@ngem3c');
   DELETE name FROM users WHERE userid = 'user1';
APPLY BATCH;

在java应用中使用batch

下面的例子示意了如何使用java客户端实现批量写入：

    PreparedStatement statement = session.prepare("insert into test(intcol,boolcol) values(?,?)");
    BatchStatement batchStatement = new BatchStatement(Type.UNLOGGED);
    for( int i = 0; i < 5; i++ ) {
      BoundStatement boundStmt = statement.bind();
      boundStmt.setInt(0, i);
      boundStmt.setBool(1, false);
      batchStatement.add(boundStmt);
    }
    session.execute(batchStatement);

注意事项

UNLOGGED/COUNTER batch操作不保证原子性，可能会部分成功。
batch大小（指的是所有statement的内容总的大小）不能超过batch_size_fail_threshold_in_kb，否则会失败；另外，如果batch大小如果超过batch_size_warn_threshold_in_kb，batch会成功，但会收到一个警告提示batch过大，如果日志中频繁看到这样的警告，需要考虑batch的使用是否正确。
不建议在UNLOGGED batch中包含多个partition key，因为这样虽然客户端和服务端之间的交互变少，但是coordinator和其他节点的交互并没有减少。如果partition key的数量超出了unlogged_batch_across_partitions_warn_threshold，会收到警告提示。顺便说一句，cassandra的copy命令在写入时用的就是UNLOGGED batch，在调用batch之前对请求按照key所在的节点做分组，然后再对每个分组调用batch。
表的gc_grace_seconds配置会影响batch的回放。在回放batch时，会检查涉及的所有表的gc_grace_seconds，如果当前时间已经超出了其中某个表的gc_grace_seconds，则整个batch都不会回放直接删除。另外，如果表的gc_grace_seconds为0，会收到警告提示。
如果在batch中使用了条件更新，需要注意只有所有更新操作的条件都满足时batch才会成功，只要有一个不满足batch就会失败；另外，所有更新都只能针对同一个partition key，这是因为cassandra中cas操作只能提供partition级别的一致性保证。

关于batch的原子性

UNLOGGED和COUNTER类型的batch是不保证原子性的，这种batch类型的处理是简单的把写请求分发到对应的节点上面，所以可能会出现部分成功的情况。以下分析LOGGED batch的处理，说明batch是如何做到原子性的。
简单来说，LOGGED batch的处理分三个步骤：
第一步写入batches表
batches表的结构如下：

                "CREATE TABLE %s ("
                + "id timeuuid,"
                + "mutations list<blob>,"
                + "version int,"
                + "PRIMARY KEY ((id)))")

我们可以看出一个batch的所有mutations都在一行记录里面。这样的设计保证了batchlog写入的原子性，要么成功，要么失败。
第二步分发mutation
这一步处理和UNLOGGED batch差不多，就是把每个mutation操作发送到他对应的节点上面去。比UNLOGGED batch多出的一个步骤是，如果所有mutation都成功执行了，会删除到batches表中对应的记录。
第三部回放batchlog
如果第二步失败了，cassandra仍然可以保证batch最终成功。有一个线程池会以10s执行一次replayFailedBatches回放batch。如果batch中的请求全部执行成功就会删除batch。
一些细节：

batch中的mutate要么成功发到endpoint，要么成功写入hint并落盘然后才会被删除。
为了避免回放正在执行中的batch，回放时只会选择BATCHLOG_REPLAY_TIMEOUT之前的记录。BATCHLOG_REPLAY_TIMEOUT的值可以通过系统属性“cassandra.batchlog.replay_timeout_in_ms”来设置，如果没有设置，默认值write_request_timeout_in_ms的两倍。

从上面的分析可以看出，batch的原子性主要体现在：