什么場景下會產(chǎn)生分布式事務唤殴？
????????在支付異步回調(diào)的情況下，支付寶發(fā)送http請求給第三方平臺到腥，第三方平臺需要更改支付狀態(tài)以及訂單狀態(tài)朵逝，在此場景下，第三方平臺更改本地支付數(shù)據(jù)庫的支付狀態(tài)后乡范，通知訂單服務更改訂單的狀態(tài)配名，在此程序后，如果代碼出現(xiàn)異常晋辆，由于有聲明式事務的存在渠脉，本地支付服務的數(shù)據(jù)庫會進行回滾，變成未支付狀態(tài)瓶佳，但是訂單服務的狀態(tài)卻無法回滾芋膘，訂單服務的訂單的狀態(tài)變成已支付狀態(tài)，這就出現(xiàn)了訂單數(shù)據(jù)庫和支付數(shù)據(jù)庫數(shù)據(jù)不一致的情況霸饲，這便是分布式事務產(chǎn)生的場景之一为朋。
什么是分布式事務？
????????分布式事務就是指事務的參與者厚脉、支持事務的服務器习寸、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。以上是百度百科的解釋傻工，簡單的說霞溪，就是一次大的操作由不同的小操作組成孵滞，這些小的操作分布在不同的服務器上，且屬于不同的應用鸯匹，分布式事務需要保證這些小操作要么全部成功剃斧，要么全部失敗。本質(zhì)上來說忽你，分布式事務就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。
分布式事務的理論
1臂容、cap理論
1）數(shù)據(jù)一致性（consistency）
????????如果系統(tǒng)對一個寫操作返回成功科雳，那么之后的讀請求都必須讀到這個新數(shù)據(jù)；如果返回失敗脓杉，那么所有讀操作都不能讀到這個數(shù)據(jù)糟秘，對調(diào)用者而言數(shù)據(jù)具有強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)
????????一致性指"all nodes see the same data at the same time",即更新操作成功并返回客戶端完成后球散，所有節(jié)點在統(tǒng)一時間的數(shù)據(jù)完全一致尿赚。分布式的一致性，對于一致性蕉堰，可以分為從客戶端和服務端兩個不通的視角凌净。 從客戶端來看，一致性主要指的是多并發(fā)訪問更新過的數(shù)據(jù)如何獲取的問題屋讶。 從服務端來看冰寻，則是更新如何復制發(fā)布到整個系統(tǒng)，以保證數(shù)據(jù)的一致性皿渗。 一致性是因為有并發(fā)讀寫才有的問題斩芭，因此在理解一致性的問題時，一定要注意結(jié)合考慮并發(fā)讀寫的場景乐疆。從客戶端角度划乖，多進程并發(fā)訪問時，更新過的數(shù)據(jù)在不同進程如何獲取的不同策略挤土，決定了不同的一致性琴庵。對于關系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到仰美，這是強一致性细卧。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性筒占。如果經(jīng)過一段時間后要求能訪問到更新后的數(shù)據(jù)贪庙，則是最終一致性。
2）可用性（availability）
? ? ? ? 可用性指所有讀寫請求在一定時間內(nèi)得到響應翰苫，可終止止邮、不會一直等待这橙。
????????可用性指的是"Reads and writes always succeed",即服務一直可用，而且是正常的響應時間导披。對于一個可用性的分布式系統(tǒng)屈扎，每一個非故障節(jié)點必須對每一個請求做出響應。也就是撩匕，該系統(tǒng)使用的任何算法必須最終終止鹰晨。當同時要求分區(qū)容忍性時，這是一個很強的定義：即使是嚴重的網(wǎng)絡錯誤止毕，每個請求必須終止模蜡。好的可用性主要是指系統(tǒng)能夠很好的為用戶服務，不出現(xiàn)用戶操作失敗或者訪問超時等用戶體驗不好的情況扁凛∪碳玻可用性通常情況下可用性和分布式數(shù)據(jù)冗余，負載均衡等有著很大的關聯(lián)谨朝。
3）分區(qū)容錯性（partition-tolerance）
????????? 分區(qū)容錯性是指在網(wǎng)絡分區(qū)的情況下卤妒，被分隔的節(jié)點仍能正常對外服務。
? ? ? ? ? 分區(qū)容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system”字币，即分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡分區(qū)故障的時候则披，仍然能夠?qū)ν馓峁M足一致性 和可用性的服務。 分區(qū)容錯性和擴展性緊密相關洗出。在分布式應用中收叶，可能因為一些分布式的原因?qū)е孪到y(tǒng)無法正常運轉(zhuǎn)。好的分區(qū)容錯性要求能夠使應用雖然是一個分布式系統(tǒng)共苛，而看上去卻好像是在一個可以運轉(zhuǎn)正常的整體判没。比如 現(xiàn)在的分布式系統(tǒng)中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉(zhuǎn)滿足系統(tǒng)需求隅茎，或者是機器之間有網(wǎng)絡異常澄峰，將分布式系統(tǒng)分隔未獨立的幾個部分，各個部分還能維持分布式系統(tǒng)的運作辟犀，這樣就具有好的分區(qū)容錯性俏竞。
base理論的三個屬性不能同時存在，只能認選其二堂竟。
2魂毁、Base理論
????????BASE理論是指，Basically Available（基本可用）出嘹、Soft-state（ 軟狀態(tài)/柔性事務）席楚、Eventual Consistency（最終一致性）。是基于CAP定理演化而來税稼，是對CAP中一致性和可用性權(quán)衡的結(jié)果烦秩。核心思想：即使無法做到強一致性垮斯，但每個業(yè)務根據(jù)自身的特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性只祠。
1兜蠕、基本可用：指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性抛寝，保證核心可用熊杨。但不等價于不可用。比如：搜索引擎0.5秒返回查詢結(jié)果盗舰，但由于故障晶府，2秒響應查詢結(jié)果；網(wǎng)頁訪問過大時岭皂，部分用戶提供降級服務，等沼头。
2爷绘、軟狀態(tài)：軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，并且該中間狀態(tài)不會影響系統(tǒng)整體可用性进倍。即允許系統(tǒng)在不同節(jié)點間副本同步的時候存在延時土至。
3、最終一致性：
系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后猾昆，最終能夠達到一致的狀態(tài)陶因，不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。最終一致性是弱一致性的一種特殊情況垂蜗。BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)楷扬，通過犧牲強一致性來獲得可用性。ACID是傳統(tǒng)數(shù)據(jù)庫常用的概念設計贴见，追求強一致性模型烘苹。
ACID，指數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素的縮寫片部。包含：原子性（Atomicity）镣衡、一致性（Consistency）、隔離性（Isolation）档悠、持久性（Durability）廊鸥。
Base理論為柔性事務
3、柔性事務和剛性事務
柔性事務滿足BASE理論（基本可用辖所，最終一致）?
剛性事務滿足ACID理論?
柔性事務分為
1.兩階段型?
2.補償型?
3.異步確保型?
4.最大努力通知型幾種惰说。 由于支付寶整個架構(gòu)是SOA架構(gòu)，因此傳統(tǒng)單機環(huán)境下數(shù)據(jù)庫的ACID事務滿足了分布式環(huán)境下的業(yè)務需要缘回，以上幾種事務類似就是針對分布式環(huán)境下業(yè)務需要設定的助被。
分布式事務解決方案
1剖张、常見的分布式事務解決方案
1）2pc兩端提交協(xié)議
2）3pc三段提交協(xié)議
3） tcc
4）MQ（補償和重試機制）
5）其他補償方式（如：支付寶異步回調(diào)）
2、2pc（兩端提交協(xié)議）
了解2pc之前必須了解下XA接口
1）什么是XA接口揩环？（分布式事務協(xié)調(diào)者）
????????XA–eXtended Architecture 在事務中意為分布式事務?XA由協(xié)調(diào)者(coordinator搔弄，一般為transaction manager)和參與者(participants,一般在各個資源上有各自的resource manager)共同完成。在MySQL中丰滑，XA事務有兩種顾犹。
2）2pc兩端提交協(xié)議
所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執(zhí)行階段）。
XA一般由兩階段完成褒墨，稱為two-phase commit(2PC)炫刷。?
階段一為準備階段，即所有的參與者準備執(zhí)行事務并鎖住需要的資源郁妈。參與者ready時浑玛，向transaction manager匯報自己已經(jīng)準備好。?
階段二為提交階段噩咪。當transaction manager確認所有參與者都ready后顾彰，向所有參與者發(fā)送commit命令。?
如下圖所示：?
3）詳細流程
第一階段（投票階段）：
1胃碾、協(xié)調(diào)者節(jié)點向所有參與者節(jié)點詢問是否可以執(zhí)行提交操作涨享，并開始等待各參與者節(jié)點的響應。
2仆百、參與者節(jié)點執(zhí)行詢問發(fā)起為止的所有的事務操作厕隧，并將Undo信息和Redo信息寫入日志。（注意：若成功這里其實每個參與者已經(jīng)執(zhí)行了事務操作）
3俄周、各個參與者節(jié)點響應協(xié)調(diào)者節(jié)點發(fā)起的詢問吁讨。如果參與者節(jié)點的事務操作實際執(zhí)行成功，則返回一個"同意"消息峦朗，如果參與者節(jié)點的事務操作實際執(zhí)行失敗挡爵，則他返回一個"終止"消息。
第二階段（提交執(zhí)行階段）：
當協(xié)調(diào)者節(jié)點從所有參與者節(jié)點獲得的相應消息都為"同意"時：
? ? ? ? 1甚垦、協(xié)調(diào)者節(jié)點向所有參與者節(jié)點發(fā)出"正式提交"的請求茶鹃。
? ? ? ? 2、參與者節(jié)點正式完成操作艰亮，并釋放在整個事務期間占用的資源闭翩。
? ? ? ? 3、參與者節(jié)點向協(xié)調(diào)者節(jié)點發(fā)送"完成"消息迄埃。
? ? ? ? 4疗韵、協(xié)調(diào)者節(jié)點受到所有參與者節(jié)點反饋的"完成"消息后，完成事務侄非。
如果其中任一參與者節(jié)點在第一階段返回的響應消息為"中止"蕉汪，或者協(xié)調(diào)者節(jié)點在第一階段的詢問超時之前無法獲取所有參與者節(jié)點響應消息時：
? ? ? ? 1流译、協(xié)調(diào)者節(jié)點向所有參與者節(jié)點發(fā)出"回滾操作"的請求。
? ? ? ? ?2者疤、參與者節(jié)點利用之前寫入的Undo信息執(zhí)行回滾福澡，并釋放在整個事務期間內(nèi)占用的資源
? ? ? ? ?3、參與者節(jié)點向協(xié)調(diào)者節(jié)點發(fā)送"回滾完成"的消息
? ? ? ? ?4驹马、協(xié)調(diào)者節(jié)點受到所有參與者節(jié)點反饋的"回滾完成"消息后革砸，取消事務。
不管結(jié)果如何糯累，第二階段都會結(jié)束當前事務
4）2pc兩端提交協(xié)議的缺點
? ? ? ? ?1算利、執(zhí)行過程中，所有的參與節(jié)點都時事務阻塞型的泳姐。當參與者節(jié)點占用公共資源時效拭，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。
? ? ? ? ?2胖秒、參與者發(fā)生故障缎患。協(xié)調(diào)者需要給每個參與者額外制定超時機制，超時后扒怖，整個事務失斀衔（沒有容錯機制）
? ? ? ? ?3业稼、協(xié)調(diào)者發(fā)生故障盗痒，參與者會一直阻塞下去。需要額外的備機進行容錯低散。
? ? ? ? ?4俯邓、二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了熔号。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者稽鞭，這條事務的狀態(tài)也是不確定的，沒人知道事務是否被已經(jīng)提交引镊。
5）XA性能問題
????????XA的性能很低朦蕴。一個數(shù)據(jù)庫的事務和多個數(shù)據(jù)庫間的XA事務性能對比可發(fā)現(xiàn)，性能差10倍左右弟头。因此要盡量避免XA事務吩抓，例如可以將數(shù)據(jù)寫入本地，用高性能的消息系統(tǒng)分發(fā)數(shù)據(jù)赴恨≌钊ⅲ或使用數(shù)據(jù)庫復制等技術。
3伦连、3PC(三段提交協(xié)議)
1）與2pc不同的是雨饺，三階段提交有兩個改動點钳垮。
? ? ? ?1、引入超時機制额港，同時在協(xié)調(diào)者和參與者中都加入了超時機制饺窿。
? ? ? ?2、在第一階段和第二階段中插入了一個準備階段锹安，保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的短荐。
2）3pc流程
? ? 1、CanCommit階段
? ? ? ? ? ? ①事務詢問
? ? ? ? ? ? ? ? 協(xié)調(diào)者向參與者發(fā)送CanCommit請求叹哭。詢問是否可以執(zhí)行事務提交操作忍宋。然后等待參與者的響應
? ? ? ? ? ? ②響應反饋
? ? ? ? ? ? ? ? 參與者街道CanCommit請求后，正常情況下风罩，如果其自身認為可以順利提交事務糠排，則返回yes響應，? ?并進入預備狀態(tài)超升。否則反饋No
? ? ?2入宦、PreCommit階段
? ? ? ? ? ? 協(xié)調(diào)者根據(jù)參與者的反應情況來決定是否可以進行事務的PreCommit操作，根據(jù)響應情況室琢，有一下兩種可能乾闰。假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應，那么就會執(zhí)行事務的預執(zhí)行盈滴。
? ? ? ? 1涯肩、發(fā)送預提交請求
? ? ? ? 協(xié)調(diào)者向參與者發(fā)送PreCommit請求，并進入PrePared階段巢钓。
? ? ? ? 2病苗、事務預提交
? ? ? ? 參與者接收到了PreCommit請求后，會執(zhí)行事務操作症汹，并將undo和redo事務信息記錄到事務日志中硫朦。
? ? ? ? 3、響應反饋
? ? ? ? 如果參與者成果的執(zhí)行了事務操作背镇，則返回ACK響應咬展，同時開始等待最終指令。
? ? ? ? 假如有任何一個參與者向協(xié)調(diào)者發(fā)送了No響應瞒斩，或者等待超時之后破婆，協(xié)調(diào)者都沒有接到參與者的響應，那么就執(zhí)行事務的中斷济瓢。
? ? ? ? 1荠割、發(fā)送中斷請求
? ? ? ? 協(xié)調(diào)者向所有的參與者發(fā)送abort請求。
? ? ? ? 2、中斷事務
? ? ? ? 參與者收到來自協(xié)調(diào)者的abort請求后（或超時之后蔑鹦，仍未收到協(xié)調(diào)者的請求）夺克，執(zhí)行事務的中斷。
? ? 3嚎朽、doCommit階段
? ? ? ? 該階段進行真正的事務提交铺纽，也可以分為一下兩種情況。
? ? 3.1 執(zhí)行提交事務
? ? ? ? 1哟忍、發(fā)送提交請求
? ? ? ? ? ? 協(xié)調(diào)者接收到參與者發(fā)送的ACK響應狡门，那么他將從預提交狀態(tài)進入提交狀態(tài)。
? ? ? ? 2锅很、事務提交
? ? ? ? ? ? 參與者接收到doCommit請求之后其馏，執(zhí)行正式的事務提交，并在完成事務提交后釋放所有的事務資源爆安。
? ? ? ? 3叛复、響應反饋
? ? ? ? ? ? 事務提交完成之后，向協(xié)調(diào)者發(fā)送ack響應扔仓。
? ? ? ? 4褐奥、完成事務
? ? ? ? ? ? 協(xié)調(diào)者接收到所有參與者的ack響應之后，完成事務翘簇。
? ? 3.2 中斷事務
? ? 協(xié)調(diào)者沒有接收到參與者發(fā)送ack響應（可能是接受者發(fā)送的不是ack響應撬码，也可能超時），那么就會執(zhí)行中斷事務版保。
? ? ? ? 1呜笑、發(fā)送中斷請求
? ? ? ? ? ? 協(xié)調(diào)者向所有參與者發(fā)送abort請求。
? ? ? ? 2找筝、事務回滾
? ? ? ? ? ? 參與者接受到abort請求之后蹈垢，利用其在階段二記錄的undo信息來執(zhí)行事務的回滾操作慷吊，并在完成回滾之后釋放所有的事務資源袖裕。
? ? ? ? 3、反饋結(jié)果
? ? ? ? ? ? 參與者完成事務回滾后溉瓶，向協(xié)調(diào)者發(fā)送ack消息
? ? ? ? 4急鳄、中斷事務
? ? ? ? ? ? 協(xié)調(diào)者接收到參與者反饋的ack消息之后，執(zhí)行事務的中斷堰酿。
未完待續(xù)疾宏。。
