mysql小白系列_01 原理

1.什麼是MVCC？有什麼做用？

Multi-Version Concurrency Conrol 多版本併發控
爲解決數據庫併發讀寫可能會出現不一致數據的狀況，須要實現數據庫的併發訪問控制，寫時複製產生數據副本。

2.ACID中的I是怎麼實如今的？

Isolation隔離性

• 讀未提交 A事務更改了某個數據但並未提交，B事務能夠訪問這個數據的舊值。
• 讀已提交 A事務更改了某個數據並提交，B事務只能讀到更改後的數據。
• 可重複讀 A事務更改某個數據前，B事務能讀到這個數據，A更改這個數據後，B事務能讀到這個數據的新值
• 串行化 A事務操做完了，B事務才能操做。

3.2PC在數據庫中是怎麼來實現的？

請求、提交兩階段
要麼全部參與者贊成，進行事務操做，若是有任何一個參與者不一樣意事務操做，則進行事務取消，保證全部數據副本都是一致的。
優勢：原理簡單、實現方便 缺點：二階段會產生阻塞、協調者存在單點、參與者可能收不到協調者的commit請求，形成數據不一致
3PC解決了2PC的阻塞問題，可是數據不一致依然存在

4. 簡單講講CAP/base/paxos算法

CAP

三選二，P分區可擴展性不能放棄，組合一般是PC或者PA

BASE

CAP的擴展，容許一段時間內的數據不一致來得到系統可用性，並最終數據達成一致性

PAXOS

• follower
• candidate
• leader

1. 初始階段全部節點都是follower，當folower監聽聽不到leader，將本身置爲candidate，發起投票選舉leader
2. follower成爲candidate的超時時間，每一個follower都有隨機超時時間，誰先timeout，誰先成爲candidate，並給本身投一票，再向其餘節點發起投片邀請
3. 若是其餘節點在這輪選舉尚未投過票，那麼就給candidate投票，而後重置本身的選舉timeout
4. 若是首先超時的candidate獲得大多數的投票，將成爲leader，以後定時向follower發送心跳
5. 若是兩個follower同時成爲candidate，並獲得相同票數，則其餘follower選擇timeout後成爲candidate，繼續開始重新一輪選舉leader

http://www.javashuo.com/article/p-qeojaqpe-kq.html

---

ACID

事務的四個特徵

1.Atomic原子性

事務必須是一個原子的操做序列單元，事務中包含的各項操做在一次執行過程當中，要麼所有執行成功，要麼所有不執行，任何一項失敗，整個事務都須要回滾，只有所有都執行成功，整個事務纔算成功。
原子不可分，要麼成功提交，要麼失敗回滾

2.Consistency一致性

事務的執行不能破壞數據庫數據的完整性和一致性，事務在執行以前和以後，數據庫都必須處於一致性狀態。
oracle數據庫（SCN）在不一致狀態下，是沒法open的

3.Isolation隔離性

在併發環境中，併發事務是相互隔離的，一個事務的執行不能被其餘事務干擾。即不通的事務併發操縱相同的數據時，每一個事務都有各自完整的數據空間，即一個事務內部的操做及使用的數據對其餘併發事務是隔離的，併發執行的各個事務之間不能相互干擾。
我寫個人讀個人，不會被你所寫所讀所幹擾

SQL中4個事務隔離級別

• 讀未提交

容許髒讀。A事務更改了某個數據但並未提交，B事務能夠訪問這個數據的舊。 

• 讀已提交

容許不可重複讀。只容許讀到已經提交的數據。A事務累加n從0到10，B事務只能讀到結果10，中間值沒法讀取，同時C事務將n累加到20，B事務再次讀取，讀到結果20 

• 可重複讀

- 容許幻讀。保證在事務處理過程當中，屢次讀取同一個數據時，其值都和事務開始時刻時是一致的。 - 禁止髒讀、不可重複讀。 - 幻讀，同一個事務不一樣的時間段內讀取n，值多是0,10,20 - 幻讀，就是不一樣事務，讀到的n多是0，多是10，多是20， 

