簡(jiǎn)單背景介紹

MySQL

MySQL是現(xiàn)在最流行的關(guān)系型數(shù)據(jù)庫(RDB)的選擇, 創(chuàng)建一個(gè)應(yīng)用時(shí)，無論是用戶數(shù)據(jù)還是訂單數(shù)據(jù)，使用關(guān)系型數(shù)據(jù)庫存儲(chǔ)是最可靠穩(wěn)定的選擇，借助RDB提供的可靠性、事務(wù)等功能，為應(yīng)用提供完善的支持。MySQL是開源軟件，可以免費(fèi)使用，MySQL在發(fā)展多年后越來越成熟，成為大部分公司的數(shù)據(jù)庫首選。MySQL采用插件式的存儲(chǔ)引擎架構(gòu)，5.5版本后默認(rèn)使用InnoDB存儲(chǔ)引擎。

MySQL架構(gòu)

MySQL從概念上可以分為四層，頂層是接入層，不同語言的客戶端通過mysql的協(xié)議與mysql服務(wù)器進(jìn)行連接通信，接入層進(jìn)行權(quán)限驗(yàn)證、連接池管理、線程管理等。下面是mysql服務(wù)層，包括sql解析器、sql優(yōu)化器、數(shù)據(jù)緩沖、緩存等。再下面是mysql中的存儲(chǔ)引擎層，mysql中存儲(chǔ)引擎是基于表的。最后是系統(tǒng)文件層，保存數(shù)據(jù)、索引、日志等。

MVCC

MVCC是Multi Version Concurrency Control的簡(jiǎn)稱，代表多版本并發(fā)控制。為什么需要MVCC，還要從數(shù)據(jù)庫事務(wù)的ACID特性說起。

相信很多朋友都了解ACID，它們分別代表了Atomicity(原子性), Consistency(一致性), Isolation(隔離性), Durability(持久性)。

原子性表示一個(gè)事務(wù)的操作結(jié)果要么全部執(zhí)行要么全部不執(zhí)行。

一致性表示事務(wù)總是從一個(gè)一致的狀態(tài)轉(zhuǎn)換到另一個(gè)一致的狀態(tài)。

隔離性表示一個(gè)事務(wù)的修改結(jié)果在什么時(shí)間能夠被其他事務(wù)看到，SQL1992規(guī)范中對(duì)隔離性定義了不同的隔離級(jí)別，

分為讀未提交(READ UNCOMMITED),事務(wù)能夠看到其他事務(wù)沒有提及的修改，當(dāng)另一個(gè)事務(wù)又回滾了修改后的情況又被稱為臟讀dirty read。

讀已提交(READ COMMITTED),事務(wù)能夠看到其他事務(wù)提交后的修改，這時(shí)會(huì)出現(xiàn)一個(gè)事務(wù)內(nèi)兩次讀取數(shù)據(jù)可能因?yàn)槠渌聞?wù)提交的修改導(dǎo)致不一致的情況，稱為不可重復(fù)讀。 可重復(fù)讀(REPEATABLE READ)，在兩次讀取時(shí)讀取到的數(shù)據(jù)的狀態(tài)是一致的，和序列化(SERIALIZABLE)可重復(fù)讀中可能出現(xiàn)第二次讀讀到第一次沒有讀到的數(shù)據(jù)，也就是被其他事務(wù)插入的數(shù)據(jù)，這種情況稱為幻讀phantom read, 序列化級(jí)別中不能出現(xiàn)幻讀。

隔離級(jí)別依次增強(qiáng)，但是導(dǎo)致的問題是并發(fā)能力的減弱。

各種數(shù)據(jù)庫廠商會(huì)對(duì)各個(gè)隔離級(jí)別進(jìn)行實(shí)現(xiàn)。

和Java中的多線程問題相同，數(shù)據(jù)庫通常使用鎖來實(shí)現(xiàn)隔離性。

最原生的鎖，鎖住一個(gè)資源后會(huì)禁止其他任何線程訪問同一個(gè)資源。但是很多應(yīng)用的一個(gè)特點(diǎn)都是讀多寫少的場(chǎng)景，很多數(shù)據(jù)的讀取次數(shù)遠(yuǎn)大于修改的次數(shù)，而讀取數(shù)據(jù)間互相排斥顯得不是很必要。所以就使用了一種讀寫鎖的方法，讀鎖和讀鎖之間不互斥，而寫鎖和寫鎖、讀鎖都互斥。這樣就很大提升了系統(tǒng)的并發(fā)能力。之后人們發(fā)現(xiàn)并發(fā)讀還是不夠，又提出了能不能讓讀寫之間也不沖突的方法，就是讀取數(shù)據(jù)時(shí)通過一種類似快照的方式將數(shù)據(jù)保存下來，這樣讀鎖就和寫鎖不沖突了，不同的事務(wù)session會(huì)看到自己特定版本的數(shù)據(jù)。當(dāng)然快照是一種概念模型，不同的數(shù)據(jù)庫可能用不同的方式來實(shí)現(xiàn)這種功能。

