事務(wù)簡(jiǎn)介

事務(wù)的核心是鎖和并發(fā)
采用同步控制的方式保證并發(fā)的情況下性能盡可能高渐逃，且容易理解耍目。
優(yōu)勢(shì)是方便理解;它的劣勢(shì)是性能比較低觉鼻。

盡管看起來計(jì)算機(jī)可以并行處理很多事情朋鞍，但實(shí)際上每個(gè)CPU單位時(shí)間內(nèi)只能做一件事。
而且計(jì)算機(jī)就做三件事朝巫，讀鸿摇、寫、算來回重復(fù)做這三件事劈猿，所有的任務(wù)都可以看成這三件事的集合拙吉。
計(jì)算機(jī)的這種特性引出了一個(gè)問題：當(dāng)多個(gè)人去讀、算揪荣、寫操作時(shí)庐镐，如果不加訪問控制，系統(tǒng)勢(shì)必會(huì)產(chǎn)生沖突变逃。
而事務(wù)相當(dāng)于在讀、算怠堪、寫操作之外增加了同步的模塊揽乱，進(jìn)而保證只有一個(gè)線程進(jìn)入事務(wù)當(dāng)中，而其他線程不會(huì)進(jìn)入粟矿。

事務(wù)與并發(fā)控制相通

單個(gè)事務(wù)單元

事物就三個(gè)指令
beginTransaction
commit
rollback
begin和commit之間的過程就是一個(gè)事務(wù)單元

事務(wù)的四大特性分別是：原子性凰棉、一致性、隔離性和持久性

• 原子性陌粹，指的是事務(wù)中包含的所有操作要么全做撒犀，要么全不做;
• 一致性，是指在事務(wù)開始以前掏秩，數(shù)據(jù)庫(kù)處于一致性的狀態(tài)或舞，事務(wù)結(jié)束后，數(shù)據(jù)庫(kù)也必須處于一致性的狀態(tài);
• 隔離性要求系統(tǒng)必須保證事務(wù)不受其他并發(fā)執(zhí)行的事務(wù)的影響;

• 持久性是指一個(gè)事務(wù)一旦成功完成蒙幻，它對(duì)數(shù)據(jù)庫(kù)的改變必須是永久的映凳，即使是在系統(tǒng)遇到故障的情況下也不會(huì)丟失，數(shù)據(jù)的重要性決定了事務(wù)的持久性的重要邮破。

  
  
  單個(gè)事務(wù)單元
  
  

  事務(wù)單元是通過Begin-Traction诈豌，然后Commit(Begin-Traction、Commit和Rollback之間所有針對(duì)數(shù)據(jù)的寫入抒和、讀取的操作都應(yīng)該添加同步訪問)矫渔，Begin和Commit之間就是一個(gè)同步的事務(wù)單元。例如摧莽，Bob給Smith 100塊錢就是一個(gè)事務(wù)單元庙洼，這個(gè)過程中有很多步操作，具體如上圖所示;但對(duì)業(yè)務(wù)來說，僅是一個(gè)轉(zhuǎn)賬的操作送膳。

一組事務(wù)單元

一組事務(wù)單元

事務(wù)單元的實(shí)現(xiàn)方式

Two Phase Lock(2PL)是數(shù)據(jù)庫(kù)中非常重要的一個(gè)概念。
數(shù)據(jù)庫(kù)操作Insert起愈、Update只恨、Delete都是先讀再寫的操作。
例如Insert操作是先讀取數(shù)據(jù)抬虽，讀取之后判斷數(shù)據(jù)是否存在官觅，如果不存在，則寫入該數(shù)據(jù)斥赋，如果數(shù)據(jù)存在缰猴，則返回錯(cuò)誤。
假設(shè)在該場(chǎng)景下沒有讀操作疤剑，只是單純寫入數(shù)據(jù)滑绒，則數(shù)據(jù)本身并沒有事務(wù)操作，Delete隘膘、Update操作與之類似疑故。
數(shù)據(jù)庫(kù)利用這些操作的特性，在每一次查詢過程中弯菊，只要查到數(shù)據(jù)纵势，就會(huì)在該數(shù)據(jù)上加鎖。
理論上，所有被讀取的數(shù)據(jù)都已加鎖钦铁，不會(huì)再被其他人讀到软舌，也就是說對(duì)數(shù)據(jù)進(jìn)行的中間操作狀態(tài)對(duì)所有人都不可見，當(dāng)所有中間狀態(tài)完成后牛曹，提交操作時(shí)佛点，解開鎖，此時(shí)數(shù)據(jù)對(duì)所有系統(tǒng)可見黎比。
例如在轉(zhuǎn)賬過程中超营，所有人只能看到兩種狀態(tài)：

