建站
咨詢
售后
建站咨詢
新聞中心
五大分布式事務，你了解多少？
作者： 牧小農 2021-04-27 07:52:18
前端
分布式 事務(Transaction)：一般是指要做的或所做的事情，由 事務開始(begin transaction) 和 事務結束(end transaction) 之間執(zhí)行的全體操作組成。
本文轉載自微信公眾號「牧小農」，作者牧小農。轉載本文請聯(lián)系牧小農公眾號。
一、前言
事務(Transaction)：一般是指要做的或所做的事情，由 事務開始(begin transaction) 和 事務結束(end transaction) 之間執(zhí)行的全體操作組成。
簡單的講就是：要么全部被執(zhí)行，要么就全部失敗。
那分布式事務，自然就是運行在分布式系統(tǒng)中的事務，是由多個不同的機器上的事務組合而成的。同上，只有分布式系統(tǒng)中所有事務執(zhí)行了才能是成功，否則失敗。
事務的基本特征ACID：
- 原子性(Atomicity)： 一個事務是一個不可分割的工作單位，事務中包括的諸操作要么都做，要么都不做。
- 一致性： 指事務執(zhí)行前和執(zhí)行后，數(shù)據是完整的。
- 隔離性： 一個事務的執(zhí)行不能被其他事務干擾。即一個事務內部的操作及使用的數(shù)據對并發(fā)的其他事務是隔離的，并發(fā)執(zhí)行的各個事務之間不能互相干擾。
- 持久性： 也稱為永久性，一個事務一旦提交，它對數(shù)據庫中數(shù)據的改變就應該是永久性的保存下來了。
二、分布式事務的目標和實際應用場景
分布式事務的目標：解決多個獨立事務一致性的問題。
比如說我們有一個功能，訂單系統(tǒng)，橫跨了多個微服務，由于每個微服務不在一個庫，沒法用數(shù)據庫事務來保證事務，那么這個時候我們就可以使用分布式事務
例如： 商城項目，有用戶支付了一個訂單，在支付系統(tǒng)中，支付表進行了更新，在另一個訂單系統(tǒng)中，訂單庫里面訂單的狀態(tài)就要變成已支付，那么在訂單表和支付表，他們在不同的庫，如何保證兩個數(shù)據庫之間的事務呢
支付操作：支付修改余額，修改訂單狀態(tài)
三、分布式事務解決方案
- 二階段提交協(xié)議(2PC)
- 三階段提交協(xié)議(3PC)
- 補償事務(TCC)
- 消息中間件實現(xiàn)
- seata框架
四、 二階段提交協(xié)議(2PC)
基于XA協(xié)議的，采取強一致性，遵從ACID
2PC：(2階段提交協(xié)議)，是基于XA/JTA規(guī)范。
4.1 XA
XA是由X/Open組織提出的分布式事務的架構(或者叫協(xié)議)。XA架構主要定義了 (全局)事務管理器(Transaction Manager)和(局部)資源管理器(Resource Manager)之間 的接口。
XA接口是雙向的系統(tǒng)接口，在事務管理器(Transaction Manager)以及一個或多個資源管理器(Resource Manager)之間形成通信橋梁。也就是說，在基于XA的一個事務中，我們可以針對多個資源進行事務管理，例如一個系統(tǒng)訪問多個數(shù)據庫，或即訪問數(shù)據庫、又訪問像消息中間件這樣的資源。這樣我們就能夠實現(xiàn)在多個數(shù)據庫和消息中間件直接實現(xiàn)全部提交、或全部取消的事務。XA規(guī)范不是java的規(guī)范，而是一種通用的規(guī)范。
4.2 JTA
JTA(Java Transaction API)，是J2EE的編程接口規(guī)范，它是XA協(xié)議的JAVA實現(xiàn)。它主要定義了：
一個事務管理器的接口javax.transaction.TransactionManager，定義了有關事務的開始、提交、撤回等操作。一個滿足XA規(guī)范的資源定義接口javax.transaction.xa.XAResource，一種資源如果要支持JTA事務，就需要讓它的資源實現(xiàn)該XAResource接口，并實現(xiàn)該接口定義的兩階段提交相關的接口。
4.3 流程圖
4.4 提交過程
1.請求階段，(commit-request phase，或稱表決階段，voting phase)，步驟(1-5) 在請求階段，協(xié)調者將通知事務參與者準備提交或取消事務，然后進入表決過程。在表決過程中，參與者將告知協(xié)調者自己的決策：同意(事務參與者本地作業(yè)執(zhí)行成功)或取消(本地作業(yè)執(zhí)行故障)。
2.提交階段(commit phase)，步驟(6-7) 在該階段，協(xié)調者將基于第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協(xié)調者才通知所有的參與者提交事務，否則協(xié)調者將通知所有的參與者取消事務。參與者在接收到協(xié)調者發(fā)來的消息后將執(zhí)行響應的操作。
4.5 缺點
- 單點故障：事務的發(fā)起、提交還是取消，均是由老大協(xié)調者管理的，只要協(xié)調者宕機，那就涼涼了。
- 同步阻塞缺點：從上面介紹以及例子可看出，我們的參與系統(tǒng)中在沒收到老大的真正提交還是取消事務指令的時候，就是鎖定當前的資源，并不真正的做些事務相關操作，所以，整個分布式系統(tǒng)環(huán)境就是阻塞的。
- 數(shù)據不一致缺點：就是說在老大協(xié)調者向小弟們發(fā)送真正提交事務的時候，部分網路故障，造成部分系統(tǒng)沒收到真正的指令，那么就會出現(xiàn)部分提交部分沒提交，因此，這就會導致數(shù)據的不一致。
4.6 無法解決的問題
當協(xié)調者出錯，同時參與者也出錯時，兩階段無法保證事務執(zhí)行的完整性?？紤]協(xié)調者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使有了新的協(xié)調者，這條事務的狀態(tài)也是不確定的，沒人知道事務是否被已經提交。知道的人已經被滅口了。
五、 三階段提交協(xié)議(3PC)
采取強一致性，遵從ACID。在二階段上增加了：超時和預提交機制。有這三個主階段，canCommit、preCommit、doCommit這三個階段
5.1 流程圖
5.2 流程
1.CanCommit階段： 3PC的CanCommit階段其實和2PC的準備階段很像。協(xié)調者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
2.PreCommit階段： Coordinator根據Cohort的反應情況來決定是否可以繼續(xù)事務的PreCommit操作。
根據響應情況，有以下兩種可能。A.假如Coordinator從所有的Cohort獲得的反饋都是Yes響應，那么就會進行事務的預執(zhí)行：發(fā)送預提交請求。Coordinator向Cohort發(fā)送PreCommit請求，并進入Prepared階段。事務預提交。Cohort(一群大兵)接收到PreCommit請求后，會執(zhí)行事務操作，并將undo和redo信息記錄到事務日志中。響應反饋。如果Cohort成功的執(zhí)行了事務操作，則返回ACK響應，同時開始等待最終指令。
B.假如有任何一個Cohort向Coordinator發(fā)送了No響應，或者等待超時之后，Coordinator都沒有接到Cohort的響應，那么就中斷事務：發(fā)送中斷請求。Coordinator向所有Cohort發(fā)送abort請求。中斷事務。Cohort收到來自Coordinator的abort請求之后(或超時之后，仍未收到Cohort的請求)，執(zhí)行事務的中斷。
3.DoCommit階段： 該階段進行真正的事務提交，也可以分為以下兩種情況:
執(zhí)行提交 A.發(fā)送提交請求。Coordinator接收到Cohort發(fā)送的ACK響應，那么他將從預提交狀態(tài)進入到提交狀態(tài)。并向所有Cohort發(fā)送doCommit請求。B.事務提交。Cohort接收到doCommit請求之后，執(zhí)行正式的事務提交。并在完成事務提交之后釋放所有事務資源。C.響應反饋。事務提交完之后，向Coordinator發(fā)送ACK響應。D.完成事務。Coordinator接收到所有Cohort的ACK響應之后，完成事務。
中斷事務 協(xié)調者沒有接收到參與者發(fā)送的ACK響應，那么就執(zhí)行中斷事務。
A.發(fā)送中斷請求 協(xié)調者向所有參與者發(fā)送abort請求 B.事務回滾 參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執(zhí)行事務的回滾操作，并在完成回滾之后釋放所有的事務資源。C.反饋結果 參與者完成事務回滾之后，向協(xié)調者發(fā)送ACK消息 D.中斷事務 協(xié)調者接收到參與者反饋的ACK消息之后，執(zhí)行事務的中斷。
5.3 缺點
如果進入PreCommit后，Coordinator發(fā)出的是abort請求，假設只有一個Cohort收到并進行了abort操作， 而其他對于系統(tǒng)狀態(tài)未知的Cohort會根據3PC選擇繼續(xù)Commit，此時系統(tǒng)狀態(tài)發(fā)生不一致性。
5.4 2PC 和 3PC 的區(qū)別
加了詢問，增大成功概率。
對于協(xié)調者(Coordinator)和參與者(Cohort)都設置了超時機制(在2PC中，只有協(xié)調者擁有超時機制，即如果在一定時間內沒有收到cohort的消息則默認失敗)。協(xié)調者掛了，參與者等待超時后，默認提交事務。有一丟進步。
如果參與者異常了，協(xié)調者也異常了，會造成其他參與者提交。
在2PC的準備階段和提交階段之間，插入預提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個階段。PreCommit是一個緩沖，保證了在最后提交階段之前各參與節(jié)點的狀態(tài)是一致的。
六、基于消息的最終一致性形式
采取最終一致性，遵從BASE理論。
BASE：全稱是，Basically Avaliable(基本可用)，Soft state(軟狀態(tài))，Eventually consistent(最終一致性)三個短語的縮寫，來自eBay的架構師提出。
Basically Avaliable： 就是在分布式系統(tǒng)環(huán)境中，允許犧牲掉部分不影響主流程的功能的不可用，將其降級以確保核心服務的正?？捎?。
Soft state： 就是指在事務中，我們允許系統(tǒng)存在中間狀態(tài)，且并不影響我們這個系統(tǒng)。就拿數(shù)據庫的主從復制來說，是完全允許復制的時候有延時的發(fā)生的。
Eventually consistent： 還是以數(shù)據庫主從復制為例說，雖然主從復制有小延遲，但是很快最終就數(shù)據保持一致了。
分布式事務不可能100%解決，只能提高成功概率。兩階段之間時間，毫秒級別。補救措施：定時任務補償。程序或腳本補償。人工介入。
七、TCC
解決方案：TCC(Try、Confirm、Cancel)，兩階段補償型方案。
從名字可以看出，實現(xiàn)一個事務，需要定義三個API：預先占有資源，確認提交實際操作資源，取消占有=回滾。
如果后兩個環(huán)節(jié)執(zhí)行一半失敗了，記錄日志，補償處理，通知人工。
2PC：是資源層面的分布式事務，一直會持有資源的鎖。
如果跨十幾個庫，一下鎖這么多數(shù)據庫，會導致，極度浪費資源。降低了吞吐量。
TCC：在業(yè)務層面的分布式事務，最終一致性，不會一直持有鎖。將鎖的粒度變小，每操作完一個庫，就釋放了鎖。
都是相對的：如果每天只有一個請求，用2PC 比 TCC 要性能高。因為tcc多了多次接口調用。而此時的2PC 不怕占用資源，反正就一個調用。高并發(fā)場景下TCC 優(yōu)勢要大。
八、消息中間件實現(xiàn)
消息隊列柔性事務流程圖：
1、操作支付表，然后在事件表里面插入一條數(shù)據，狀態(tài)為new狀態(tài)，放到數(shù)據庫，這個(1、2、3)操作都是在一個事務中，因為他們都是一個庫
2、定時任務讀取事件表，發(fā)送隊列，發(fā)送成功以后，將事件表new的狀態(tài)改為(published)，監(jiān)聽事件表，插入一條數(shù)據到事件表
3、定時任務讀庫是不是published事件表，如果是published事件表，更新訂單表，更新事件表為processed，這樣就將一個大事務，拆分成幾個幾個的小事務
表設計：
- 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 '事件內容，保存事件發(fā)生時需要傳遞的數(shù)據',
- `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 是一款開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。
官網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
- # 此服務的地址
- 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ù)據庫，并建表
分支事務表： branchtable全局事務表： globaltable全局鎖： lock_table
注意：表的結構不能錯
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;
十、小結
以上就是分布式事務的介紹，有不懂的小伙伴可以在討論留言，小農看到了會第一時間回復大家的，也歡迎各位小伙伴對文中有不足的地方補充和交流，謝謝，大家加油
網站名稱：五大分布式事務，你了解多少？
網頁URL：http://www.5511xx.com/article/cdsscjc.html