之后的討論默認(rèn)均以REPEATABLE READ作為隔離級(jí)別。

InnoDB與MVCC

MySQL中的InnoDB存儲(chǔ)引擎的特性有，默認(rèn)隔離級(jí)別REPEATABLE READ, 行級(jí)鎖，實(shí)現(xiàn)了MVCC, Consistent nonlocking read(默認(rèn)讀不加鎖，一致性非鎖定讀), Insert Buffer, Adaptive Hash Index, DoubleWrite, Cluster Index。

上面列舉了這么多，表示InnoDB有很多特性、很快。

InnoDB中通過UndoLog實(shí)現(xiàn)了數(shù)據(jù)的多版本，而并發(fā)控制通過鎖來實(shí)現(xiàn)。

Undo Log除了實(shí)現(xiàn)MVCC外，還用于事務(wù)的回滾。

Redo log, bin log, Undo log

MySQL Innodb中存在多種日志，除了錯(cuò)誤日志、查詢?nèi)罩就?#xff0c;還有很多和數(shù)據(jù)持久性、一致性有關(guān)的日志。

binlog，是mysql服務(wù)層產(chǎn)生的日志，常用來進(jìn)行數(shù)據(jù)恢復(fù)、數(shù)據(jù)庫復(fù)制，常見的mysql主從架構(gòu)，就是采用slave同步master的binlog實(shí)現(xiàn)的, 另外通過解析binlog能夠?qū)崿F(xiàn)mysql到其他數(shù)據(jù)源(如ElasticSearch)的數(shù)據(jù)復(fù)制。

redo log記錄了數(shù)據(jù)操作在物理層面的修改，mysql中使用了大量緩存，緩存存在于內(nèi)存中，修改操作時(shí)會(huì)直接修改內(nèi)存，而不是立刻修改磁盤，當(dāng)內(nèi)存和磁盤的數(shù)據(jù)不一致時(shí)，稱內(nèi)存中的數(shù)據(jù)為臟頁(dirty page)。為了保證數(shù)據(jù)的安全性，事務(wù)進(jìn)行中時(shí)會(huì)不斷的產(chǎn)生redo log，在事務(wù)提交時(shí)進(jìn)行一次flush操作，保存到磁盤中, redo log是按照順序?qū)懭氲?#xff0c;磁盤的順序讀寫的速度遠(yuǎn)大于隨機(jī)讀寫。當(dāng)數(shù)據(jù)庫或主機(jī)失效重啟時(shí)，會(huì)根據(jù)redo log進(jìn)行數(shù)據(jù)的恢復(fù)，如果redo log中有事務(wù)提交，則進(jìn)行事務(wù)提交修改數(shù)據(jù)。這樣實(shí)現(xiàn)了事務(wù)的原子性、一致性和持久性。

Undo Log: 除了記錄redo log外，當(dāng)進(jìn)行數(shù)據(jù)修改時(shí)還會(huì)記錄undo log，undo log用于數(shù)據(jù)的撤回操作，它記錄了修改的反向操作，比如，插入對(duì)應(yīng)刪除，修改對(duì)應(yīng)修改為原來的數(shù)據(jù)，通過undo log可以實(shí)現(xiàn)事務(wù)回滾，并且可以根據(jù)undo log回溯到某個(gè)特定的版本的數(shù)據(jù)，實(shí)現(xiàn)MVCC。

redo log 和binlog的一致性，為了防止寫完binlog但是redo log的事務(wù)還沒提交導(dǎo)致的不一致，innodb 使用了兩階段提交

大致執(zhí)行序列為

InnoDB prepare (持有prepare_commit_mutex)；

write/sync Binlog；

InnoDB commit (寫入COMMIT標(biāo)記后釋放prepare_commit_mutex)。

MVCC實(shí)現(xiàn)

