mysql分布式事務,undo和redo,java學習這塊必須要懂?

2021-01-07 怡子科技

011.什麼是分布式事務

要了解分布式事務,必須先了解本地事務。

1.1.本地事務

本地事務,是指傳統的單機資料庫事務,必須具備ACID原則:

原子性

所謂的原子性就是說,在整個事務中的所有操作,要麼全部完成,要麼全部不做,沒有中間狀態。對於事務在執行中發生錯誤,所有的操作都會被回滾,整個事務就像從沒被執行過一樣。

一致性

事務的執行必須保證系統的一致性,在事務開始之前和事務結束以後,資料庫的完整性沒有被破壞,就拿轉帳為例,A有500元,B有500元,如果在一個事務裡A成功轉給B50元,那麼不管發生什麼,那麼最後A帳戶和B帳戶的數據之和必須是1000元。

隔離性

所謂的隔離性就是說,事務與事務之間不會互相影響,一個事務的中間狀態不會被其他事務感知。資料庫保證隔離性包括四種不同的隔離級別:

Read Uncommitted(讀取未提交內容)

Read Committed(讀取提交內容)

Repeatable Read(可重讀)

Serializable(可串行化)

-持久性

所謂的持久性,就是說一旦事務提交了,那麼事務對數據所做的變更就完全保存在了資料庫中,即使發生停電,系統宕機也是如此。

因為在傳統項目中,項目部署基本是單點式:即單個伺服器和單個資料庫。這種情況下,資料庫本身的事務機制就能保證ACID的原則,這樣的事務就是本地事務。

概括來講,單個服務與單個資料庫的架構中,產生的事務都是本地事務。

其中原子性和持久性就要靠undo和redo 日誌來實現。

02undo和redo

在資料庫系統中,既有存放數據的文件,也有存放日誌的文件。日誌在內存中也是有緩存Log buffer,也有磁碟文件log file。

MySQL中的日誌文件,有這麼兩種與事務有關:undo日誌與redo日誌。

1.2.1.undo日誌

資料庫事務具備原子性(**Atomicity**),如果事務執行失敗,需要把數據回滾。

事務同時還具備持久性**(Durability)**,事務對數據所做的變更就完全保存在了資料庫,不能因為故障而丟失。

原子性可以利用undo日誌來實現。

Undo Log的原理很簡單,為了滿足事務的原子性,在操作任何數據之前,首先將數據備份到Undo Log。然後進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句,系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態。

資料庫寫入數據到磁碟之前,會把**數據先緩存在內存**中,事務提交時才會寫入磁碟中。

用Undo Log實現原子性和持久化的事務的簡化過程:

假設有A、B兩個數據,值分別為1,2。

A. 事務開始.

B. 記錄A=1到undo log.

C. 修改A=3.

D. 記錄B=2到undo log.

E. 修改B=4.

F. 將undo log寫到磁碟。

G. 將數據寫到磁碟。

H. 事務提交

如何保證持久性?

事務提交前,會把修改數據到磁碟前,也就是說只要事務提交了,數據肯定持久化了。

如何保證原子性?

- 每次對資料庫修改,都會把修改前數據記錄在undo log,那麼需要回滾時,可以讀取undo log,恢復數據。

- 若系統在G和H之間崩潰

此時事務並未提交,需要回滾。而undo log已經被持久化,可以根據undo log來恢復數據

- 若系統在G之前崩潰

此時數據並未持久化到硬碟,依然保持在事務之前的狀態

缺陷:每個事務提交前將數據和Undo Log寫入磁碟,這樣會導致大量的磁碟IO,因此性能很低。

如果能夠將數據緩存一段時間,就能減少IO提高性能。但是這樣就會喪失事務的持久性。因此引入了另外一種機制來實現持久化,即**Redo Log**.

1.2.2.redo日誌

和Undo Log相反,Redo Log記錄的是**新數據**的備份。在事務提交前,只要將Redo Log持久化即可,不需要將數據持久化,減少了IO的次數。

先來看下基本原理:

Undo + Redo事務的簡化過程

假設有A、B兩個數據,值分別為1,2

A. 事務開始.

B. 記錄A=1到undo log buffer.

C. 修改A=3.

D. 記錄A=3到redo log buffer.

E. 記錄B=2到undo log buffer.

F. 修改B=4.

G. 記錄B=4到redo log buffer.

H. 將undo log寫入磁碟

I. 將redo log寫入磁碟

J. 事務提交

03 安全和性能問題