• 開始時(shí)，A有錢阅虫，B沒錢;
• 結(jié)束時(shí)演闭，B有錢，A沒錢颓帝，

中間A減掉錢米碰，B尚未加上錢的狀態(tài)被鎖隱藏掉了迅办，這個(gè)操作就是數(shù)據(jù)庫(kù)中處理事務(wù)的最標(biāo)準(zhǔn)的方式报亩。

事務(wù)單元的實(shí)現(xiàn)方式

如上圖所示：

• Trx2(JoeLock)與其他事務(wù)不相關(guān)，因此可以并行執(zhí)行;
• Trx1需要Lock兩個(gè)數(shù)據(jù)Boblock和Smithlock布疼，
• Trx3同樣需要Lock這兩個(gè)數(shù)據(jù)工猜，因此Trx3必須等待，且等待在 Boblock上菱蔬，Trx3會(huì)等到Trx1完成后才會(huì)開始;
• Joe事務(wù)會(huì)先結(jié)束篷帅。

單機(jī)事務(wù)的典型異常應(yīng)對(duì)策略

處理事務(wù)的常見方法

處理事務(wù)的常見方法有排隊(duì)法、排他鎖拴泌、讀寫鎖魏身、MVCC等方式。

排隊(duì)法

排隊(duì)法

IOPS: 每秒進(jìn)行讀寫（I/O）操作的次數(shù)，多用于數(shù)據(jù)庫(kù)等場(chǎng)合埋涧，衡量隨機(jī)訪問的性能板辽，

由于磁盤的IOPS僅為內(nèi)存的幾千分之一，意味著必須將大量的讀寫操作聚合成一個(gè)Batch后再提交時(shí)才能達(dá)到較好的性能棘催。而將大量請(qǐng)求攢到一起的方式就是異步劲弦，也就是請(qǐng)求本身和線程不綁定，線程可以不Block(本質(zhì)來說還是一種多線程的方式)醇坝，處理完一個(gè)線程后再處理其他線程邑跪。這種做法的核心是將大量不同的請(qǐng)求提交到一個(gè)Buffer中，再由該Buffer統(tǒng)一讀取或者寫入磁盤呼猪，從而提高效率画畅。
在慢速設(shè)備中，多線程或異步非常常見宋距，在設(shè)計(jì)系統(tǒng)時(shí)轴踱，面對(duì)磁盤、網(wǎng)絡(luò)谚赎、SSD等慢速設(shè)備必須考慮使用多線程淫僻。

排他鎖

排他鎖

多線程場(chǎng)景，可以利用排他鎖快速隔離并發(fā)讀寫事務(wù)壶唤。
數(shù)據(jù)庫(kù)中有一些事務(wù)單元是共享的雳灵，
上圖中的事務(wù)單元1是共享的，事務(wù)單元2/3共享數(shù)據(jù);
針對(duì)事務(wù)單元2/3共享數(shù)據(jù)的所有讀寫B(tài)lock住闸盔，事務(wù)單元1單獨(dú)用一個(gè)鎖來控制悯辙，用這種方式完成系統(tǒng)的訪問控制。

讀寫鎖

讀寫鎖

只讀事務(wù)過程中迎吵，數(shù)據(jù)一定不被修改躲撰，因此多個(gè)查詢操作可以并行執(zhí)行，針對(duì)讀讀場(chǎng)景的優(yōu)化自然而然產(chǎn)生——讀寫鎖击费。
讀寫鎖的核心是在多次讀的操作中茴肥，同時(shí)允許多個(gè)讀者來訪問共享資源，提高并發(fā)性荡灾。

MVCC

MVCC

本質(zhì)是Copy On Write瓤狐，也就是每次寫都是以重新開始一個(gè)新的版本的方式寫入數(shù)據(jù)瞬铸，數(shù)據(jù)庫(kù)包含了之前的所有版本。在數(shù)據(jù)讀的過程中础锐，先申請(qǐng)一個(gè)版本號(hào)嗓节，如果該版本號(hào)小于正在寫入的版本號(hào)，則數(shù)據(jù)一定可以查詢到皆警，無需等到新版本完全寫完即可返回查詢結(jié)果拦宣。
讀讀不阻塞，讀寫/寫讀不阻塞信姓，只有寫寫操作串行鸵隧。

