本地事物的簡介

此章帶你們回顧下本地事物的一些內容。標題 2

事物:

有一組操做構成的可靠,獨立的工做單元----百度百科

事物的四大特性:

A:原子性(Atomicity)
       事務是數據庫的邏輯工做單位，事務中包括的諸操做要麼全作，要麼全不作。
B:一致性(Consistency)
       事務執行的結果必須是使數據庫從一個一致性狀態變到另外一個一致性狀態。一致性與原子性是密切相關的。
C:隔離性(Isolation)
      一個事務的執行不能被其餘事務干擾。
D:持續性/永久性(Durability)
      一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。

以上介紹完事務的四大特性(簡稱ACID)，如今重點來講明下事務的隔離性，當多個線程都開啓事務操做數據庫中的數據時，數據庫系統要能進行隔離操做，以保證各個線程獲取數據的準確性，在介紹數據庫提供的各類隔離級別以前，咱們先看看若是不考慮事務的隔離性，會發生的幾種問題：

不可重複讀

不可重複讀的重點是修改:

一樣的條件, 你讀取過的數據, 再次讀取出來發現值不同了

例子：

在事務1中，Mary 讀取了本身的工資爲1000,操做並無完成 

con1 = getConnection();  
select salary from employee empId ="Mary";  

在事務2中，這時財務人員修改了Mary的工資爲2000,並提交了事務. 

con2 = getConnection();  
update employee set salary = 2000;  
con2.commit();  

在事務1中，Mary 再次讀取本身的工資時，工資變爲了2000 

//con1  
select salary from employee empId ="Mary";  

在一個事務中先後兩次讀取的結果並不致，致使了不可重複讀。

 

 

幻讀

幻讀的重點在於新增或者刪除

一樣的條件, 第1次和第2次讀出來的記錄數不同

例子：

目前工資爲1000的員工有10人。 
事務1,讀取全部工資爲1000的員工。 

con1 = getConnection();  
Select * from employee where salary =1000;  

共讀取10條記錄 

這時另外一個事務向employee表插入了一條員工記錄，工資也爲1000 

con2 = getConnection();  
Insert into employee(empId,salary) values("Lili",1000);  
con2.commit();  

事務1再次讀取全部工資爲1000的員工 

//con1  
select * from employee where salary =1000;  

共讀取到了11條記錄，這就產生了幻像讀。 

 

事物的隔離級別:

如今來看看MySQL數據庫爲咱們提供的四種隔離級別：

　　① Serializable (串行化)：可避免髒讀、不可重複讀、幻讀的發生。

　　② Repeatable read (可重複讀)：可避免髒讀、不可重複讀的發生。

　　③ Read committed (讀已提交)：可避免髒讀的發生。

　　④ Read uncommitted (讀未提交)：最低級別，任何狀況都沒法保證。

　　以上四種隔離級別最高的是Serializable級別，最低的是Read uncommitted級別，固然級別越高，執行效率就越低。像Serializable這樣的級別，就是以鎖表的方式(相似於Java多線程中的鎖)使得其餘的線程只能在鎖外等待，因此平時選用何種隔離級別應該根據實際狀況。在MySQL數據庫中默認的隔離級別爲Repeatable read (可重複讀)。

　　在MySQL數據庫中，支持上面四種隔離級別，默認的爲Repeatable read (可重複讀)；而在Oracle數據庫中，只支持Serializable (串行化)級別和Read committed (讀已提交)這兩種級別，其中默認的爲Read committed級別。

　　在MySQL數據庫中查看當前事務的隔離級別：

select @@tx_isolation;

　　在MySQL數據庫中設置事務的隔離 級別：

set  [glogal | session]  transaction isolation level 隔離級別名稱;

    set tx_isolation=’隔離級別名稱;’

 

 

本地事物的侷限性：

如何修復事物的侷限性解決微服務問題？

    1：單數據源侷限性思考

    既然一個事物只能操做一個數據源，那麼咱們可否新建多個事物，分別操做多個數據源，最後經過一個統一的」事物管理器」進行統一管理以及提交呢?

    2：單進程侷限性思考

既然一個事物只能對一個線程進行管理，那麼咱們可否新建多個事物，分別操做多個線程，最後經過一個統一的」事物管理器」進行統一管理以及提交呢?

  3：高併發下效率低侷限性思考

 既然事物執行效率低，那麼可否把事物的執行丟到一個異步線程裏面執行，這樣主線程就不會受事物的影響了。

那就帶着，咱們本身思考的解決方案，正式進入分佈式方案的講解吧。

 

 /** *   ————————若是以爲本博文還行，別忘了推薦一下哦，謝謝！ *   做者：寫程序的奧特曼 *   歡迎轉載，請保留此段聲明。 *   出處：https://my.oschina.net/u/2286631/blog/1504647 */