分布式事務 - 簡書

1 分布式事務緣起
一切開始于單機時代铁蹈，人們面臨著兩個困境：單機服務器性能瓶頸 & 單點故障服務不可用／數據丟失。
因此，人們開始對服務器進行擴展马篮，加入更多的機器分擔性能問題，以及解決單點故障怜奖，通常使用兩種手段來擴展數據服務：

數據分區(qū)浑测，系統(tǒng)拆分 & 分庫分表
數據鏡像，備份&冗余
但是歪玲，這樣一來又產生了新的問題：
1）容災：結點fail后數據不丟失
2）多份數據的一致性問題
3）數據一致性帶來的性能問題
這就是分布式事務需要解決的問題迁央。
參考：https://coolshell.cn/articles/10910.html

2 ACID -> CAP -> BASE
ans：（1）ACID 即事務的特征，此處不再詳述

（2）C（Consistency 一致性）A（Availability 可用性）P（Partition tolerance 分區(qū)容錯性）滥崩，對于一個分布式系統(tǒng)岖圈，三者是無法全部滿足的，只能舍一取二钙皮。

如果放棄C（這里指強一致性）蜂科，那么系統(tǒng)無法保證數據實時一致，雖然在時間窗口之后數據將最終到達一致短条，但時間窗口內數據是不一致的导匣。
如果放棄A（可用性），那么當遇到故障時茸时，服務的質量會下降甚至無法提供正常服務
如果放棄P（容錯）贡定，那么就是放棄了分布式，放棄了系統(tǒng)擴展性可都。
一般來說P是絕不能放棄的缓待，因此一般在C or A 中權衡（看場景）蚓耽。

（3）BASE 是基于CAP演化而來，核心理念是即使無法做到強一致性旋炒，每個應用也可以根據自身特點步悠，采用適當的方式來使系統(tǒng)到達最終一致性。

BA（Basically Available 基本可用）瘫镇，出現(xiàn)故障時鼎兽，允許損失部分可用性，但不等于系統(tǒng)完全不可用汇四。例如：出現(xiàn)故障時，響應時間增加踢涌；或流量高峰時屏蔽部分功能以保證系統(tǒng)穩(wěn)定（服務降級）
S （Soft state 軟狀態(tài)）通孽，允許系統(tǒng)在不同結點的數據副本之間進行數據同步的過程存在時延。
E（Eventually consistent 最終一致性）睁壁，強調系統(tǒng)保證最終數據達到一致背苦，不需要保證實時的強一致性。
參考：https://segmentfault.com/a/1190000004468442

3 關于ZK
ZK 的目標是保證 CP潘明，即保證一致性 & 容錯行剂，放棄了可用性。
這一點體現(xiàn)在：leader選舉時钳降，集群不可用厚宰，如果網絡不穩(wěn)定或延遲較高，這個時間可能比預期更久遂填。
ZK 作為服務注冊中心的應用很多铲觉，但也許不是那么合適：
（1）ZK 的 CP 導致服務可能無法獲得其他服務的信息，此時如果能返回舊數據吓坚，比什么都不返回要強一些撵幽，即 AP 可能更合適。
（2）偶發(fā)的網絡延遲礁击，可能使 ZK 的心跳檢測失敗盐杂，使 ZK 誤以為服務不可用將其淘汰，這種情況如果發(fā)生在網絡割接時尤其危險哆窿。

4 分布式事務實現(xiàn)
4.1 2pc & 3pc
ans：（1）2pc链烈，Tow-Phase Commit 兩階段提交

2pc

2pc 的問題在于，在第二階段挚躯，如果某個參與者收不到協(xié)調器的commit/fallback指令测垛，那么它將一直處于“狀態(tài)未知”階段，完全不知道該怎么辦秧均。要么一直等待協(xié)調者食侮，要么重發(fā)第一階段的反饋号涯，資源不能得到釋放。
（2）3pc锯七，Three-Phase Commit 三階段提交

3pc

對于2pc链快，協(xié)調者對事務完成至關重要，一旦協(xié)調者異常那么可能block整個事務眉尸。因此衍生出了 3pc域蜗。3pc的關鍵點在于：

canCommit 階段不會鎖定資源，基于一個認知：如果第一階段所有參與者ok噪猾，那么第二階段有很大概率認為能夠提交成功霉祸，這樣第一階段的詢問能夠降低第二階段可能回滾的概率。
preCommit階段袱蜡，即使協(xié)調者故障丝蹭，參與者也不會等在原地，超時后將自動commit坪蚁，避免了 2pc 的問題奔穿。但這也存在一個隱患：preCommit 階段一旦不能正常通信，而參與者的默認操作是commit敏晤，如果數據需要rollback 那么會出現(xiàn)數據不一致的情況贱田。
2pc 3pc歸根到底是選擇系統(tǒng)可用性還是選擇系統(tǒng)一致性（CAP理論中的抉擇問題）
2pc 一致性好、可用性較低嘴脾，3pc 一致性較低男摧、可用性高
參考：https://segmentfault.com/a/1190000004474543
https://coolshell.cn/articles/10910.html
http://www.cnblogs.com/hubaoxi/p/6867203.html

4.2 TCC
ans： TCC（Try-Confirm-Cancel）又稱補償事務。其核心思想是："針對每個操作都要注冊一個與其對應的確認和補償（撤銷操作）"译打。它分為三個操作：

Try階段：主要是對業(yè)務系統(tǒng)做檢測及資源預留
Confirm階段：確認執(zhí)行業(yè)務操作
Cancel階段：取消執(zhí)行業(yè)務操作
TCC 本質是一個應用層面的2PC彩倚，優(yōu)點在于可以自己定義數據庫操作的粒度，使得降低鎖沖突扶平、提高吞吐成為可能帆离；缺點在于，對應用入侵性非常強结澄，業(yè)務邏輯的每個分枝都需要實現(xiàn) try/confirm/cancel 三個操作哥谷，confirm/cancel 必須實現(xiàn)冪等。

TCC

參考：https://www.cnblogs.com/wudimanong/p/10340948.html
https://juejin.im/post/5bf201f7f265da610f63528a

4.3 本地消息表（eBay 事件隊列方案——保證最終一致性—異步確保）
ans：核心思想是將分布式事務拆分成本地事務進行處理麻献。

上游服務在自己的數據庫中保存一個消息發(fā)送記錄们妥，然后將消息投遞出，這兩步可以用本地事務處理勉吻。
下游服務接收消息后進行處理监婶，之后通知上游成功 or 失敗
如果這之間出現(xiàn)故障導致下游未收到消息／超時，上游可以定時掃描消息發(fā)送記錄，將未完成的消息重發(fā)一遍
優(yōu)點：一種非常經典的實現(xiàn)惑惶，避免了分布式事務煮盼，實現(xiàn)了最終一致性。
缺點：消息表會耦合到業(yè)務系統(tǒng)中带污，如果沒有封裝好的解決方案僵控，會有很多雜活需要處理，但可以抽象出一個消息發(fā)送服務來處理
參考：https://blog.csdn.net/mine_song/article/details/64118963
https://blog.csdn.net/tangdong3415/article/details/59117947
https://cloud.tencent.com/developer/article/1117449
https://juejin.im/post/5bf2c6b6e51d456693549af4 前半部分