事務(wù)的調(diào)優(yōu)原則

事務(wù)的調(diào)優(yōu)的思路是在不影響業(yè)務(wù)應(yīng)用的前提下：

• 第一，盡可能減少鎖的覆蓋范圍意推，例如Myisam表鎖到Innodb的行鎖就是一個(gè)減少鎖覆蓋范圍的過程;對(duì)于原位鎖(排他鎖豆瘫、讀寫鎖等)可變?yōu)镸VCC多版本(本質(zhì)仍然是減少鎖的范圍)。
• 第二菊值，增加鎖上可并行的線程數(shù)外驱，例如讀鎖和寫鎖的分離，允許并行讀取數(shù)據(jù)腻窒。
• 第三昵宇，選擇正確鎖類型，其中悲觀鎖適合并發(fā)爭(zhēng)搶比較嚴(yán)重的場(chǎng)景; 樂觀鎖適合并發(fā)爭(zhēng)搶不太嚴(yán)重

分布式事務(wù)

二段式提交

分為準(zhǔn)備階段和提交階段

準(zhǔn)備階段

1. 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)儿子，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)瓦哎。
2. 參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志柔逼。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）
3. 各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問杭煎。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功，則它返回一個(gè)”同意”消息卒落；如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗，則它返回一個(gè)”中止”消息蜂桶。

提交階段

1. 如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)儡毕，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息；
2. 否則扑媚，發(fā)送提交(Commit)消息腰湾；
3. 參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過程中使用的鎖資源疆股。(注意:必須在最后階段釋放鎖資源)

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí)

1. 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”正式提交(commit)”的請(qǐng)求费坊。
2. 參與者節(jié)點(diǎn)正式完成操作，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源旬痹。
3. 參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”完成”消息附井。
4. 協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”完成”消息后讨越，完成事務(wù)。

如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為”中止”永毅，或者 協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)

1. 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請(qǐng)求把跨。
2. 參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源沼死。
3. 參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”消息着逐。
4. 協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”回滾完成”消息后，取消事務(wù)意蛀。

三段式提交

三階段提交有兩個(gè)改動(dòng)點(diǎn)

1. 引入超時(shí)機(jī)制耸别。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。
2. 在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段县钥。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的秀姐。

三階段提交就有CanCommit、PreCommit魁蒜、DoCommit三個(gè)階段囊扳。

CanCommit階段

3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求兜看，參與者如果可以提交就返回Yes響應(yīng)锥咸，否則返回No響應(yīng)。

1. 事務(wù)詢問 協(xié)調(diào)者向參與者發(fā)送CanCommit請(qǐng)求细移。詢問是否可以執(zhí)行事務(wù)提交操作搏予。然后開始等待參與者的響應(yīng)。
2. 響應(yīng)反饋 參與者接到CanCommit請(qǐng)求之后弧轧，正常情況下雪侥，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)精绎，并進(jìn)入預(yù)備狀態(tài)速缨。否則反饋No

PreCommit階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以事務(wù)的PreCommit操作。
根據(jù)響應(yīng)情況代乃，有以下兩種可能旬牲。
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行搁吓。

1. 發(fā)送預(yù)提交請(qǐng)求 協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求原茅，并進(jìn)入Prepared階段。
2. 事務(wù)預(yù)提交 參與者接收到PreCommit請(qǐng)求后堕仔，會(huì)執(zhí)行事務(wù)操作擂橘，并將undo和redo信息記錄到事務(wù)日志中。
3. 響應(yīng)反饋 如果參與者成功的執(zhí)行了事務(wù)操作摩骨，則返回ACK響應(yīng)通贞，同時(shí)開始等待最終指令朗若。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后滑频，協(xié)調(diào)者都沒有接到參與者的響應(yīng)捡偏，那么就執(zhí)行事務(wù)的中斷。

1. 發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求峡迷。
2. 中斷事務(wù) 參與者收到來自協(xié)調(diào)者的abort請(qǐng)求之后（或超時(shí)之后银伟，仍未收到協(xié)調(diào)者的請(qǐng)求），執(zhí)行事務(wù)的中斷绘搞。

doCommit階段

該階段進(jìn)行真正的事務(wù)提交彤避，也可以分為以下兩種情況。
執(zhí)行提交