innodb中通過B+樹作為索引的數(shù)據(jù)結(jié)構(gòu)，并且主鍵所在的索引為ClusterIndex(聚簇索引), ClusterIndex中的葉子節(jié)點(diǎn)中保存了對(duì)應(yīng)的數(shù)據(jù)內(nèi)容。一個(gè)表只能有一個(gè)主鍵，所以只能有一個(gè)聚簇索引，如果表沒有定義主鍵，則選擇第一個(gè)非NULL唯一索引作為聚簇索引，如果還沒有則生成一個(gè)隱藏id列作為聚簇索引。

除了Cluster Index外的索引是Secondary Index(輔助索引)。輔助索引中的葉子節(jié)點(diǎn)保存的是聚簇索引的葉子節(jié)點(diǎn)的值。

InnoDB行記錄中除了剛才提到的rowid外，還有trx_id和db_roll_ptr, trx_id表示最近修改的事務(wù)的id,db_roll_ptr指向undo segment中的undo log。

新增一個(gè)事務(wù)時(shí)事務(wù)id會(huì)增加，trx_id能夠表示事務(wù)開始的先后順序。

Undo log分為Insert和Update兩種，delete可以看做是一種特殊的update，即在記錄上修改刪除標(biāo)記。

update undo log記錄了數(shù)據(jù)之前的數(shù)據(jù)信息，通過這些信息可以還原到之前版本的狀態(tài)。

當(dāng)進(jìn)行插入操作時(shí)，生成的Insert undo log在事務(wù)提交后即可刪除，因?yàn)槠渌聞?wù)不需要這個(gè)undo log。

進(jìn)行刪除修改操作時(shí)，會(huì)生成對(duì)應(yīng)的undo log，并將當(dāng)前數(shù)據(jù)記錄中的db_roll_ptr指向新的undo log

數(shù)據(jù)可見性判斷

CREATE TABLE `testunique` (

`id` int(11) unsigned NOT NULL AUTO_INCREMENT,

`uid` int(11) DEFAULT NULL,

`ukey` int(11) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `id_uid` (`uid`),

KEY `index_key` (`ukey`)

) ENGINE=InnoDB AUTO_INCREMENT=70 DEFAULT CHARSET=utf8;

隔離級(jí)別REPEATABLE READ

只有當(dāng)session2 commit之后的查詢才能查到session1插入的數(shù)據(jù)

事務(wù)可見性的處理過程:

RR級(jí)別下一個(gè)事務(wù)開始后第一個(gè)snapshot read的時(shí)候，會(huì)將當(dāng)期活動(dòng)的事務(wù)id記錄下來，記錄到read view中。RC級(jí)別則是每次snapshot read都會(huì)創(chuàng)建一個(gè)新的read view。

假設(shè)當(dāng)前,read view中最大的事務(wù)id為tmax, 最小為tmin。則判斷一個(gè)數(shù)據(jù)是否可見以及對(duì)應(yīng)的版本的方法為。

如果該行中的trx_id, 賦值給tid, 如果tid和當(dāng)前事務(wù)id相等或小于tmin，說明是事務(wù)內(nèi)發(fā)生的或開啟前的修改，則直接返回該版本數(shù)據(jù); 如果

trx_id大于tmax, 則查看該版本的db_roll_ptr中的trx_id，賦值給tid并從頭開始判斷。如果tid小于tmax并且不在read view中，則返回，否則中回滾段中找出undo log的trx_id，賦值給tid從頭判斷。

所以可見性是，只有當(dāng)?shù)谝淮巫x之前提交的修改和自己的修改可見，其他的均不可見。

代碼實(shí)現(xiàn)部分

在storage/innobase/include/read0types.h中

// Friend declaration

class MVCC;

/** Read view lists the trx ids of those transactions for which a consistent

read should not see the modifications to the database. */

...

class ReadView {

...

private:

// Prevent copying

ids_t(const ids_t&);

ids_t& operator=(const ids_t&);

private:

/** Memory for the array */

value_type* m_ptr;

/** Number of active elements in the array */

ulint m_size;

/** Size of m_ptr in elements */

ulint m_reserved;

friend class ReadView;

};

public:

ReadView();

~ReadView();

/** Check whether transaction id is valid.

@param[in] id transaction id to check

@param[in] name table name */

static void check_trx_id_sanity(

trx_id_t id,

const table_name_t& name);

// 判斷一個(gè)修改是否可見

/** Check whether the changes by id are visible.

@param[in] id transaction id to check against the view

@param[in] name table name

@return whether the view sees the modifications of id. */

bool changes_visible(

trx_id_t id,

const table_name_t& name) const

MY_ATTRIBUTE((warn_unused_result))

