Trafodion事務管理怎么理解

這篇文章主要介紹“Trafodion事務管理怎么理解”，在日常操作中，相信很多人在Trafodion事務管理怎么理解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Trafodion事務管理怎么理解”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Trafodion這個詞的本意是“事務”，可見項目組對事務處理的重視程度。

事務主要用來防止和處理數據出現不一致的錯誤。首先理解什么是數據一致性，給出具體的定義實在太為難筆者。還是舉個例子吧。筆者年輕時大家都知道“香港四大天王”，他們是劉德華，張學友，黎明和郭富城。我定義這四個名字是“一致的”，而“劉學友”或者“張德華”就不是一致性的數據。或者在介紹的時候不全：比如“香港四大天王是：劉德華,”，其他天王要不高興了。另外，劉德華唱過《忘情水》，如果數據庫查詢得到劉德華唱了《吻別》，也是不一致的數據。

造成數據不一致主要有兩種因素，分別用兩種事務技術解決。在Trafodion中，一個技術是日志；另一個技術是多版本并發控制MVCC。

日志

第一種造成數據不一致的因素是不可預知的故障。故障會導致正在處理數據的過程異常中斷，比如數據正在往磁盤中寫入的時候系統斷電，那么結果就是未知的，有可能寫入了不完整的數據。比如應該寫入”張學友”覆蓋原本的”劉德華”，卻只寫了”張”，剩下兩個字節沒來得及寫入，所以還是老數據，于是磁盤數據變成“張德華”，造成數據了不一致，從來沒有這個天王；或者說正在順序寫入四個人的名字，斷電了，只寫了劉德華，其他人都沒寫，也是不一致，要么4位全寫，要么全都不寫，寫一個漏掉其他算是什么意思，看不起其他天王么？

處理這類錯誤的方法是WAL日志，write ahead log。即每次寫入數據之前，先將變化寫入日志，再寫數據。這樣，如果有錯誤發生，通過查詢日志，就可以進行恢復。比如前面的例子，在將“張學友”寫入數據文件之前，先寫入日志。這樣即便發生了故障，也不會有問題，如果故障發生在寫日志的過程中，那么數據文件中依然是“劉德華”。如果故障發生在寫數據文件的過程中，那么雖然數據文件中是“張德華”，但是WAL日志中卻是正確的數據“張學友”，我們將日志replay一下，用“張學友”覆蓋“張德華”即可。
如果遇到寫中斷錯誤，則可以利用日志將做過的操作全部撤銷，比如寫入了劉德華，然后出錯了，查詢日志，發現已經寫了劉德華，那么rollback就是把“劉德華”刪除掉。
通過日志，保證了在任何錯誤情況下，事務的一致性，即ACID中的A和D。

傳統的日志技術包括Redo，undo, redo/undo等。和所有其他數據庫一樣，Trafodion采用redo/undo日志。

Trafodion采用HBase的WAL做Redo日志，當region恢復時，HBase負責回放WAL進行恢復。

在R1.0版本中，Trafodion將寫入數據緩存在內存中，提交的時候才將內存中的數據寫入磁盤，因此不需要undo日志。如果事務需要回滾，只需要將內存中的數據丟棄即可。

目前計劃在R1.2版本中，Trafodion將使用一種被稱為SSCC的最新技術，SSCC利用HBase的多版本支持存儲數據的變化歷史，以便提供repeated read隔離級別，這些數據歷史同時作為undo日志。

MVCC的并發控制方法

還有一種錯誤，靠日志也不管用，就是多個事務并發寫同一個數據，這類錯誤和我們在多線程程序中修改共享變量時發生的race condition是同一類問題。比如我們有兩個線程寫數據庫，都要更新歌曲排行榜的第一名。線程A寫入一行數據：[ singer=>劉德華, song=>忘情水]；線程B寫入另一行數據[ singer=>張學友，song=>吻別]。A和B一起寫，一種可能的寫法為A寫了歌手后被B打斷，B寫了歌手和歌曲，A恢復執行，寫入歌曲。最后變成了[ singer=>張學友, song=>忘情水]。可是張學友沒有唱過《忘情水》。