1. 發(fā)送提交請(qǐng)求 協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)夯辖，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)琉预。并向所有參與者發(fā)送doCommit請(qǐng)求。
2. 事務(wù)提交 參與者接收到doCommit請(qǐng)求之后蒿褂，執(zhí)行正式的事務(wù)提交圆米。并在完成事務(wù)提交之后釋放所有事務(wù)資源。
   3.響應(yīng)反饋 事務(wù)提交完之后啄栓，向協(xié)調(diào)者發(fā)送Ack響應(yīng)娄帖。
   4.完成事務(wù) 協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)昙楚。

中斷事務(wù)
協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)近速，也可能響應(yīng)超時(shí)），那么就會(huì)執(zhí)行中斷事務(wù)堪旧。

1. 發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求
2. 事務(wù)回滾 參與者接收到abort請(qǐng)求之后削葱，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源淳梦。
   3.反饋結(jié)果 參與者完成事務(wù)回滾之后析砸，向協(xié)調(diào)者發(fā)送ACK消息
   4.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷爆袍。

在doCommit階段首繁，如果參與者無法及時(shí)接收到來自協(xié)調(diào)者的doCommit或者abort請(qǐng)求時(shí)，會(huì)在等待超時(shí)之后螃宙，會(huì)繼續(xù)進(jìn)行事務(wù)的提交。
這個(gè)應(yīng)該是基于概率來決定的所坯，當(dāng)進(jìn)入第三階段時(shí)谆扎，說明參與者在第二階段已經(jīng)收到了PreCommit請(qǐng)求，那么協(xié)調(diào)者產(chǎn)生PreCommit請(qǐng)求的前提條件是他在第二階段開始之前芹助，收到所有參與者的CanCommit響應(yīng)都是Yes堂湖。
一旦參與者收到了PreCommit闲先，意味他知道大家其實(shí)都同意修改了
所以，一句話概括就是无蜂，當(dāng)進(jìn)入第三階段時(shí)伺糠，由于網(wǎng)絡(luò)超時(shí)等原因，雖然參與者沒有收到commit或者abort響應(yīng)斥季，但是他有理由相信：成功提交的幾率很大训桶。

一致性

分布式事務(wù)控制的最終目標(biāo)是實(shí)現(xiàn)一致性，方案大體分為實(shí)時(shí)一致性和最終一致性兩種：
兩階段提交是比較典型的實(shí)時(shí)一致性方案
提供補(bǔ)償事務(wù)和基于消息隊(duì)列的異步處理方案是最終一致性方案酣倾。

目前的主流數(shù)據(jù)庫(kù)在本地事務(wù)提交后都不能回滾舵揭。

事務(wù)隔離性的本質(zhì)就是如何正確處理讀寫沖突和寫寫沖突，這在分布式事務(wù)中又是一個(gè)難點(diǎn)

分布式事務(wù)最初起源于處理多個(gè)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)一致性問題躁锡，但隨著IT技術(shù)的高速發(fā)展午绳，大型系統(tǒng)中逐漸使用SOA服務(wù)化接口替換直接對(duì)數(shù)據(jù)庫(kù)操作，所以如何保證各個(gè)SOA服務(wù)之間的數(shù)據(jù)一致性也被劃分到分布式事務(wù)的范疇映之。

兩段式事務(wù)

兩段式事務(wù)也就是著名的XA事務(wù)拦焚，XA是由X/Open組織提出的分布式事務(wù)的規(guī)范，也是使用最為廣泛的多數(shù)據(jù)庫(kù)分布式事務(wù)規(guī)范杠输，目前市面上主流的數(shù)據(jù)庫(kù)MySQL赎败，Oralce，SQLServer等都支持XA事務(wù)抬伺。

基于SOA接口的分布式事務(wù)

目前比較流行的SOA分布式事務(wù)解決方案是TCC事務(wù)螟够，TCC事務(wù)的全稱為：Try-Confirm/Cancel，翻譯成中文即：嘗試峡钓、確定妓笙、取消。
TCC模式的扣除金幣操作能岩，接口提供者針對(duì)扣除金幣這一操作需要提供三個(gè)SOA接口：

1. 扣除金幣Try接口寞宫，嘗試扣除金幣，這里只是鎖定玩家賬戶中需要被扣除的金幣拉鹃，并沒有真正扣除金幣辈赋，類似于信用卡的預(yù)授權(quán)；假設(shè)玩家賬戶中100金幣膏燕，調(diào)用該接口鎖定60金幣后钥屈，鎖定的金幣不能再被使用，玩家賬戶中還有40金幣可用
2. 扣除金幣Confirm接口坝辫，確定扣除金幣篷就，這里將真正扣除玩家賬戶中被鎖定的金幣，類似于信用卡的確定預(yù)授權(quán)完成刷卡
3. 扣除金幣Cancel接口近忙，取消扣除金幣竭业，被鎖定的金幣將返還到玩家的賬戶中智润，類似于信用卡的撤銷預(yù)授權(quán)取消刷卡

