溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

數(shù)據(jù)庫事務的實現(xiàn)原理是什么

發(fā)布時間:2022-01-15 17:41:09 來源:億速云 閱讀:322 作者:iii 欄目:數(shù)據(jù)庫

本篇內(nèi)容主要講解“數(shù)據(jù)庫事務的實現(xiàn)原理是什么”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“數(shù)據(jù)庫事務的實現(xiàn)原理是什么”吧!

數(shù)據(jù)庫的事務有四大特性:原子性、隔離性、永久性、一致性,下面將介紹這四大特性的定義和在 InnoDB 引擎中是怎么實現(xiàn)的。

原子性

定義

一次操作是不可分割的,要么全部成功,要么全部失敗。比如我們的轉(zhuǎn)賬操作,不允許出款方成功,收款方失敗這種情況,要么都成功,要么多失敗,不可能出現(xiàn)中間狀態(tài)。

實現(xiàn)

InnoDB 引擎使用 undo  log(歸滾日志)來保證原子性操作,你對數(shù)據(jù)庫的每一條數(shù)據(jù)的改動(INSERT、DELETE、UPDATE)都會被記錄到 undo log  中,比如以下這些操作:

  • 你插入一條記錄時,至少要把這條記錄的主鍵值記下來,之后回滾的時候只需要把這個主鍵值對應的記錄刪掉就好了。

  • 你刪除了一條記錄,至少要把這條記錄中的內(nèi)容都記下來,這樣之后回滾時再把由這些內(nèi)容組成的記錄插入到表中就好了。

  • 你修改了一條記錄,至少要把修改這條記錄前的舊值都記錄下來,這樣之后回滾時再把這條記錄更新為舊值就好了。

當事務執(zhí)行失敗或者調(diào)用了 rollback 方法時,就會觸發(fā)回滾事件,利用 undo log 中記錄將數(shù)據(jù)回滾到修改之前的樣子。

更多關于 undo log 的信息,后面再單獨開一篇文章打卡。

隔離性

定義

多個事務并發(fā)執(zhí)行的時候,事務內(nèi)部的操作與其他事務是隔離的,并發(fā)執(zhí)行的各個事務之間不能互相干擾。

實現(xiàn)

隔離性可能會引入臟讀(dirty read)、不可重復讀(non-repeatable read)、幻讀(phantom  read)等問題,為了解決這些問題就引入了“隔離級別”的概念。

SQL 標準的事務隔離級別包括:讀未提交(read uncommitted)、讀提交(read committed)、可重復讀(repeatable  read)和串行化(serializable):

  • 讀未提交:一個事務還沒提交時,它做的變更就能被別的事務看到。

  • 讀提交:一個事務提交之后,它做的變更才會被其他事務看到。

  • 可重復讀: 一個事務執(zhí)行過程中看到的數(shù)據(jù),總是跟這個事務在啟動時看到的數(shù)據(jù)是一致的。當然在可重復讀隔離級別下,未提交變更對其他事務也是不可見的。

  • 串行化:  顧名思義是對于同一行記錄,“寫”會加“寫鎖”,“讀”會加“讀鎖”。當出現(xiàn)讀寫鎖沖突的時候,后訪問的事務必須等前一個事務執(zhí)行完成,才能繼續(xù)執(zhí)行。

SQL標準中規(guī)定,針對不同的隔離級別,并發(fā)事務可以發(fā)生不同嚴重程度的問題,具體情況如下:

數(shù)據(jù)庫事務的實現(xiàn)原理是什么

上面就是幾種隔離級別可能出現(xiàn)的并發(fā)問題,但是有必要說一下,你隔離得越嚴實,效率就會越低。

InnoDB 引擎是如何保證隔離性的?利用鎖和 MVCC 機制。這里簡單的介紹一下 MVCC 機制,也叫多版本并發(fā)控制,在使用 READ  COMMITTD、REPEATABLE READ 這兩種隔離級別的事務下,每條記錄在更新的時候都會同時記錄一條回滾操作,就會形成一個版本鏈,在執(zhí)行普通的  SELECT 操作時訪問記錄的版本鏈的過程,這樣子可以使不同事務的讀-寫、寫-讀操作并發(fā)執(zhí)行,從而提升系統(tǒng)性能。

持久性

定義

事務一旦提交,它對數(shù)據(jù)庫的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

實現(xiàn)

要保證持久性很簡單,就是每次事務提交的時候,都將數(shù)據(jù)刷磁盤上,這樣一定保證了安全性,但是要知道如果每次事務提交都將數(shù)據(jù)寫入到磁盤的話,頻繁的 IO  操作,成本太高,數(shù)據(jù)庫的性能極低,所以這種方式不可取。

InnoDB 引擎是怎么解決的?InnoDB 引擎引入了一個中間層來解決這個持久性的問題,我們把這個叫做 redo log(歸檔日志)。

為什么要引入 redo log?redo log 可以保證持久化又可以保證數(shù)據(jù)庫的性能,相比于直接刷盤,redo log 有以下兩個優(yōu)勢:

  • redo log體積小,畢竟只記錄了哪一頁修改了啥,因此體積小,刷盤快。

  • redo log是一直往末尾進行追加,屬于順序IO。效率顯然比隨機IO來的快。

InnoDB 引擎是怎么做的?當有一條記錄需要更新的時候,InnoDB 引擎就會先把記錄寫到 redo log  里面,并更新內(nèi)存,這個時候更新就算完成了。當數(shù)據(jù)庫宕機重啟的時候,會將 redo log 中的內(nèi)容恢復到數(shù)據(jù)庫中,再根據(jù) undo log和 binlog  內(nèi)容決定回滾數(shù)據(jù)還是提交數(shù)據(jù)。

一致性

定義

一致性簡單一點說就是數(shù)據(jù)執(zhí)行前后都要處于一種合法的狀態(tài),比如身份證號不能重復,性別只能是男或者女,高考的分數(shù)只能在0~750之間,紅綠燈只有3種顏色,房價不能為負的等等,  只有符合這些約束的數(shù)據(jù)才是有效的,比如有個小孩兒跟你說他高考考了1000分,你一聽就知道他胡扯呢。數(shù)據(jù)庫世界只是現(xiàn)實世界的一個映射,現(xiàn)實世界中存在的約束當然也要在數(shù)據(jù)庫世界中有所體現(xiàn)。如果數(shù)據(jù)庫中的數(shù)據(jù)全部符合現(xiàn)實世界中的約束(all  defined rules),我們說這些數(shù)據(jù)就是一致的,或者說符合一致性的。

實現(xiàn)

要保證數(shù)據(jù)庫的數(shù)據(jù)一致性,要在以下兩個方面做努力:

  • 利用數(shù)據(jù)庫的一些特性來保證部分一致性需求:比如聲明某個列為NOT NULL 來拒絕NULL值得插入等。

  • 絕大部分還是需要我們程序員在編寫業(yè)務代碼得時候來保證。

到此,相信大家對“數(shù)據(jù)庫事務的實現(xiàn)原理是什么”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關內(nèi)容可以進入相關頻道進行查詢,關注我們,繼續(xù)學習!

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI