使用場景
例如: 電商下單 訂單生成+扣減庫存
訂單生成屬于訂單系統(tǒng),扣減庫存屬于庫存系統(tǒng)
db本地事務(wù)如何保證的?
redo、undo、ACID
AD(日志文件)、CI鎖 詳見MySql學(xué)習(xí)筆記//TODO
剛性事務(wù)acid&柔性事務(wù)base
剛性事務(wù):強(qiáng)一致性(ACID)
柔性事務(wù):基本可用,最終一致性(BASE理論)
BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個(gè)短語的縮寫。BASE理論是對CAP中一致性和可用性權(quán)衡的結(jié)果，其來源于對大規(guī)?；ヂ?lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。接下來看一下BASE中的三要素：
1、基本可用
基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候，允許損失部分可用性----注意，這絕不等價(jià)于系統(tǒng)不可用。比如：
（1）響應(yīng)時(shí)間上的損失。正常情況下，一個(gè)在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)故障，查詢結(jié)果的響應(yīng)時(shí)間增加了1~2秒
（2）系統(tǒng)功能上的損失：正常情況下，在一個(gè)電子商務(wù)網(wǎng)站上進(jìn)行購物的時(shí)候，消費(fèi)者幾乎能夠順利完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時(shí)候，由于消費(fèi)者的購物行為激增，為了保護(hù)購物系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁面
2、軟狀態(tài)
軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過程存在延時(shí)
3、最終一致性
最終一致性強(qiáng)調(diào)的是所有的數(shù)據(jù)副本，在經(jīng)過一段時(shí)間的同步之后，最終都能夠達(dá)到一個(gè)一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性。
XA協(xié)議
- 事務(wù)管理器(TM)Transaction Manager
- 資源管理器(RM)Resource Manager
2PC兩階段提交
- 流程
image.png
- 缺點(diǎn)
1.TM單點(diǎn)問題,掛了，整個(gè)2PC徹底完蛋
2.執(zhí)行過程是完全同步的。各參與者在等待其他參與者響應(yīng)的過程中都處于阻塞狀態(tài)，高并發(fā)性能問題
3.仍然存在不一致風(fēng)險(xiǎn)。如果由于網(wǎng)絡(luò)異常等意外導(dǎo)致只有部分參與者收到了commit請求，就會(huì)造成部分參與者提交了事務(wù)而其他參與者未提交的情況。
3PC
1.基于2PC,在預(yù)備之前,加入詢問階段,用于判斷網(wǎng)絡(luò)是否通暢(詢問不鎖定資源)
2.增加超時(shí)機(jī)制(TM/RM都有):
(TM超時(shí)默認(rèn)失敗)
(第三階段)RM超時(shí)默認(rèn)提交
3PC也不能完全保證一致性,只是降低了數(shù)據(jù)不一致的概率.降低了資源鎖定概率
解決方案
- 本地事件表+mq方案
image.png
lock 鎖定事務(wù)單元
confirm 確認(rèn)事務(wù)單元
notify 通知事務(wù)單元
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，為用戶打造一站式的分布式解決方案
- TCC
- 原理介紹:
TCC事務(wù)機(jī)制相對于傳統(tǒng)事務(wù)機(jī)制（X/Open XA Two-Phase-Commit），其特征在于它不依賴資源管理器(RM)對XA的支持，而是通過對（由業(yè)務(wù)系統(tǒng)提供的）業(yè)務(wù)邏輯的調(diào)度來實(shí)現(xiàn)分布式事務(wù)。主要由三步操作，Try: 嘗試執(zhí)行業(yè)務(wù)、Confirm:確認(rèn)執(zhí)行業(yè)務(wù)、Cancel: 取消執(zhí)行業(yè)務(wù)- 模式特點(diǎn):
該模式對代碼的嵌入性高，要求每個(gè)業(yè)務(wù)需要寫三種步驟的操作。
該模式對有無本地事務(wù)控制都可以支持使用面廣。
數(shù)據(jù)一致性控制幾乎完全由開發(fā)者控制，對業(yè)務(wù)開發(fā)難度要求高。- 不適用于全數(shù)據(jù)庫,純手工流程過于復(fù)雜,用于redis月mysql同步事務(wù)還可.數(shù)據(jù)庫LCN更加合適
private static Map<String,Integer> maps = new HashMap<>();
@Transactional(rollbackFor = Exception.class)
@TccTransaction
public String tryX(@RequestBody XBean bean){
//數(shù)據(jù)庫操作
//do SQL
//maps中記錄唯一標(biāo)識(shí)id
maps.put("a",id);
return "try成功";
}
public String confirmX(XBean bean){
System.out.println("pay confirm");
return "confirm成功";
}
public String cancelX(XBean bean){
//從map獲取id,供取消使用
Integer a = maps.get("a");
//do SQL 取消tryX()方法操作
return "取消支付成功";
}
- 可靠性消息最終一致性
image.png
- 最大努力通知
一般適用于三方服務(wù),例如支付寶/微信的支付回調(diào),如果消費(fèi)方不應(yīng)答,由高到底降低頻率通知固定次數(shù)后將不在通知,提供查詢接口供消費(fèi)方調(diào)用
- 事務(wù)消息
image.png
