不生产博客，只是官网的搬运工
https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/kudu_transaction_semantics.html
这篇自认为翻译的最差的，主要对数据库并发控制理解的差，容日后再修改吧
贴一篇大佬对kudu paper的笔记
https://zhuanlan.zhihu.com/p/26798353
这是简单的介绍对于kudu的事务和一致性。kudu的核心理念是在不牺牲性能或适配不同系统的能力下提供简单、strong的事务。kudu的事务和架构受spanner和calvin系统的启发。
kudu当前允许下面的操作：
a.scan是读操作，遍历多个tablet并且以不同的一致性级别或正确性保证，scan可以执行time-travel读，也就是说，你可以设置一个之前的scan timestamp并且返回那个timestamp时间点时的数据
b.写操作是在一个tablet的多个副本中，一组rows被insert、update或者delete，写操作没有单独的"read sets"，也就是说，不scan已经存在的数据在写入之前（也就是说写只是写，不会读之前的数据），写入仅仅与将要改变的行的先前状态有关，写入无需用户显示的"commit"，相反，它们在完成之后被系统自动的commited。
虽然kudu被设计acid，但多tablet的事务至今仍未实现。所以下面的讨论重点在单tablet的写和多talbet的读
单tablet写操作
kudu采用mvcc和raft协议，kudu中每个写操作必须遵循以下顺序:
1.tablet的leader获取将要改变行的所有锁
2.leader在写操作提交之前分配一个写入时间戳对于副本，这个时间戳将被写到mvcc的写tag
3.在多数副本确认写入后，row将改变
4.更改完成后，原子的使并发的读写可见
所有的tablet分区遵循相同的流程，因此，如果一个写操作被分配时间戳n和改变rows x，第二个写操作时间m>n保证看到x的新值
锁的获取和时间戳的分配按照严格的顺序是强一致的通过所有副本遵循的协议，因此，通过时钟分配的写操作的时间戳是有序的，相对别的写操作在同一副本。换句话说，写有严格的顺序。
多tablet写操作
kudu不支持跨多个tablet的事务，但是，可以一致性的快照读取
来自客户端的写入可能在内存中缓存直接它们被刷新并且发送到tablet server。当客户端的session被刷新时，对于每个tablet的row被批处理在一起，然后发送到tablet server主机（tablet副本是leader）。由于没有多-tablet事务，所以每个tablet处理一个单独的独立写操作用它自己的时间戳，然而，客户端api提供配置对分配的时间戳和写入多个tablet来约束
kudu设计了externally一致性，当操作多个tablet甚至多个data center保持一致性，这意味着如果如果一个写操作修改 A tablet的x，并且后面的操作修改了B tabletd的y，如果你想如果可以看到y，必须看到x，这种对于很多例子都是重要的，比如，如果kudu存储的是点击流数据对于以后的分析， 并且两个相邻的点击存到了不同的tablet，后续的点击应该分配后面的时间戳，以便知道他们的因果关系
client_propagated一致性
kudu默认的外部一致性，这种一致性使从单个客户端的写入自动外部一致性，如果两次点击由两个不同的客户端提交的，程序必须手动传时间戳从一个客户端到另一个客户端
官网还列了两个api，只写java的了
Call AsyncKuduClient#getLastPropagatedTimestamp() on client a
propagate the timestamp to client b,
and call AsyncKuduClient#setLastPropagatedTimestamp() on client b.
读scan操作
scan可能会涉及到多个tablet，当server收到scan请求，会先对mvcc状态做快照，然后根据用户的读取模式进行处理，有以下两种模式
read_latest
默认的模式，server对mvcc做完快照，立刻读，仅仅"Read Committed"
read_at_snapshot
这种模式下，scan是一致和可重复的，快照的时间戳由server选择，或者用户指定，server等知道该时间戳是“safe”，也就是早于该读取的写入都完成，这种模式加外部一致性，使kudu有严格序列化的语义对于读写
反正这2种，默认的scan性能最好