SOA接口調(diào)用者如何使用這三個(gè)接口呢？
調(diào)用者先執(zhí)行扣除金幣Try接口未辆，再去執(zhí)行其他任務(wù)（比如添加道具）窟绷，當(dāng)其他任務(wù)執(zhí)行成功，調(diào)用者執(zhí)行扣除金幣Confirm接口確認(rèn)扣除金幣咐柜，而當(dāng)其他任務(wù)執(zhí)行異常兼蜈，調(diào)用者則執(zhí)行扣除金幣Cancel接口取消扣除金幣。
即使我們使用了TCC事務(wù)炕桨，也無法完美的保證各個(gè)SOA服務(wù)之間的數(shù)據(jù)一致性饭尝。
但TCC事務(wù)為我們屏蔽了大多數(shù)異常導(dǎo)致的數(shù)據(jù)不一致，同時(shí)一般情況下献宫，進(jìn)行Confirm或Cancel操作時(shí)產(chǎn)生異常的概率極小極小钥平，所以對(duì)于一些強(qiáng)一致性系統(tǒng)，我們還是會(huì)使用TCC事務(wù)來保證多個(gè)SOA服務(wù)之間的數(shù)據(jù)一致性姊途。

TCC事務(wù)存在不小的性能問題
其實(shí)我們使用的基于后置提交的多數(shù)據(jù)庫(kù)事務(wù)與TCC事務(wù)都屬于強(qiáng)一致性事務(wù)涉瘾，使用強(qiáng)一致性事務(wù)能保證事務(wù)的實(shí)時(shí)性，但卻很難在高并發(fā)環(huán)境中保證性能捷兰。
最終一致性事務(wù)這幾個(gè)字看起來很牛逼立叛，但說白了就是異步數(shù)據(jù)補(bǔ)償，即在核心流程我們只保證核心數(shù)據(jù)的實(shí)時(shí)數(shù)據(jù)一致性贡茅，對(duì)于非核心數(shù)據(jù)秘蛇，我們通過異步程序來保證數(shù)據(jù)一致性。

異步數(shù)據(jù)補(bǔ)償

目前主流觸發(fā)異步數(shù)據(jù)補(bǔ)償?shù)姆绞接袃煞N：

1. 使用消息隊(duì)列實(shí)時(shí)觸發(fā)數(shù)據(jù)補(bǔ)償顶考，核心流程在保證核心數(shù)據(jù)的一致性后赁还，使用消息隊(duì)列的方式通知異步程序進(jìn)行數(shù)據(jù)補(bǔ)償，這種方式能近乎實(shí)時(shí)的使數(shù)據(jù)達(dá)到最終一致性驹沿，但如果消息隊(duì)列或異步程序出現(xiàn)異常艘策，數(shù)據(jù)一致性也將不能保證
2. 使用定時(shí)任務(wù)周期性觸發(fā)數(shù)據(jù)補(bǔ)償，核心流程在保證核心數(shù)據(jù)的一致性后直接返回渊季，由定時(shí)任務(wù)周期性觸發(fā)數(shù)據(jù)補(bǔ)償程序朋蔫，這種方式雖不能像消息隊(duì)列那樣能近乎實(shí)時(shí)的使數(shù)據(jù)達(dá)到最終一致性，但數(shù)據(jù)補(bǔ)償程序出現(xiàn)異常時(shí)却汉，我們能比較容易在下個(gè)周期對(duì)數(shù)據(jù)進(jìn)行修復(fù)驯妄，能最大限度的保證數(shù)據(jù)的一致性
   上面兩種異步數(shù)據(jù)補(bǔ)償?shù)姆绞礁饔欣祝㈥?duì)列方式實(shí)時(shí)性強(qiáng)合砂，但在異常情況下一致性弱青扔，而定時(shí)任務(wù)方式實(shí)時(shí)性弱，但在異常情況下一致性強(qiáng)。
   注：消息系統(tǒng)還是很穩(wěn)定的赎懦，一般選擇第一種
   其實(shí)最優(yōu)的策略是同時(shí)使用消息隊(duì)列與定時(shí)任務(wù)觸發(fā)數(shù)據(jù)補(bǔ)償。
   正常情況下幻工，我們使用消息隊(duì)列近乎實(shí)時(shí)的異步觸發(fā)數(shù)據(jù)補(bǔ)償励两，而針對(duì)那些極少發(fā)生的異常，我們使用定時(shí)任務(wù)周期性的修補(bǔ)數(shù)據(jù)囊颅。