處理第二類錯誤的方法被稱為并發控制。通常有兩種解決方案，第一種是傳統的數據庫通常使用的方法，即鎖管理器；第二種是MVCC（多版本并發控制）。Trafodion采用MVCC的方法，沒有使用鎖管理器。因此在Trafodion中沒有因為鎖而引起的讀寫阻塞和死鎖問題。
MVCC的基本思想和人們使用SVN版本控制系統是一樣的，每個程序員都是一個事務，而修改的代碼就是數據庫中的表。如果用sourcesafe，那么就類似鎖管理，張三修改寫文件A的時候別人誰都不能讀寫，等張三修改完check in才行。用SVN后，如果張三正在寫文件A，他寫的是本地的一個版本，另外的人想讀，可以隨時讀；別的程序員也可以修改文件A。但是兩個人不能都commit。先commit的人成功，后commit的人需要做merge，如果兩個人修改了不同的行（類似兩個事務修改不同數據行），則一般都可以commit，SVN可以自動merge。否則就有沖突，需要第二個commit的人手動merge，或者干脆放棄(Abort)。Trafodion的MVCC方法和這個過程完全一樣。

HBase本身提供多版本服務，因此非常適合采用MVCC技術。每個寫操作都會產生一個新的數據版本，而不會覆蓋老版本數據。讀操作根據事務開始時間，讀取正確的數據版本，即數據的一個歷史快照。這避免了幻讀，提供了repeated read隔離級別的保證。筆者孤陋寡聞，竊以為MVCC是Oracle最先采用的，Oracle工程師經常對此非常自豪，因為讀不會被寫阻塞，提供了很高的并行度。后來innodb山寨了Oracle的所有實現細節，使得MySQL也擁有了類似的能力；PostgreSql則采用了和Oracle/innoDb不同的MVCC實現方法，Trafodion的實現更加類似于Postgresql，即保存多版本數據用來提供快照讀取，而非用作undo日志，然后定期進行垃圾收集，刪除過期的快照。而Oracle則利用了undo日志來作為歷史快照；前者讀取歷史版本的速度很快，因為數據和快照都在一起，但需要處理每條歷史數據，檢查它們的可見性，比較低效；Oracle則需要到undo segment中讀取歷史數據，應用undo日志對數據進行回滾，貌似會比較慢；但是不需要考慮GC的問題，而且節約了空間，因為undo空間一舉兩得。所以筆者認為Oracle/InnoDB的模式好些，但也主要還是取決于具體的應用場景，假如并發很高，讀取歷史版本的比例比讀取最近數據的頻率還要高，則PostgreSQL/Trafodion的模式應該更好，因為它們讀取快照的效率更好。
不過作者水平經驗都很有限，在這里議論其他產品有點兒心中坎坷，各位如果不以為然還請不吝賜教。

在Commit的時候，進行write-write沖突檢測。如果發現兩個并發事務同時寫一行數據，就依據”first committer win”的原則處理，第一個提交的事務成功，而其他的事務則失敗回滾。如前所述的線程A和B，A寫入歌手信息劉德華之后，被打斷，B寫入張學友唱《吻別》，這條數據不會覆蓋原始數據，而是新生成一條記錄，(有些人喜歡稱為COW)，這條記錄用線程B的事務ID標記它。這時線程A被調度回來，繼續寫入，同樣A寫的劉德華唱《忘情水》也不會覆蓋原始數據，而是新生成一條新的記錄，用A的事務ID標記。在commit的時候，Trafodion發現，這同一行數據有兩條新紀錄，根據first commit win的原則，A獲勝。所以如果線程A提交，會成功；而線程B提交的時候會報錯，回滾。最終數據庫的記錄為劉德華唱的《忘情水》。是一致的。