• 串行化

全部事務順序執行，不能併發。 

看到要麼是提交前的數據，要麼是提交後的數據

不控制併發的情形

• 一類丟失更新：兩事務讀取同一數據，A修改字段1，B修改字段2，後提交的恢復先提交修改的字段，形成其中之一更新丟失。
• 二類丟失更新：兩事務讀取同一數據，後提交的覆蓋先提交的修改。
• 髒讀：讀到未提交的值，萬一事務回滾，產生髒讀。
• 不可重複讀：兩個查詢之間，被另一個事務修改了數據的內容，產生內容不一致，所見不是實際數據。
• 幻讀：兩個查詢之間，被另外的事務插入或者刪除了記錄，產生結果集不一致。

4.Durability持久性

一個事務一旦提交，它對數據庫中對應數據的狀態變動就應該是永久性的，即便發生系統崩潰或機器宕機，只要數據庫可以從新啓動，那麼必定可以將其恢復到事務成功結束時的狀態。
提交的事務只要數據庫能打開，數據就存在，沒提交的回滾丟失

---

什麼事MVCC？有什麼做用

Multi-Version Concurrency Conrol 多版本併發控制

• 解決問題：
  • 控制併發操做並下降系統開銷
  • 鎖機制也能夠控制併發，但開銷稍大。
• MVCC實現：基於時間點保存數據的快照來實現，不用存儲引擎的MVCC實現機制也不同，典型的有：
  • 樂觀併發控制
  • 悲觀併發控制

innodb的MVCC

• 每行記錄後面保存兩個隱藏的列
• 分別是行建立時間、行刪除時間
• 保存的是系統版本號（相似事務ID），並非實際時間值
• 每開始一個新的事務，系統版本號自增
• 事務開始時刻的系統版本號會做爲事務的ID

http://blog.csdn.net/whoamiyang/article/details/51901888
http://blog.sina.com.cn/s/blog_711b11fd0101bhks.html 怎麼查看着兩個隱藏列的？

2PC在數據庫中是怎麼來實現的？

• 分佈式一致性 分佈式系統中，爲保證數據高可用，將數據的多個副本放置到不一樣的物理機上，用戶的增刪改查對全部的數據副本都須要保證是一致的。 解決分佈式一致性問題的算法：
• 2PC Two Phase Commit Protocol 二階段提交協議
• 3PC Three Phase Commit Protocol 三階段提交協議
• Paxos

2PC

角色：

• 協調者（coordinator) 一般只有一個
• 事務參與者（participants、cohorts、workers），一般有多個，數據存儲系統這是副本個數

兩個階段：

• 請求階段（commit-request phase、表決階段、votingphase，選舉階段）
  • 協調者將通知事務參與者準備提交或取消事務，而後進入表決過程。
  • 表決過程當中，參與者將告知協調者本身的決策：
    贊成：事務參與者本地做業執行成功
    取消：本地做業執行故障
• 提交階段（commit phase）
  • 協調者將基於第一個階段的投票結構進行決策：提交或取消
  • 當且僅當全部的參與者贊成提交事務，協調者才通知全部的參與者提交事務
  • 不然協調者將通知全部的參與者取消事務
  • 參與者在接收到協調者發來的消息後執行響應的操做

http://blog.csdn.net/shenlan211314/article/details/7283948
摘抄一段：
階段1：

1. A發郵件給B、C和D，提出下週三去登山，問是否贊成。
2. 那麼此時A須要等待B、C和D的郵件。
3. B、C和D分別查看本身的日程安排表。B、C發現本身在當日沒有活動安排，則發郵件告訴A它們贊成下週三去爬長城。
4. 因爲某種緣由，D白天沒有查看郵件。
5. 那麼此時A、B和C均須要等待。
6. 到晚上的時候，D發現了A的郵件，而後查看日程安排，發現週三當天已經有別的安排，那麼D回覆A說活動取消吧。
   階段2：
