1.邏輯架構(gòu)圖

邏輯架構(gòu)圖
2.并發(fā)控制
只要有多個查詢需要在同一個時刻修改數(shù)據(jù)導致出現(xiàn)并發(fā)問題(讀取數(shù)據(jù)不會出現(xiàn)問題)
解決并發(fā)控制的讀寫
通過實現(xiàn)兩種類型的鎖組成的鎖系統(tǒng)解決
讀寫鎖
- 共享鎖(讀鎖)
- 排他鎖(寫鎖)
什么是鎖
- 讀鎖: 多個客戶都可以在同一時刻讀取同一個資源并且是共享的(互不干擾)
- 寫鎖:只有一個用戶可以能執(zhí)行寫入,會阻塞其他的讀鎖和寫鎖,防止其他用戶讀取正在寫入的同一資源
鎖粒度
一種提高共享資源并發(fā)性的方式
出現(xiàn)問題:加大開銷,消耗資源
- 例如:鎖的各種操作
- 獲取鎖 檢查鎖是否解除 釋放鎖等
鎖策略
鎖的開銷和數(shù)據(jù)的安全性之間尋求平衡
常用的鎖策略
- 表鎖
1.基本鎖策略,開銷最小
2.鎖住整張表
一個用戶操作表的話需要獲取到寫鎖,
這會阻塞其他用戶的對該表所有的讀寫操作,釋放掉寫鎖后,其他讀取用戶才可以操作(讀鎖[互不阻塞])
- 行級鎖(存儲引擎實現(xiàn))
1.最大程度的支持并發(fā)處理,開銷最大
3.事務
一組原子性(不成功便成仁)的SQL查詢語句 (獨立工作的單元)
事務內(nèi)的語句,要么全部執(zhí)行成功,要么全部執(zhí)行失敗(一條語句崩潰或者其他原因無法執(zhí)行)
開啟事務
start transaction 語句開啟事務
commit提交事務
roolback撤銷所有事務
例子:銀行應用(轉(zhuǎn)賬)
所有事務必須經(jīng)過ACID測試
- A: atomicity 原子性
- C: consistency 一致性
- I: isolation 隔離性
- D: durability 持久性
原子性:
要執(zhí)行事務代碼邏輯成功,要么就執(zhí)行事務代碼失敗
一致性:
“一致性”在數(shù)據(jù)庫領域有兩個意義:
,一個是ACID中的C,也是普遍意義上的數(shù)據(jù)庫事務一致性,
另一個是CAP的C,有關分布式事務的一致性。
舉例來說,假設用戶A和用戶B兩者的錢加起來一共是1000,
那么不管A和B之間如何轉(zhuǎn)賬、轉(zhuǎn)幾次賬,
事務結(jié)束后兩個用戶的錢相加起來應該還得是1000,這就是事務的一致性。
ACIP
1.事務對數(shù)據(jù)完整性的遵循
約束可能包括主鍵約束、外鍵約束或是一些用戶自定義約束。
事務執(zhí)行的前后都是合法的數(shù)據(jù)狀態(tài),不會違背任何的數(shù)據(jù)完整性
2.不能寫出錯誤的事務邏輯
CAP
1.CAP定理是分布式系統(tǒng)理論的基礎
分布式系統(tǒng)(或者由于網(wǎng)絡隔離等原因產(chǎn)生的分區(qū)系統(tǒng)),它無法同時保證一致性、可用性和分區(qū)容忍性,
而是必須要舍棄其中的一個。
2.具體在數(shù)據(jù)庫上,就是分布式數(shù)據(jù)庫中,
每一個節(jié)點對于同一個數(shù)據(jù)必須有相同的拷貝每個庫里的同一個數(shù)據(jù)內(nèi)容必須是一致的)
分布式事務
隔離性
當多個用戶并發(fā)訪問數(shù)據(jù)庫時,比如同時操作同一張表時,數(shù)據(jù)庫為每一個用戶開啟的事務,
不能被其他事務的操作所干擾,多個并發(fā)事務之間要相互隔離
持久性
一個事務一旦被提交了,那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的,
即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會丟失提交事務的操作
隔離級別(隔離性)
- 未提交讀(臟讀)[READ UNCOMMITTED]
事務可以讀取為提交的的數(shù)據(jù)[問題多,實際少用] - 提交讀(不可重復讀)[READ COMMITTED]
一個事務開始到結(jié)束,所做的所有修改對其他事務是不可見的[兩次所執(zhí)行的查詢,得到的結(jié)果可能不一樣] - 可重復讀[REPEATABLE READ]
- 解決臟讀問題
2.保證同一事務中多次讀取同樣的記錄結(jié)果是一致的
3.幻讀:當一個事務讀取某一范圍的記錄,又有新事務在這個范圍插入新的記錄,上一個事務再次讀取就會出現(xiàn)此問題-->幻行
- 可串行化[SERALIZABLE]
1.強制事務串行執(zhí)行,避免幻行問題
2.讀取的每一行數(shù)據(jù)上加鎖增大開銷和爭鎖問題(實際上少用除了非常需要保持數(shù)據(jù)一致性且可以接受沒有并發(fā)的情況)

SQL隔離級別
死鎖
兩個或者多個事務在同一資源上相互占用,請求鎖定對方的資源從而導致惡性循環(huán)現(xiàn)象
出現(xiàn)死鎖原因:
1.數(shù)據(jù)出現(xiàn)沖突
2.存儲引擎實現(xiàn)方式導致
解決:大多數(shù)情況只需要重新執(zhí)行因死鎖回滾的事務

image.png
·
Mysql 事務
常見事務存儲引擎:innodb NDB Cluster
Mysql 事務
多版本并發(fā)控制
Mysql存儲引擎
//查看存儲引擎顯示表的相關信息
SHOW TABLE STATUS LIKE 表名
- innoDB 存儲引擎