不生產博客，只是官網的搬運工
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性能最好