學習事務

事務簡介

事務的核心是鎖和併發，採用同步控制的方式保證併發的狀況下性能儘量高，且容易理解。這種方式的優點是方便理解；它的劣勢是性能比較低。
計算機能夠簡單的理解爲一個標準的打字機，儘管看起來計算機能夠並行處理不少事情，但實際上每一個CPU單位時間內只能作一件事，要麼讀取數據、要麼計算數據、要麼寫入數據，全部的任務均可以當作這三件事的集合。計算機的這種特性引出了一個問題：當多我的去讀、算、寫操做時，若是不加訪問控制，系統勢必會產生衝突。而事務至關於在讀、算、寫操做以外增長了同步的模塊，進而保證只有一個線程進入事務當中，而其餘線程不會進入。

單個事務單元

事務的四大特性分別是：原子型、一致性、隔離性和持久性。其中原子性指的是事務中包含的全部操做要麼全作，要麼全不作；一致性是指在事務開始之前，數據庫處於一致性的狀態，事務結束後，數據庫也必須處於一致性的狀態；隔離性要求系統必須保證事務不受其餘併發執行的事務的影響；持久性是指一個事務一旦成功完成，它對數據庫的改變必須是永久的，即便是在系統遇到故障的狀況下也不會丟失，數據的重要性決定了事務的持久性的重要。

事務單元是經過Begin-Traction，而後Commit（Begin-Traction、Commit和Rollback之間全部針對數據的寫入、讀取的操做都應該添加同步訪問），Begin和Commit之間就是一個同步的事務單元。例如，Bob給Smith 100塊錢就是一個事務單元，這個過程當中有不少步操做，具體如上圖所示；但對業務來講，僅是一個轉帳的操做。

一組事務單元

當三個帳戶都在進行轉帳操做時，每一個操做都涉及Smith帳戶，全部的事務都會排隊，造成一組事務單元。
事務單元之間的Happen-Before關係中的四種可能性：讀寫、寫讀、讀讀、寫寫。全部事務之間的關係均可以抽象成這四種之一，來對應如今全部的業務邏輯處理。在此基礎之上，須要用最快的速度處理多個事務單元之間的關係，同時還能保障這四種操做的邏輯順序。

單個事務單元的其餘例子

除了轉帳操做是事務單元外，諸如商品要創建一個基於GMT_Modified的索引、從數據庫中讀取一行記錄、向數據庫中寫入一行記錄，同時更新這行記錄的全部索引、刪除整張表等都是一個事務單元。

事務單元的實現方式

Two Phase Lock（2PL）是數據庫中很是重要的一個概念。數據庫操做Insert、Update、Delete都是先讀再寫的操做，例如Insert操做是先讀取數據，讀取以後判讀數據是否存在，若是不存在，則寫入該數據，若是數據存在，則返回錯誤。假設在該場景下沒有讀操做，只是單純寫入數據，則數據自己並無事務操做，Delete、Update操做與之相似。數據庫利用這些操做的特性，在每一次查詢過程當中，只要查到數據，就會在該數據上加鎖。理論上，全部被讀取的數據都已加鎖，不會再被其餘人讀到，也就是說對數據進行的中間操做狀態對全部人都不可見，當全部中間狀態完成後，提交操做時，解開鎖，此時數據對全部系統可見，例如在轉帳過程當中，全部人只能看到兩種狀態：開始時，A有錢，B沒錢；結束時，B有錢，A沒錢，而中間A減掉錢，B還沒有加上錢的狀態被鎖隱藏掉了，這個操做就是數據庫中處理事務的最標準的方式。如上圖所示：事務中的Trx2（JoeLock）與其餘事務不相關，所以能夠並行執行；Trx1須要Lock兩個數據Boblock和Smithlock，而Trx3一樣須要Lock這兩個數據，所以Trx3必須等待，且等待在Boblock上；Joe事務會先結束，Trx3會等到Trx1完成後纔會開始。

處理事務的常見方法

處理事務的常見方法有排隊法、排他鎖、讀寫鎖、MVCC等方式，下面來一一解析。

排隊法

事務處理中最重要也是最簡單的方案是排隊法，單線程地處理一堆數據。在Redis中，若是數據所有在內存中，則單線程處理全部Put、Get操做效率最高。這是由於多線程本質是CPU模擬多個線程，這種模擬是以上下文切換爲代價，而對於內存的數據庫來講，沒有上下文切換時效率最高。所以，單個CPU綁定一塊內存的數據，針對這塊數據作屢次讀寫操做時都是在單個CPU上完成的，單線程處理方式在內存的狀況是效率是最優的。
那麼何時事務須要用到多線程呢？這個問題的本質取決於下層所使用的存儲，若是是內存操做，則能夠動態地申請和銷燬內存塊；而磁盤的IOPS很低，但吞吐量很高。若是一個場景涉及屢次讀寫操做，單線程能夠很高的效率對於內存進行讀寫操做；可是，因爲磁盤的IOPS僅爲內存的幾千分之一，若是依舊用操做內存的方式操做磁盤，那系統的總體性能將會很低，這意味着必須將大量的讀寫操做聚合成一個Batch後再提交時才能達到較好的性能。而將大量請求攢到一塊兒的方式一是異步，也就是請求自己和線程不綁定，線程能夠不Block（本質來講仍是一種多線程的方式），處理完一個線程後再處理其餘線程。這種作法的核心是將大量不一樣的請求提交到一個Buff

設備中，多線程或異步很是常見，在設計系統時，面對磁盤、網絡、SSD等慢速設備必須考慮使用多線程。

排他鎖

有些場景不適合用單線程操做，能夠利用排他鎖的方式來快速隔離併發讀寫事務。數據庫中有一些事務單元是共享的，如圖中的事務單元1是共享的，事務單元2/3共享數據；針對事務單元2/3共享數據的全部讀寫Block住，事務單元1單獨用一個鎖來控制，用這種方式完成系統的訪問控制。

讀寫鎖

若是是一個只讀的事務，例如只對數據進行查詢操做，在該過程當中數據必定不被修改，所以多個查詢操做能夠並行執行，所以一種針對讀讀場景的優化天然而然產生——讀寫鎖。讀寫鎖的核心是在屢次讀的操做中，同時容許多個讀者來訪問共享資源，提升併發性。

MVCC

在最初的數據庫事務實現中是不存在MVCC的，它是Oracle在八十年代新加的功能，本質是Copy On Write，也就是每次寫都是以從新開始一個新的版本的方式寫入數據，所以，數據庫中也就包含了以前的全部版本。在數據讀的過程當中，先申請一個版本號，若是該版本號小於正在寫入的版本號，則數據必定能夠查詢到，無需等到新版本徹底寫完便可返回查詢結果。這種方式能夠在讀讀不阻塞的前提下，實現讀寫/寫讀不阻塞，儘量保證全部的讀操做並行，而寫操做串行。

事務的調優原則

事務的調優的思路是在不影響業務應用的前提下： 第一，儘量減小鎖的覆蓋範圍，例如Myisam表鎖到Innodb的行鎖就是一個減小鎖覆蓋範圍的過程；對於原位鎖（排他鎖、讀寫鎖等）可變爲MVCC多版本（本質仍然是減小鎖的範圍）。 第二，增長鎖上可並行的線程數，例如讀鎖和寫鎖的分離，容許並行讀取數據。 第三，選擇正確鎖類型，其中悲觀鎖適合併發爭搶比較嚴重的場景；樂觀鎖適合併發爭搶不太嚴重的場景。