不知大家是否已經留意到，在[ TDengine]( https://www.taosdata.com/" TDengine") 3.0 的官方文件（https://docs.taosdata.com/taos-sql/show/#）中，有了這樣一個命令 ：show transactions。顧名思義，這是“事務”。

在 Database 的語境中，滿足 ACID 屬性的資料庫操作序列即可稱為事務，它是資料庫的一個不可拆分的工作單元，包含著一個資料庫操作的序列，這些操作要麼全部執行，要麼全部不執行。換個角度也可以說，事務是為了實現 ACID 特性的一種工具。

不過在 TDengine 中，依託於“一個資料採集點一張表”的設計理念，針對表的操作都是以佇列方式逐個進行的，所以在絕大多數情況下都不需要事務機制。那 TDengine 3.0 中的“事務”是用來解決什麼問題的呢？答案就是：3.0 中的事務機制並沒有應用在業務資料上，而是針對資料庫的後設資料的，它的目的是利用事務的 ACID 特性，來強化後設資料的一致性，因此，普通使用者對此是無感知的，但是對 TDengine 的運維人員而言，意義會更大一些。

大家都知道 TDengine 3.0 是一款高效能、雲原生的分散式[時序資料庫]( https://www.taosdata.com/"時序資料庫")（Time Series Database），甚至可以支援十億級別的表數量，因此它的後設資料量是十分龐大的。那麼如果使用了事務，會不會影響 TDengine 的高效能呢？

這裡就需要結合 TDengine 2.x 時代的後設資料架構來說起了。

**一、2.x 的後設資料架構**
在 2.x 版本中，管理節點 mnode 中的 sdb 模組儲存了大量後設資料，如叢集資訊、使用者資訊、資料庫資訊、超級表資訊以及普通表資訊等。這些不同型別的資訊，會在記憶體中分別以一個 hash 表的形式來維護。其中，一些後設資料需要在管理節點（mnode）和資料節點（dnode/vnode）中分別儲存，比如超級表、普通表。所以，當對資料庫執行 DDL 操作時，需要在 mnode 上對這個 hash 表操作一次，還要再去 dnode 中的 vnode 也做一次。這裡為了效能的最佳化，TDengine 選擇以非同步的方式來完成操作。以刪表為例，當 mnode 記憶體中的 hash 表刪掉了這個表後，會立即返回成功。後續由 dnode/vnode 一側刪除自己的後設資料，達成最終一致。

因為該流程的非強一致性，可能會導致在某些極特殊情況下（比如網路不穩定），出現 mnode 與 vnode 後設資料不同步的情況（有的使用者遇到過這個錯誤資訊：“Invalid table id”）。但是如果為了強一致性而在 2.x 中引入事務機制，那麼對於存在超大規模 DDL 操作的場景來說（如刪除一張擁有百萬千萬子表的超級表），這種分散式的事務對資料庫的效能損耗又將非常之大。

那麼應該如何解決這個問題呢？我們的思路是：利用“分散式事務”，解決 mnode 和 dnode 同步時的問題，但是又不能讓其影響到資料庫的效能。

**二、3.0 的事務引入**
以此為依據，TDengine 在 3.0 中選擇把開銷最大的普通表後設資料從 mnode 中移除，完全只放在各個 vnode 中分散式儲存，這樣除了防止了上述 mnode 和 vnode 普通表後設資料不一致的現象發生，更使得 TDengine 不再具有單點效能瓶頸，解決了業界的“高基數”難題，從而可以支援十億級別的時間線。在其餘的後設資料模組中，我們則引入了事務機制，確保了這部分後設資料的 ACID 特性。

下圖是一個兩階段提交的流程，其中 Coordinator（協調者）就是 mnode，而 Participants（參與者） 就是 dnode/vnode。

建立事務後，協調者本地準備事務所需的必要資料，redo、undo 日誌等。然後向參與者們傳送事務執行請求，如果參與者們的事務執行結果皆為成功，那麼則進入提交階段，由協調者提交事務。
![](http://img.blog.itpub.net/blog/2022/10/17/5a0a73c21baba444.jpeg?x-oss-process=style/bb)

需要注意的是：如果作為協調者的 mnode 當機，那麼其他 mnode 在成為 leader 之後，會作為新的協調者繼續驅動事務的執行。也就是說，Raft 協議保證了事務的一致性和永續性。

在現在的 3.0 架構中，為了避免不同的事務操作共享資源，管理節點針對不同型別的後設資料把事務分成了幾個級別，分別為無衝突級別、全域性級別、資料庫級別以及資料庫內部級別。如果在記憶體中仍有未完成且具有相同衝突型別的事務，後執行的事務將會等待前者執行完畢再執行。

![](http://img.blog.itpub.net/blog/2022/10/17/b5d3ee1327b1fbcc.png?x-oss-process=style/bb)

最終，一個事務的執行狀態與行為是由該類後設資料本身的衝突級別和失敗策略等因素決定的，而這一切是對使用者無感知的。使用者只需知道事務在執行階段具有 PREPARE，REDO_ACTION，COMMIT，COMMIT_ACTION，ROLLBACK，UNDO_ACTION，FINISHED 7 個階段。

![](http://img.blog.itpub.net/blog/2022/10/17/f4824c685fc5697c.png?x-oss-process=style/bb)

其中，比較關鍵的地方是：在 PREPARE 階段，事務的基本資訊在不同的 mnode 間達成一致；然後在 REDO_ACTION 階段，執行 mnode 的本地操作、以及涉及的 vnode 的遠端操作。當 REDO_ACTION 的所有操作都完成後，進入 COMMIT 階段。注：REDO_ACTION 不止包含了第一次執行任務，還包括執行失敗後的重做。COMMIT 階段則負責把資料最終寫入到 SDB 對應的表中，完成持久化。在最後的 FINISHED 階段，清理 SDB 模組中事務表的相關記憶體，完成整個任務的執行或者回滾。

![](http://img.blog.itpub.net/blog/2022/10/17/01ad54e9237cccdc.jpeg?x-oss-process=style/bb)

透過 show transactions，我們可以明確瞭解到當前事務執行的階段。除了確保資料庫的安全一致之外，也給了資料庫運維人員更充足的資訊去診斷資料庫的當前狀態。不過，在絕大多數時間，show transactions 的輸出是沒有結果的，因為後設資料體量較小，所以執行速度都非常快。

總而言之，TDengine 3.0 的“事務”機制為叢集資訊、使用者資訊、資料庫資訊以及超級表資訊等後設資料帶來了 ACID 的特性保障。

而在它背後的把普通表後設資料完全遷移到 vnode 的架構變更，使得 TDengine 不再具有單點瓶頸，獲得了超強的水平擴充套件能力，如果想獲得更多的資料處理能力，只需要加入更多的資料節點即可。

在下一篇文章中，我會繼續和大家分享該變更帶來的諸多優勢，一起感受 TDengine 這款開源、高效能、雲原生的時序資料庫的架構變化之路。

> 歡迎新增小T（VX：TDengine），加入物聯網技術討論群，第一時間瞭解TDengine 官方資訊，與關注前沿技術的同學們共同探討新技術、新玩法。

------------

想了解更多 [TDengine Database]( https://www.taosdata.com/?zh"TDengine Database")的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

一文讀懂 TDengine3.0 中的事務機制

相關文章