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的原子性主要体现在：
- 如果batch log写入失败，那么batch的操作全部失败。
- 如果batch log写入成功，即使某个mutation没有成功，cassandra也会（在gc_grace_seconds之前）一直回放batch，保证最终全部成功。
入群邀约
为了营造一个开放的 Cassandra 技术交流，我们建立了微信群公众号和钉钉群，为广大用户提供专业的技术分享及问答，定期开展专家技术直播，欢迎大家加入。另外阿里云提供免费Cassandra试用：https://www.aliyun.com/product/cds
钉钉群入群链接：https://c.tb.cn/F3.ZRTY0o
微信群公众号：