7. 此時A收到了全部活動參與者的郵件，而且A發現D下週三不能去登山。
8. 那麼A將發郵件通知B、C和D，下週三爬長城活動取消。
9. 此時B、C回覆A「太惋惜了」，D回覆A「很差意思」。至此該事務終止。
   要是上面D一直不回覆，那麼不是A、B阻塞到永久了？

簡單講講CAP/base/paxos算法。

CAP

一個分佈式系統不可能同時知足一致性Consistency、可用性Avaiablity、分區容錯性Partition tolerance這三個基本需求，最多隻能知足其中的兩項。

• 一致性 分佈式環境中，一致性指多個數據副本之間可否保持一致的特性。
  • 在一致性要求下，當一個系統在數據一致的狀態下執行更新操做後，
  • 應該保證系統的數據任然處於一致的狀態。
• 可用性 系統提供的服務必須一直處於可用的狀態，對於用戶的每個操做請求總能在有限的時間內返回結果。
  • 有限時間內
    對於用戶的一個操做請求，系統在指定時間內返回處理結果，則系統是可用的
    若是超過指定時間，則系統是不可用的
  • 返回正常結果
    系統完成處理用戶請求後，返回正常響應結果，不是異常
• 分區容錯性 分佈式系統在遇到任何網絡分區故障時，任然須要可以保證對外提供知足一致和可用的服務，除非是整個網絡環境都發生了故障
  應用組合
• 放棄P 就是放棄系統可擴展性
• 放棄A 遇到網絡分區或者其餘故障，受影響服務中止服務，即不可用
• 放棄C 放棄強一致性，在一段時間窗口內沒法實時保證數據的一致性
  選擇PA或者PC，P是不能放棄的

base

CAP演化而來，即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方法來使系統最終一致性。

• Basically Available 基本可用
  指分佈式系統出現不可預知的故障的時候，容許損失部分可用性，但不等於系統不可用
  • 響應時間上的損失
    當出現故障時，響應時間增長
  • 功能上的損失
    當流量高峯期時，屏蔽一些功能的使用以保證系統穩定性-服務降級
• Soft state 軟狀態
  與硬狀態相對，指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的構成存在延時。
• Eventually consistent 最終一致性
  強調系統中全部的數據副本，在通過一段時間的通報後，最終可以達成一個一致的狀態。其本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。

最終一致性分爲:

• 因果一致性 Causal consistency
  A進程更新完數據後通知B進程，B進程在A進程更新後的最新值上操做
• 讀己之所寫 Read your writes
  進程A更新一項數據後，它老是能訪問到本身更新過的最新值
• 會話一致性 Session consistency
  將數據一致性框定在會話當中，在一個回話當中實現讀己值所寫的一致性。
  即更新後，客戶端在同一個會話中始終能肚帶該項數據的最新值
• 單調讀一致性 Monotonic read consistency
  若是一個進程從系統中讀取一個數據項的某個值，那麼系統對於該進程後續的任何數據訪問都不該該返回更舊的值
• 單調寫一致性 Monotoic write consistency
  一個系統須要保證來自同一個進程的寫操做被順序執行。

BASE定理經過犧牲一致性來得到可用性，並容許數據在一段時間是不一致的，但最終達到一致狀態

paxos

三類角色

• follower
• candidate
• leader

1. 初始階段全部節點都是follower，當folower監聽聽不到leader，將本身置爲candidate，發起投票選舉leader
2. follower成爲candidate的超時時間，每一個follower都有隨機超時時間，誰先timeout，誰先成爲candidate，並給本身投一票，再向其餘節點發起投片邀請
3. 若是其餘節點在這輪選舉尚未投過票，那麼就給candidate投票，而後重置本身的選舉timeout
4. 若是首先超時的candidate獲得大多數的投票，將成爲leader，以後定時向follower發送心跳
5. 若是兩個follower同時成爲candidate，並獲得相同票數，則其餘follower選擇timeout後成爲candidate，繼續開始重新一輪選舉leader

http://www.javashuo.com/article/p-wgrnzeon-kt.html http://www.javashuo.com/article/p-qeojaqpe-kq.html