什麼是Database的ACID與一致性問題

-

目的

介紹ACID，並且針對其中的C(Consisitency)一致性提出常見的問題與解決問題的Lock用法

ACID

資料庫的ACID基本上就是四個字首的縮寫分別是

  • ATOMICITY
  • CONSISTENCY
  • ISOLATION
  • DURABILITY

在開始進入文章前需要先講解一個概念Transaction(交易/事務)，Transaction代表著你的程式在這個過程中對資料庫做的操作

舉例:

今天會員購買了這個產品，則程式會對資料庫做一系列的操作包含
新增訂單資料
新增會員與訂單的關聯資料
更新商品銷售資料
則這系列的操作可稱為一個Transaction

若是以Java Spring中的Annotation來講解的話，若在method上標記Transaction則Spring會幫助你判斷此method中對資料庫的操作都為一個Transaction。

ATOMICITY (原子性)

一個Transaction中的全部操作被視為不可分割，代表要就全部完成或是全部取消。若是其中一個環節失敗則會全部回滾(Rollback)到此資料庫Transaction前的狀態。
原子性確保了資料庫的可使用性，當然當資料不再準確時資料庫基本上也不可以使用了

CONSISTENCY (一致性)

其實目前我對於網路上一致性的解釋上有些許混亂，網路上有兩種說法可能是與CAP理論的C一起解釋了，如何選擇就由客官們判斷了

  1. 資料庫在Transaction執行後資料都必須符合schema的規範，例如要執行Trigger或是constraint(Not null/Unique)
  2. 資料庫每個Transaction讀取一個數據的解果都是一樣的

第二個說法的補充

當資料滿足了原子性與隔離性，那在同步進行Transaction時，就算其中一個Transaction
提前完成，那資料也是可以滿足一致性的

ISOLATION (隔離性)

Transaction在確定提交以前，是看不到其他Transaction對這個資料的操作。

DURABILITY (持久性)

一但Transaction提交後，其作的修改將會永遠存在Database之中不能遺失

常見的一致性問題

現在各語言框架通常都已經將資料庫操作包裝好都符合ACID原則，開發者只要呼叫API即可使用，比較少會遇到一致性的問題，但是現在微服務盛行分佈式系統中可能會有好幾台資料庫，在這裡介紹基本以前常遇見的資料庫問題，或許在分佈式系統中可以也會遇到這些提高層級的一致性問題

遺失修改值

T1 -> x=50 -> UPDATE x -------------------> SELECT x -----> x = 100 (不符合預期值)
T2 --------------------> x=100-> UPDATE x ----------------> x = 100

讀取髒數據

T1 -> SELECT x -> x=50 -> UPDATE x --------------->ROLLBACK -> x = 100 (不符合預期值)
T2 ------------------------------- x=100 -> UPDATE x --------> x = 100

不可重複讀

若T2在操作中需要讀取兩次x則第二次取出的值會不同

T1 x=50 -> SELECT x -> x=100 -> UPDATE x -------------> x = 100 (不符合預期值)
T2 x=50 -> SELECT x --------------------- SELECT x ---> x = 100

幻影讀

T1 size = COUNT(x) = N --------- size = COUNT(x) --------> size = N+1 (不符合預期值)
T2 --------------------INSERT x--------------------------> size = N+1

敲黑板 畫重點

若是資料庫不符合ACID原則的話，上面四種情形會非常常見，還是要強調現在用的語言與框架大多已將這些問題包裝並且預防了，而這些問題不一定只會存在於資料庫中再多執行續或是分佈式系統也會常常遇到。

常見的一致性問題解法 - Lock

Lock顧名思義就是將Table或是Raw鎖住不讓其他Transaction使用，可以確保資料的一致性當然效能也會因為要等待Lock解鎖會受到影響，這也是需要考量的事情。

當我們在考慮加鎖時首先要考慮的是，Lock的粒子大小，粒子大小如果在資料庫的話就是Table與Row，今天明明只要鎖Row但是鎖了整張Table讓整個程式運轉下降的話那就不大妙了，而到底要使用哪一種就要看每個工程師的經驗與實力了，最重要的是在平行執行跟Lock的時間消耗做一個平衡

Lock的種類有兩種分別是

  • 排它 (Exclusive) - Write 通稱X鎖
  • 共享 (Shared) - Read 通稱S鎖

其中的兼容性如下

- x s
x x x
s x s

當加了x鎖(Write)那今天除了目前的Transaction其他都無法讀取和寫入此資料/表
當加了s鎖(Read)代表著今天除非我解了此鎖才可以繼續寫入不然今天每個人只能讀

如果在Database的操作中加上了鎖，那上一章節的一致性問題都可以逢刃而解，而Lock的更深入的操作就等哪一天我更深入探索Database之後再發一篇新文章搂!

參考資源

ACID Properties in DBMS
Wiki

