写
cassandra除了轻量级事务，不支持别的事务。cassandra是追加写，写的速度非常快。cassandra还有hint日志，这个数据库总是可写的，而且单个列的写操作是原子的。
hint并不是一定写在协调节点，一般是写在下线节点的某个非副本的邻居节点。
写一致性
ANY：写hint也算成功
ONE：写hint和memtable才算成功。
commitlog文件名格式：CommitLog-<version>-<timestamp>.log的模式命名。
version是commitlog格式的一个整数。cassandra 3.0的版本提交日志的格式是6。org.apache.db.commitlog.CommitLogDescriptor可以根据cassandra版本查到commitlog版本。
SSTable
每个keyspace有一个目录，每个目录下面有对应的表的目录，目录名由表名+UUID组成的，UUID是用来区别不同schema的表，因为表结构可能会变。表的目录下面是SSTable。
SSTable包含多个文件，这些文件采用通用的命名规则：
<version>-<generation>-<implementation>-<component>.db
version是一个两字符序列，表示SSTable格式的主\次版本。可以在org.apache.io.sstable.Descriptor
类中了解不同的SSTable格式版本。
generation 是一个索引数，每次为一个表创建一个新的SSTable时，索引数就会递增。
implementation 是实现org.apache.io.sstable.format.SSTableWriter接口的一个引用。比如cassandra 3.0，这个值是“big"，会引用org.apache.cassandra.io.sstable.format.big.BigFormat类中的”Bigtable 格式“
component包含多种，3.0为例：
*-Data.db
存储实际的数据的文件，cassandra备份只保留这些文件。
*-CompressionInfo.db
提供Data.db文件压缩相关的元数据，包含有关未压缩的数据长度，块偏移量和其他压缩信息的信息
*-Digest.adler32
包含*-Data.db文件的一个校验和
*-Filter
包含这个SSTable的布隆过滤器
*-Index.db
提供相应的*-Data.db文件中的行和列的偏移位置
summary.db：索引的抽样,用来加速读取的
Statistics.db：存储有关SSTable的统计信息，nodetool tablehistograms命令将使用这些信息。
TOC.txt：该文件存储对应SSTable 所有组件的列表
轻量级事务 LWT lightweight transaction
限制：
1、必须在一个分区下。
2、每个事务由一个读写组成，读后写。也叫比较和设置，只有比较成功才会完成设置。类似CAS。
3、事务失败，会提示失败，会返回尝试更新的值，可以选择重试或者撤销。比如当你期望的值和读到的值不一样。
4、不支持using timestamp
insert要用if not exist
update要用if x=y
LWT的客户端时，可以使用wasApplied()来看语句是否成功。
LWT还另外支持串行一致性：serial和local_serial。
如果在查询的时候，读取的数据是一个未提交事务的一部分的时候，它会根据串行一致性级别提交事务。
批处理
支持多个分区，限制：
1、批处理只能包含修改语句（insert，update，delete)
2、批处理具有原子性。如果一个批处理被接受，最终一定会全部成功，batchlog。（3.0之前是unbatchlog，没有batchlog）
3、一个批处理中，分区所有更新会独立完成，可能会批处理完成之前读道不同分区的修改结果。
4、批处理带LWT，只能是在一个分区内。
5、计数器修改只能用于一种叫计算器批处理的方式。计算器批处理只能包含计数器修改。
批处理（batchlog方式）可能会降低性能，带来GC压力。
批处理底层实现：
协调器接受了批处理请求后，会将批处理请求的副本发给2个节点，副本存在system.batchlog。然后协调节点执行完批处理中所有的语句后，会删除其它节点的batchlog。
如果协调器执行失败，每分钟，每个节点会检查是否有应该完成的批处理。检查的时候会检查batchlog的时间戳和超时时间，只有才超时时间之后的才会reply，这样是防止重放正在执行的批处理。超时可以通过“cassandra.batchlog.replay_timeout_in_ms”来设置，如果没有设置，默认值write_request_timeout_in_ms的两倍。如果reply成功，会删掉对应的batchlog。
发给2个节点batchlog，存储batchlog的节点的选择其实只是找若干个尽可能不在同一个机架上的节点，主要是为了可靠性。
总结：
如果batch log写入失败，那么批处理全部失败。
如果batch log写入成功，即使某个写没有成功，cassandra也会（在gc_grace_seconds之前）一直回放batch log，保证最终全部成功。
注意：
表的gc_grace_seconds配置会影响batch的回放。在回放batch时，会检查涉及的所有表的gc_grace_seconds，如果当前时间已经超出了其中某个表的gc_grace_seconds，则整个batch都不会回放直接删除。另外，如果表的gc_grace_seconds为0，会收到警告提示。
失败：默认50k，batch_size_fail_threshold_in_kb
告警：默认5k，batch_size_warn_threshold_in_kb
counter因为不是幂等操作，不支持原子性的batch
正常写和批处理写会有并发问题。
LWT 超时后，后台batchlog 和正常写得看下代码，应该是会导致直到gc_grace_seconds后不在重试。