五大分布式事務(wù)，你了解多少？
本文轉(zhuǎn)載自微信公眾號「牧小農(nóng)」，作者牧小農(nóng)。轉(zhuǎn)載本文請聯(lián)系牧小農(nóng)公眾號。
一、前言
事務(wù)(Transaction)：一般是指要做的或所做的事情，由 事務(wù)開始(begin transaction) 和 事務(wù)結(jié)束(end transaction) 之間執(zhí)行的全體操作組成。
簡單的講就是：要么全部被執(zhí)行，要么就全部失敗。
那分布式事務(wù)，自然就是運行在分布式系統(tǒng)中的事務(wù)，是由多個不同的機器上的事務(wù)組合而成的。同上，只有分布式系統(tǒng)中所有事務(wù)執(zhí)行了才能是成功，否則失敗。
事務(wù)的基本特征ACID：
- 原子性(Atomicity)： 一個事務(wù)是一個不可分割的工作單位，事務(wù)中包括的諸操作要么都做，要么都不做。
- 一致性： 指事務(wù)執(zhí)行前和執(zhí)行后，數(shù)據(jù)是完整的。
- 隔離性： 一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾。即一個事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對并發(fā)的其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個事務(wù)之間不能互相干擾。
- 持久性： 也稱為永久性，一個事務(wù)一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的保存下來了。
二、分布式事務(wù)的目標(biāo)和實際應(yīng)用場景
分布式事務(wù)的目標(biāo)：解決多個獨立事務(wù)一致性的問題。
比如說我們有一個功能，訂單系統(tǒng)，橫跨了多個微服務(wù)，由于每個微服務(wù)不在一個庫，沒法用數(shù)據(jù)庫事務(wù)來保證事務(wù)，那么這個時候我們就可以使用分布式事務(wù)
例如： 商城項目，有用戶支付了一個訂單，在支付系統(tǒng)中，支付表進行了更新，在另一個訂單系統(tǒng)中，訂單庫里面訂單的狀態(tài)就要變成已支付，那么在訂單表和支付表，他們在不同的庫，如何保證兩個數(shù)據(jù)庫之間的事務(wù)呢
支付操作：支付修改余額，修改訂單狀態(tài)
三、分布式事務(wù)解決方案
- 二階段提交協(xié)議(2PC)
- 三階段提交協(xié)議(3PC)
- 補償事務(wù)(TCC)
- 消息中間件實現(xiàn)
- seata框架
四、 二階段提交協(xié)議(2PC)
基于XA協(xié)議的，采取強一致性，遵從ACID
2PC：(2階段提交協(xié)議)，是基于XA/JTA規(guī)范。
4.1 XA
XA是由X/Open組織提出的分布式事務(wù)的架構(gòu)(或者叫協(xié)議)。XA架構(gòu)主要定義了 (全局)事務(wù)管理器(Transaction Manager)和(局部)資源管理器(Resource Manager)之間 的接口。
XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器(Transaction Manager)以及一個或多個資源管理器(Resource Manager)之間形成通信橋梁。也就是說，在基于XA的一個事務(wù)中，我們可以針對多個資源進行事務(wù)管理，例如一個系統(tǒng)訪問多個數(shù)據(jù)庫，或即訪問數(shù)據(jù)庫、又訪問像消息中間件這樣的資源。這樣我們就能夠?qū)崿F(xiàn)在多個數(shù)據(jù)庫和消息中間件直接實現(xiàn)全部提交、或全部取消的事務(wù)。XA規(guī)范不是java的規(guī)范，而是一種通用的規(guī)范。
4.2 JTA
JTA(Java Transaction API)，是J2EE的編程接口規(guī)范，它是XA協(xié)議的JAVA實現(xiàn)。它主要定義了：
一個事務(wù)管理器的接口javax.transaction.TransactionManager，定義了有關(guān)事務(wù)的開始、提交、撤回等操作。一個滿足XA規(guī)范的資源定義接口javax.transaction.xa.XAResource，一種資源如果要支持JTA事務(wù)，就需要讓它的資源實現(xiàn)該XAResource接口，并實現(xiàn)該接口定義的兩階段提交相關(guān)的接口。
4.3 流程圖
4.4 提交過程
1.請求階段，(commit-request phase，或稱表決階段，voting phase)，步驟(1-5) 在請求階段，協(xié)調(diào)者將通知事務(wù)參與者準(zhǔn)備提交或取消事務(wù)，然后進入表決過程。在表決過程中，參與者將告知協(xié)調(diào)者自己的決策：同意(事務(wù)參與者本地作業(yè)執(zhí)行成功)或取消(本地作業(yè)執(zhí)行故障)。
2.提交階段(commit phase)，步驟(6-7) 在該階段，協(xié)調(diào)者將基于第一個階段的投票結(jié)果進行決策：提交或取消。當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。
4.5 缺點
- 單點故障：事務(wù)的發(fā)起、提交還是取消，均是由老大協(xié)調(diào)者管理的，只要協(xié)調(diào)者宕機，那就涼涼了。
- 同步阻塞缺點：從上面介紹以及例子可看出，我們的參與系統(tǒng)中在沒收到老大的真正提交還是取消事務(wù)指令的時候，就是鎖定當(dāng)前的資源，并不真正的做些事務(wù)相關(guān)操作，所以，整個分布式系統(tǒng)環(huán)境就是阻塞的。
- 數(shù)據(jù)不一致缺點：就是說在老大協(xié)調(diào)者向小弟們發(fā)送真正提交事務(wù)的時候，部分網(wǎng)路故障，造成部分系統(tǒng)沒收到真正的指令，那么就會出現(xiàn)部分提交部分沒提交，因此，這就會導(dǎo)致數(shù)據(jù)的不一致。
4.6 無法解決的問題
當(dāng)協(xié)調(diào)者出錯，同時參與者也出錯時，兩階段無法保證事務(wù)執(zhí)行的完整性?？紤]協(xié)調(diào)者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使有了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒人知道事務(wù)是否被已經(jīng)提交。知道的人已經(jīng)被滅口了。
五、 三階段提交協(xié)議(3PC)
采取強一致性，遵從ACID。在二階段上增加了：超時和預(yù)提交機制。有這三個主階段，canCommit、preCommit、doCommit這三個階段
5.1 流程圖
5.2 流程
1.CanCommit階段： 3PC的CanCommit階段其實和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。
2.PreCommit階段： Coordinator根據(jù)Cohort的反應(yīng)情況來決定是否可以繼續(xù)事務(wù)的PreCommit操作。
根據(jù)響應(yīng)情況，有以下兩種可能。A.假如Coordinator從所有的Cohort獲得的反饋都是Yes響應(yīng)，那么就會進行事務(wù)的預(yù)執(zhí)行：發(fā)送預(yù)提交請求。Coordinator向Cohort發(fā)送PreCommit請求，并進入Prepared階段。事務(wù)預(yù)提交。Cohort(一群大兵)接收到PreCommit請求后，會執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。響應(yīng)反饋。如果Cohort成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時開始等待最終指令。
B.假如有任何一個Cohort向Coordinator發(fā)送了No響應(yīng)，或者等待超時之后，Coordinator都沒有接到Cohort的響應(yīng)，那么就中斷事務(wù)：發(fā)送中斷請求。Coordinator向所有Cohort發(fā)送abort請求。中斷事務(wù)。Cohort收到來自Coordinator的abort請求之后(或超時之后，仍未收到Cohort的請求)，執(zhí)行事務(wù)的中斷。
3.DoCommit階段： 該階段進行真正的事務(wù)提交，也可以分為以下兩種情況:
執(zhí)行提交 A.發(fā)送提交請求。Coordinator接收到Cohort發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進入到提交狀態(tài)。并向所有Cohort發(fā)送doCommit請求。B.事務(wù)提交。Cohort接收到doCommit請求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。C.響應(yīng)反饋。事務(wù)提交完之后，向Coordinator發(fā)送ACK響應(yīng)。D.完成事務(wù)。Coordinator接收到所有Cohort的ACK響應(yīng)之后，完成事務(wù)。
中斷事務(wù) 協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)，那么就執(zhí)行中斷事務(wù)。
A.發(fā)送中斷請求 協(xié)調(diào)者向所有參與者發(fā)送abort請求 B.事務(wù)回滾 參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。C.反饋結(jié)果 參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息 D.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。
5.3 缺點
如果進入PreCommit后，Coordinator發(fā)出的是abort請求，假設(shè)只有一個Cohort收到并進行了abort操作， 而其他對于系統(tǒng)狀態(tài)未知的Cohort會根據(jù)3PC選擇繼續(xù)Commit，此時系統(tǒng)狀態(tài)發(fā)生不一致性。
5.4 2PC 和 3PC 的區(qū)別
加了詢問，增大成功概率。
對于協(xié)調(diào)者(Coordinator)和參與者(Cohort)都設(shè)置了超時機制(在2PC中，只有協(xié)調(diào)者擁有超時機制，即如果在一定時間內(nèi)沒有收到cohort的消息則默認(rèn)失敗)。協(xié)調(diào)者掛了，參與者等待超時后，默認(rèn)提交事務(wù)。有一丟進步。
如果參與者異常了，協(xié)調(diào)者也異常了，會造成其他參與者提交。
在2PC的準(zhǔn)備階段和提交階段之間，插入預(yù)提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。PreCommit是一個緩沖，保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的。
六、基于消息的最終一致性形式
采取最終一致性，遵從BASE理論。
BASE：全稱是，Basically Avaliable(基本可用)，Soft state(軟狀態(tài))，Eventually consistent(最終一致性)三個短語的縮寫，來自eBay的架構(gòu)師提出。
Basically Avaliable： 就是在分布式系統(tǒng)環(huán)境中，允許犧牲掉部分不影響主流程的功能的不可用，將其降級以確保核心服務(wù)的正常可用。
Soft state： 就是指在事務(wù)中，我們允許系統(tǒng)存在中間狀態(tài)，且并不影響我們這個系統(tǒng)。就拿數(shù)據(jù)庫的主從復(fù)制來說，是完全允許復(fù)制的時候有延時的發(fā)生的。
Eventually consistent： 還是以數(shù)據(jù)庫主從復(fù)制為例說，雖然主從復(fù)制有小延遲，但是很快最終就數(shù)據(jù)保持一致了。
分布式事務(wù)不可能100%解決，只能提高成功概率。兩階段之間時間，毫秒級別。補救措施：定時任務(wù)補償。程序或腳本補償。人工介入。
七、TCC
解決方案：TCC(Try、Confirm、Cancel)，兩階段補償型方案。
從名字可以看出，實現(xiàn)一個事務(wù)，需要定義三個API：預(yù)先占有資源，確認(rèn)提交實際操作資源，取消占有=回滾。
如果后兩個環(huán)節(jié)執(zhí)行一半失敗了，記錄日志，補償處理，通知人工。
2PC：是資源層面的分布式事務(wù)，一直會持有資源的鎖。
如果跨十幾個庫，一下鎖這么多數(shù)據(jù)庫，會導(dǎo)致，極度浪費資源。降低了吞吐量。
TCC：在業(yè)務(wù)層面的分布式事務(wù)，最終一致性，不會一直持有鎖。將鎖的粒度變小，每操作完一個庫，就釋放了鎖。
都是相對的：如果每天只有一個請求，用2PC 比 TCC 要性能高。因為tcc多了多次接口調(diào)用。而此時的2PC 不怕占用資源，反正就一個調(diào)用。高并發(fā)場景下TCC 優(yōu)勢要大。
八、消息中間件實現(xiàn)
消息隊列柔性事務(wù)流程圖：
1、操作支付表，然后在事件表里面插入一條數(shù)據(jù)，狀態(tài)為new狀態(tài)，放到數(shù)據(jù)庫，這個(1、2、3)操作都是在一個事務(wù)中，因為他們都是一個庫
2、定時任務(wù)讀取事件表，發(fā)送隊列，發(fā)送成功以后，將事件表new的狀態(tài)改為(published)，監(jiān)聽事件表，插入一條數(shù)據(jù)到事件表
3、定時任務(wù)讀庫是不是published事件表，如果是published事件表，更新訂單表，更新事件表為processed，這樣就將一個大事務(wù)，拆分成幾個幾個的小事務(wù)
表設(shè)計：
- CREATE TABLE `t_order_event` (
- `id` int(16) NOT NULL,
- `order_type` varchar(32) DEFAULT NULL COMMENT '事件類型（支付表支付完成，訂單表修改狀態(tài)）',
- `process` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '事件環(huán)節(jié)（new,published,processed)',
- `content` varchar(255) DEFAULT NULL COMMENT '事件內(nèi)容，保存事件發(fā)生時需要傳遞的數(shù)據(jù)',
- `create_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
- `update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
- PRIMARY KEY (`id`)
- ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
九、seata框架
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案。
官網(wǎng)Api(強烈推薦觀看)： https://seata.io/zh-cn/docs/overview/what-is-seata.html
seata下載地址： https://seata.io/zh-cn/blog/download.html
流程圖：
操作步驟：
1、下載seata server
https://seata.io/zh-cn/blog/download.html
2、修改file.conf
- service {
- #transaction service group mapping
- #修改，可不改,my_test_tx_group隨便起名字。
- vgroup_mapping.my_test_tx_group = "default"
- #only support when registry.type=file, please don't set multiple addresses
- # 此服務(wù)的地址
- default.grouplist = "127.0.0.1:8091"
- #disable seata
- disableGlobalTransaction = false
- }
- store {
- ## store mode: file、db
- # 修改
- mode = "db"
- ## file store property
- file {
- ## store location dir
- dir = "sessionStore"
- }
- ## database store property
- #db信息修改
- db {
- ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp) etc.
- datasource = "druid"
- ## mysql/oracle/h2/oceanbase etc.
- db-type = "mysql"
- driver-class-name = "com.mysql.cj.jdbc.Driver"
- url = "jdbc:mysql://127.0.0.1:3306/seata-server?useUnicode=true&useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai"
- user = "root"
- password = "root"
- }
- }
3、修改registry.conf
- registry {
- # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
- #修改
- type = "eureka"
- nacos {
- serverAddr = "localhost"
- namespace = ""
- cluster = "default"
- }
- #修改
- eureka {
- serviceUrl = "http://localhost:8761/eureka"
- application = "default"
- weight = "1"
- }
- redis {
- serverAddr = "localhost:6379"
- db = "0"
- }
- zk {
- cluster = "default"
- serverAddr = "127.0.0.1:2181"
- session.timeout = 6000
- connect.timeout = 2000
- }
- consul {
- cluster = "default"
- serverAddr = "127.0.0.1:8500"
- }
- etcd3 {
- cluster = "default"
- serverAddr = "http://localhost:2379"
- }
- sofa {
- serverAddr = "127.0.0.1:9603"
- application = "default"
- region = "DEFAULT_ZONE"
- datacenter = "DefaultDataCenter"
- cluster = "default"
- group = "SEATA_GROUP"
- addressWaitTime = "3000"
- }
- file {
- name = "file.conf"
- }
- }
- config {
- # file、nacos 、apollo、zk、consul、etcd3
- type = "file"
- nacos {
- serverAddr = "localhost"
- namespace = ""
- }
- consul {
- serverAddr = "127.0.0.1:8500"
- }
- apollo {
- app.id = "seata-server"
- apollo.meta = "http://192.168.1.204:8801"
- }
- zk {
- serverAddr = "127.0.0.1:2181"
- session.timeout = 6000
- connect.timeout = 2000
- }
- etcd3 {
- serverAddr = "http://localhost:2379"
- }
- file {
- name = "file.conf"
- }
- }
4、創(chuàng)建數(shù)據(jù)庫，并建表
分支事務(wù)表： branchtable全局事務(wù)表： globaltable全局鎖： lock_table
注意：表的結(jié)構(gòu)不能錯
5、在每個庫中增加 undo_log，用于回滾
- CREATE TABLE `undo_log` (
- `id` bigint(20) NOT NULL AUTO_INCREMENT,
- `branch_id` bigint(20) NOT NULL,
- `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
- `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
- `rollback_info` longblob NOT NULL,
- `log_status` int(11) NOT NULL,
- `log_created` datetime NOT NULL,
- `log_modified` datetime NOT NULL,
- `ext` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
- PRIMARY KEY (`id`) USING BTREE,
- UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) USING BTREE
- ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;
十、小結(jié)
以上就是分布式事務(wù)的介紹，有不懂的小伙伴可以在討論留言，小農(nóng)看到了會第一時間回復(fù)大家的，也歡迎各位小伙伴對文中有不足的地方補充和交流，謝謝，大家加油