Trafodion目前的版本為R1.0，在今后的版本中(計劃在R1.2版本中)使能一種新的并發控制算法SSCC。SSCC是中科院的研究成果，Trafodion團隊和中科院緊密合作，即將推出這一全新的并發控制機制，SSCC提供比SnapShot Isolation更高級的隔離級別，同時對無狀態寫操作有很高效的支持。
SSCC認為SQL的寫操作有兩種：stateful的寫比如a=a+1，是有狀態的；stateless的寫，比如delete，或者覆蓋舊數據，這類寫操作和歷史狀態無關。
無狀態寫在web應用中非常普遍，比如Google的index generating。采用這一機制，Trafodion可以高效地為相關的web應用提供強大的支持。

筆者也會嘗試在后續的博客中介紹SSCC這一創新的并發控制算法。

并發控制保證了ACID中的I。
最后還有ACID的C沒有提到，是"一致"的意思，然而這個C卻不是靠事務處理器來保證的。ACID的Consistency靠數據庫的約束保證。因此筆者不喜歡用ACID來描述事務。但是這個是經典，也不得不提。

兩階段提交

對于單機的數據庫，比如MySQL，Oracle (not RAC)，SQL Server，PostgreSql (not xl版)等，以上兩個技術就完全可以實現ACID事務了。但是Trafodion是一個分布式數據庫，操作分布在集群的不同節點執行，比如兩條寫操作可能由兩個不同的ESP在不同節點運行，所以Trafodion還需要處理分布式事務。

Trafodion的事務處理器將并發控制的職責分成兩部分，TM(Transaction Manager)負責整個事務的分布式并發控制，保證事務本身的一致性；RM(Resource Manager)負責數據訪問的并發控制，保證數據的一致性。

具體來說，RM采用前面所說的MVCC技術，提供Snapshot Isolation級別的數據一致性。

在Trafodion中，每個HBase的Region都是一個RM。一個事務很可能會在多個Region上操作，比如事務需要更新兩行數據，而它們分別屬于兩個不同的Region。在這種情況下，一個事務會有多個RM參與。而HBase的Region很可能運行在不同的物理節點上，因此這是一種分布式事務。分布式事務由TM保證整個事務的一致性。

TM使用兩階段提交協議來保證分布式事務的一致性。兩階段提交是一個非常簡單直觀的協議，類似公司的秘書安排幾個人都必須參加的會議。第一階段：秘書發信給所有參與者：“周一下午3點開會，OK?”，如果所有有人都回復“OK”，則最終決定開會進入第二階段；如果有人回答no，或者有人不回答，則不開會進入第二階段；第二階段根據第一階段的結果進行不同處理，如果是開會，秘書給每個人發信: '確定周一下午3點開會'；如果不開會，秘書給每個人發信：‘不開會’。

每個事務都由一個TM發起，事務開始的時候，TM會給事務創建一個ID。此后，事務中的每一個DML操作都帶有該ID，用來在RM內部確定該讀取的數據版本。

在提交的時候，TM先進行第一階段的prepare commit，向每個RM發送prepare消息。RM在收到prepare消息時，進行write-write沖突檢測，如果有沖突則返回沖突，否則返回提交成功。TM得到所有RM的回復后進行判斷，如果所有的RM都提交成功，則該事務成功，否則事務失敗；進入第二階段，如果事務成功，TM向所有RM發送commit消息，每一個RM收到commit消息后將事務的所有操作都寫入物理磁盤，完成事務處理；如果有任何一個RM返回沖突，或者任何一個RM超時沒有反應，TM認為事務失敗，在第二階段向所有的RM發送abort消息；每個RM在收到abort消息后進行事務回滾操作。

DDL事務

從R1.1版本開始，Trafodion還支持DDL的事務處理，比如創建2個表，第一個成功，第二個失敗，回滾后，兩個表都不存在。

到此，關于“Trafodion事務管理怎么理解”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！