如何保證原子性?

如果在事務提交前故障,通過undo log日誌恢復數據。如果undo log都還沒寫入,那麼數據就尚未持久化,無需回滾

相關焦點

  • 必須了解的MySQL三大日誌:binlog、redo log和undo log
    日誌是mysql資料庫的重要組成部分,記錄著資料庫運行期間各種狀態信息。mysql日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位日誌幾大類。作為開發,我們重點需要關注的是二進位日誌(binlog)和事務日誌(包括redo log和undo log),本文接下來會詳細介紹這三種日誌。
  • 必須了解的mysql三大日誌-binlog、redo log和undo log
    日誌是 mysql 資料庫的重要組成部分,記錄著資料庫運行期間各種狀態信息。mysql日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位日誌幾大類。作為開發,我們重點需要關注的是二進位日誌( binlog )和事務日誌(包括redo log 和 undo log ),本文接下來會詳細介紹這三種日誌。
  • MySQL 日誌(redo log 和 undo log) 都是什麼鬼?
    出處:https://www.cnblogs.com/f-ck-need-u/innodb事務日誌包括redo log和undo log。redo log是重做日誌,提供前滾操作,undo log是回滾日誌,提供回滾操作。
  • Seata 實現分布式事務原理,mysql日誌記錄問題,學習下
    redo log何時寫入磁碟redo log會在事務提交之前,或者redo log buffer滿了的時候寫入磁碟這裡存在兩個問題:問題1:之前是寫undo和資料庫數據到硬碟,現在是寫undo和redo到磁碟,似乎沒有減少IO次數- 資料庫數據寫入是隨機IO,性能很差- redo log在初始化時會開闢一段連續的空間,寫入是順序IO,性能很好- 實際上undo log並不是直接寫入磁碟,而是先寫入到redo log buffer中,當redo log持久化時,undo
  • 詳解MySQL的Redo日誌與Undo日誌
    Redo用來保證事務的原子性和持久性,Undo能保證事務的一致性,兩者也是系統恢復的基礎前提。1.1 Redo一個事務從開始到結束,要麼提交完成,要麼中止,具有原子性。(b) 日誌中T0已經提交了,必須要對T0 進行redo,而部分T1也需要redo(c) 日誌中T0已經提交了,必須要對T0進行redo,而T1雖然abort也需要redo可能有人有疑惑,commit的事務確實要redo,但進行到一半未提交的事務及後來abort的事務可以不必進行redo。
  • 面試官:談談你對MySQL事務的認識?
    這篇文章屬於mysql資料庫系列,我們來談談事務方面的常見面試題。那麼,具體題目有下面這些:1、講講為什麼用事務?事務的四大特性?事務的隔離級別知道吧,你們生產用哪種?2、Innodb中ACID具體是如何實現的?3、redo log和binlog的一致性如何保證?4、大事務有哪些壞處?生產上遇到過大事務麼?你怎麼排查和解決的?
  • 後端程式設計師必備:分布式事務基礎篇
    事務日誌innodb事務日誌包括redo log和undo log。redo log(重做日誌)redo log通常是物理日誌,記錄的是數據頁的物理修改,而不是某一行或某幾行修改成怎樣,它用來恢復提交後的物理數據頁。
  • 微服務 SpringCloud Alibaba Seata處理分布式事務
    從入門到精通實戰課程分享微服務 SpringCloud Alibaba Seata處理分布式事務一、分布式事務問題什麼是分布式事務?一次業務操作需要跨多個數據源或需要跨多個系統進行遠程調用,就會產生分布式事務問題。例如,在微服務分布式架構中,一次網上購買操作涉及到,訂單系統,支付系統,積分系統,庫存系統,物流系統。一個業務邏輯,分別對應不同的系統,不同的數據源,其中一環出現問題,需要全部回退,這就是分布式事務要解決的問題。
  • SpringBoot+ Dubbo + Mybatis + Nacos +Seata整合來實現Dubbo分布式事務
    1.簡介「本文主要介紹SpringBoot2.1.5 + Dubbo 2.7.3 + Mybatis 3.4.2 + Nacos 1.1.3 +Seata 0.8.0整合來實現Dubbo分布式事務管理,使用Nacos 作為 Dubbo和Seata的註冊中心和配置中心,使用 MySQL 資料庫和 MyBatis來操作數據。
  • 淺析 MySQL Replication
    在了解了以上基礎的內容後,我們可以帶著以下的三個問題去學習複製到底是怎樣工作的。務是如何提交的?事務提交先寫 binlog 還是 redo log?undo 的內存日誌,寫入 redo log fileMySQL Server 層寫 binlog (write --》 fsync)InnoDB 層寫 commit log, InnoDB存儲引擎內提交,使 undo 和 redo 永久寫入磁碟為什麼 MySQL 有 binlog,還有 redo log?
  • 【140期】MySQL中的redolog,undolog,以及binlog的區別及各自作用是什麼?
    重做日誌(redo log) 作用:防止在發生故障的時間點,尚有髒頁未寫入磁碟,在重啟mysql服務的時候,根據redo log進行重做,從而達到事務的持久性這一特性。這一點是必須要知道的,因為這可以很好地解釋再大的事務的提交(commit)的時間也是很短暫的。
  • MySQL 存儲引擎如何完成一條更新語句的執行
    un接著下一步,假設「id=1」這行數據的name原來是「周星星」,現在我們要更新為「月伴飛魚」,那麼此時我們得先 把要更新的原來的值「周星星」和「id=1」這些信息,寫入到undo日誌文件中去。所以為了考慮到未來可能要回滾數據的需要,這裡會把你更新前的值寫入undo日誌文件,我們看下圖。
  • InnoDB undo log
    遞增,這樣回滾段所在的undo tablespace文件就不會被truncate掉臨時表回滾段被賦予trx->rsegs->m_noredo,普通讀寫操作的回滾段被賦予trx->rsegs->mo_redo;如果事務在只讀階段使用臨時表,隨後轉換成讀寫事務,那麼會為該事務分配兩個回滾段對於臨時表,分配1-32號回滾段對於普通表DML,
  • 5種分布式事務解決方案優缺點對比
    一致性:在分布式系統中的所有數據備份,在同一時刻是否同樣的值。 可用性:在集群中一部分節點故障後,集群整體是否還能響應客戶端的讀寫請求。 分區容忍性:以實際效果而言,分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性,就意味著發生了分區的情況,必須就當前操作在C和A之間做出選擇。
  • MySQL如何計算統計redo log大小
    在MySQL中如何計算、統計重做日誌(redo log)的生成情況呢? 例如10分鐘內,生成了多少M的redo log呢?30分鐘內又生成了多少M的redo log.....。MySQL沒有像Oracle中那樣的系統視圖統計這些數據,但是我們可以通過一些方法曲線的統計二進位日誌的生成量。
  • 這有一把鑰匙,打開MySQL死鎖問題!
    下面來系統學習學習mysql事務及鎖機制1. 事務的引入1. 銀行轉帳業務A向B轉帳1000,A-1000,B+10002.事務的實現原理事務的原子性是通過undo log來實現的事務的持久性是通過redo log來實現的事務的隔離性是通過(讀寫鎖+MVCC
  • MySQL InnoDB存儲引擎啟動過程源碼分析
    InnoDB相關參數的檢查和初始化,包括共享表空間、臨時表空間、undo表空間、redo日誌文件、double write文件等等。調用 innobase_start_or_create_for_mysql 函數,這個函數非常重要,後面詳細分析這個函數。
  • 從銀行轉帳失敗到分布式事務:總結與思考
    姊妹篇:再論分布式事務:從理論到實踐  本文地址:http://www.cnblogs.com/xybaby/p/7465816.html關係型資料庫事務回到頂部  大多數人可能和我一樣,第一次聽說事務是在學習關係型資料庫(mysql、sql server、Oracle)的時候,在關係型資料庫中,如果一組操作滿足ACID特性,那麼稱之為一個事務
  • 一文搞懂undo log版本鏈與ReadView機制如何讓事務讀取到該讀的數據
    《一文搞懂 undo log 版本鏈與 ReadView 機制如何讓事務讀取到該讀的數據》,也就是本文;《在 MySQL 中是如何通過 MVCC 機制來解決不可重複讀和幻讀問題的?》,下一篇文章;《在讀提交的事務隔離級別下,MVCC 機制是如何工作的?》,下下篇文章。
  • 萌新和小白都能看懂的MySQL事務機制
    這兩個操作序列就是一個事務,他不能拆分執行,必須同時成功和失敗。當我們面試時最常遇到的問題是什麼?或者不那麼世俗的說——畢竟我們學習並不全是為了面試嘛,啊呸!不面試誰看那麼多,腦子內存本來就不大。事務的4大特性A (Atomicity) 原子性:事務的操作序列不可再拆分:這也是都成功都失敗的意思。