大師談經(jīng)驗(yàn)

對(duì)原理的取舍
形成模式当悔，產(chǎn)品
在理解了原理的情況下，做出更多取舍踢代，同業(yè)務(wù)貼合更好的解決業(yè)務(wù)訴求
容易理解的模型往往性能都不好盲憎，性能好的模型往往不容易理解
《分布式系統(tǒng)原理與范型》
理解了數(shù)據(jù)庫(kù)原理，你才能知道我們?cè)谀抢镒隽巳∩?/p>

排它鎖是最高級(jí)鎖

其它鎖都是讀寫鎖的升級(jí)

單機(jī)事務(wù)——小結(jié)
原子性胳挎、一致性饼疙、隔離性（擴(kuò)展MVCC/SNAPSHOT ISOLATION）、持久性

從單機(jī)事務(wù)到分布式事務(wù)

GTS（全局事務(wù)服務(wù)）柔性事務(wù)
事務(wù)就是保證代碼向你寫的一樣慕爬，真實(shí)的執(zhí)行窑眯，這就是事務(wù)的核心
所有的時(shí)間戳分配器都會(huì)面臨單機(jī)的自增問題

分布式事務(wù)的主要難點(diǎn)

事務(wù)延遲變大問題
事務(wù)異常處理
日志記錄
MVCC的順序問題

分布式數(shù)據(jù)庫(kù)方案

共享磁盤方案
鎖延遲變大問題
采用遠(yuǎn)程內(nèi)存直接訪問RDMA （遠(yuǎn)程直接內(nèi)存讀寫）(FC/IB) infin band
Oracle RAC（非常有代表性）
事務(wù)的異常處理
放棄分布式事務(wù)

RAC

Raid的方案，Shared Disk
優(yōu)勢(shì)：
兼容性好医窿，SQL全兼容
能提升讀性能
劣勢(shì)：
寫性能巨大下降磅甩，原因要等待多臺(tái)Cache全寫入，這是一個(gè)同步等待的過程
高可用切換時(shí)間長(zhǎng)姥卢，就是不可用時(shí)切換到備機(jī)時(shí)間長(zhǎng)
擴(kuò)展性有限卷要，4臺(tái)基本是極限，否則寫入時(shí)間沒法要了
傳遞距離有限制独榴。

從北京到深圳僧叉，光速需30ms

廣播算法，面包法算法（棄用）

一般談分布式DB括眠，就會(huì)談2PC彪标，就會(huì)談MVCC

標(biāo)準(zhǔn)的兩階段提交，只要可讀就說明數(shù)據(jù)是一致的掷豺，因?yàn)閮呻A段提交是可以保證一致性

事務(wù)要解決的是四種情況下捞烟，操作的沖突問題
WR
WW
RR
RW

讀寫鎖只能在RR的時(shí)候能夠并行
MVCC只有在WW時(shí)，不能并行
MVCC有個(gè)單點(diǎn)問題

PG-XL/PG-XC方案：發(fā)號(hào)機(jī)
存儲(chǔ)可以擴(kuò)展

TrueTimeAPI
可以在多機(jī)房?jī)?nèi)做數(shù)據(jù)同步
在未來的一段時(shí)間內(nèi)当船，因?yàn)楸淼恼`差很小题画，那么很長(zhǎng)時(shí)間就不用對(duì)表。
使用原子鐘+GPS來維持時(shí)間準(zhǔn)確性
利用TrueTimeAPI來保證happen before德频，時(shí)間為2e

利用這個(gè)時(shí)間服務(wù)器苍息，就可以當(dāng)做全局SCN或Trx_id服務(wù)使用
代價(jià)：
每個(gè)事務(wù)的提交之間的延遲
山寨貨NTP服務(wù)
機(jī)器與機(jī)器之間時(shí)間誤差比較大（150ms）
無法保證happen-before
Spanner解決跨城數(shù)據(jù)高可用，自動(dòng)容錯(cuò)，標(biāo)準(zhǔn)的2PC+MVCC