{

ut_ad(id > 0);

if (id < m_up_limit_id || id == m_creator_trx_id) {

return(true);

}

check_trx_id_sanity(id, name);

if (id >= m_low_limit_id) {

return(false);

} else if (m_ids.empty()) {

return(true);

}

const ids_t::value_type* p = m_ids.data();

return(!std::binary_search(p, p + m_ids.size(), id));

}

private:

// Disable copying

ReadView(const ReadView&);

ReadView& operator=(const ReadView&);

private:

// 活動(dòng)事務(wù)中的id的最大

/** The read should not see any transaction with trx id >= this

value. In other words, this is the "high water mark". */

trx_id_t m_low_limit_id;

// 活動(dòng)事務(wù)id的最小值

/** The read should see all trx ids which are strictly

smaller (

low water mark". */

//

trx_id_t m_up_limit_id;

/** trx id of creating transaction, set to TRX_ID_MAX for free

views. */

trx_id_t m_creator_trx_id;

/** Set of RW transactions that was active when this snapshot

was taken */

ids_t m_ids;

/** The view does not need to see the undo logs for transactions

whose transaction number is strictly smaller (

they can be removed in purge if not needed by other views */

trx_id_t m_low_limit_no;

/** AC-NL-RO transaction view that has been "closed". */

bool m_closed;

typedef UT_LIST_NODE_T(ReadView) node_t;

/** List of read views in trx_sys */

byte pad1[64 - sizeof(node_t)];

node_t m_view_list;

};

Undo log刪除

undo log在沒有活動(dòng)事務(wù)依賴(用于consistent read或回滾)便可以清楚，innodb 中存在后臺(tái)purge 線程進(jìn)行后臺(tái)輪詢刪除undo log。

Current Read snapshot read

REPEATABLE READ隔離級(jí)別下普通的讀操作即select都不加鎖，使用MVCC進(jìn)行一致性讀取，這種讀取又叫做snapshot read。

而update, insert, delete, select … for update, select … lock in share mode都會(huì)進(jìn)行加鎖，并且讀取的是當(dāng)前版本，也就是READ COMMITTED讀的效果。innodb-locks-set.html中對(duì)各種操作會(huì)進(jìn)行的鎖操作有詳細(xì)的說明，這里我簡(jiǎn)單總結(jié)下。

InnoDB中加鎖的方法是鎖住對(duì)應(yīng)的索引，一個(gè)操作進(jìn)行前會(huì)選擇一個(gè)索引進(jìn)行掃描，掃描到一行后加上對(duì)應(yīng)的鎖然后返回給上層然后繼續(xù)掃描。InnoDB支持行級(jí)鎖(record lock)，上述需要加鎖的操作中，除了select … lock in share mode 是加shared lock(共享鎖或讀鎖)外其他操作都加的是exclusive lock(即排他鎖或?qū)戞i)。在加行級(jí)鎖前，會(huì)對(duì)表加一個(gè)intention lock，即意向鎖，意向所是表級(jí)鎖，不會(huì)和行級(jí)鎖沖突，主要用途是表明一個(gè)要加行級(jí)鎖或正在加鎖的操作。

另外InnoDB種除了record lock外還有一種gap lock，即鎖住兩個(gè)記錄間的間隙，防止其他事務(wù)插入數(shù)據(jù)，用于防止幻讀。當(dāng)索引是主鍵索引或唯一索引時(shí)，不需要加gap lock。當(dāng)索引不是唯一索引時(shí)，需要對(duì)索引數(shù)據(jù)和索引前的gap加鎖，這種方式叫做next-key locking。

另外在插入數(shù)據(jù)時(shí)，還需要提前最插入行的前面部分加上insert intention lock, 即插入意向鎖，插入意向鎖之間不會(huì)沖突，會(huì)和gap鎖沖突導(dǎo)致等待。當(dāng)插入時(shí)遇到duplicated key錯(cuò)誤時(shí)，會(huì)在要插入的行上加上share lock。

參考

• https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html
• http://hedengcheng.com/
• MySQL技術(shù)內(nèi)幕
• http://www.postgres.cn/downfiles/pg2016conf_day2_s1_pm3.pdf
• https://dev.mysql.com/doc/refman/5.7/en/source-installation.html
• https://blog.jcole.us/2014/04/16/the-basics-of-the-innodb-undo-logging-and-history-system/
• http://www.cnblogs.com/chenpingzhao/p/5065316.html

總結(jié)

以上是生活随笔為你收集整理的window.open 实现session隔离_InnoDB存储引擎MVCC实现原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。