關鍵字

  • Concurrency control
  • ACID

留言

張貼留言

這個網誌中的熱門文章

Java Lambda Map篇

-
目的 主要介紹Map中的新方法，包含如下 forEach() getOrDefault() putIfAbsent() remove() replace() replaceAll() merge() 有些是Lambda有些則是我覺得比以前使用Map更方便而介紹 forEach Map的forEach方法與List不大依樣，因為Map主要的迭代方法是以Entry為主，所以需要Key-Value Pair去迭代 原始碼解說 可以看到forEach的傳入參數BiConsumer介面，必須傳入Key與Val，裡面的實作就如同我們使用Java8版本以前的寫法，需要使用for迴圈去迭代抓出每個Value 原始碼 default void forEach(BiConsumer<? super K, ? super V> action) { Objects.requireNonNull(action); for (Map.Entry<K, V> entry : entrySet()) { K k; V v; try { k = entry.getKey(); v = entry.getValue(); } catch(IllegalStateException ise) { // this usually means the entry is no longer in the map. throw new ConcurrentModificationException(ise); } action.accept(k, v); } } 範例 private void forEachExample() { Map<Integer, String> map = new HashMap<>(); map.put(1, "test1"); map.put(2, "test2"); m
閱讀完整內容

(InterviewBit) System Design - Design Cache System

-
圖片
前言 這是InterviewBit中Storage Scalabiliy第一題，設計一個快取系統。 我希望可以透過InterviewBit中的文章與題目，打開自己系統設計的視野，並且重裡面中得到關鍵詞彙，透過這些關鍵詞彙補足自己知識的不足。 其中會參考許多 jyt0532神 的許多文章 題目 替Twitter或是google設計快取系統，概念圖如下: 分析步驟 列出需求情境 估算 立定設計目標 深入探討設計方法 需求情境 需要多大的快取 我們的快取清除策略要如何 因為快取大小所以必須將舊資料刪掉 快取的寫入策略 Write through cache 當資料寫入時，同時寫入DB和Cache中 寫入因為需要寫入兩個系統(DB/Cache)所以有較高的延遲 Write around cache 當資料寫入時先寫入DB，當快取被讀取發現遺失資料時，再將資料從DB同步到快取中 因為讀取是從快取中讀取，但是在讀取時判斷到有新增資料沒進入快取，會有較高的讀延遲。 但寫和重複讀不會有特別的延遲 Write back cache 直接將資料寫入到快取中，在同步到資料庫裡 風險 - 畢竟快取是in-memory會有遺失風險 優點 - 高寫入效率(寫得快可附合的流量大) 可以透過replica快取降低memory消失的風險 評估 預先知識 QPS - Queries Per Second TPS - Transactions Per Second UV - Unique Visitor RPS - Requests Per Secornd 獲取設計前條件 目前得知的條件 快取大小會是30TB QPS會是10M(每秒一千萬) 估算機器數量 假設我們每台機器都有72G的記憶體，則要存入30TB的資料則需要 30TB / 72G = 420(大約)，而這是剛剛好的數目，有可能需要增加，因為我們每秒要附和10M的搜尋流量。 設計目標 設計目標三巨頭 Latency(延遲) Consistency(一致性) Availability(可使用性) 快取系統的設計目標 快取的用意就在於降低延遲，DB的寫入是依靠硬碟的而快取是依靠記憶體，有基本計算機常識的話就可以知道
閱讀完整內容

設計模式 - 享元模式 (Structural Patterns - Flyweight Design Pattern)

-
圖片
前言 甚麼是Flyweight Pattern? 幫助你節省記憶體開銷 透過共享物件的方式 最常見的例子 String : 每次新增一個String的時候，都會將String丟進String pool，再讓物件指向這個String memory。 String str1 = "test"; String str2 = "test"; System.out.println(str1 == str2) // true 實踐方式 撰寫Flyweight介面與物件 撰寫Flyweight工廠(主要節省記憶體邏輯在此)，負責管理和創建Flyweight 類別圖 範例 我們可以思考一下，在英雄遊戲中有那些東西可以使用享元模式。 重複製造 同物件的性質一樣 我想武器添加物系統可以使用享元模式，因為武器中插的寶石不管插在哪種類的武器裡，他們的功效都是一樣的，而如果為每把武器都創建新的寶石物件，那太消耗記憶體了。 程式行為 為武器加上寶石 若是已經存在的寶石則不在new 物件 透過DiamondFactory去控制要不要new新物件的邏輯 import java.util.ArrayList; import java.util.HashMap; import java.util.Map; abstract class Weapon { ArrayList<Diamond> diamonds = new ArrayList<>(); public void addDiamond(Diamond diamond) { diamonds.add(diamond); } abstract void attack(); } class Sword extends Weapon { @Override void attack() { System.out.println("Sword attack"); diamonds.forEach((x) -> { System.out.println("Use "
閱讀完整內容