你才不是只會理論的女同學-seata實踐篇
- 2021 年 4 月 6 日
- 筆記
本文主要內容為seata的實踐篇,理論知識不懂的請參考前文:
主要介紹兩種最常用的TCC和AT模式。
環境資訊:
mysql:5.7.32
seata-server:1.4.1
SpringCloud:Hoxton.SR10
SpringBoot:2.3.8.RELEASE
註冊中心:Eureka
涉及服務:
Seata-server
1、在file.conf中修改
mode = “db”
然後配置DB資訊:
## database store property
db {
datasource = "druid"
## mysql/oracle/postgresql/h2/oceanbase etc.
dbType = "mysql"
driverClassName = "com.mysql.jdbc.Driver"
url = "jdbc:mysql://127.0.0.1:3306/seata"
user = "root"
password = "123456"
minConn = 5
maxConn = 100
globalTable = "global_table"
branchTable = "branch_table"
lockTable = "lock_table"
queryLimit = 100
maxWait = 5000
}
2、在register.conf
registry {
# file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
type = "eureka"
loadBalance = "RandomLoadBalance"
loadBalanceVirtualNodes = 10
eureka {
serviceUrl = "//eureka-chengdu:8761/eureka,//eureka-hangzhou:8762/eureka"
application = "seata-server"
weight = "1"
}
3、客戶端修改
這裡所指的客戶端包含所有的資源管理器,包含所有需要seata-server管理的服務
在服務啟動yml中增加:
seata:
enabled: true
# 事務群組(可以每個應用獨立取名,也可以使用相同的名字)
tx-service-group: my_tx_group
client:
rm-report-success-enable: true
# 非同步提交快取隊列長度(默認10000)
rm-async-commit-buffer-limit: 1000
# 一階段全局提交結果上報TC重試次數(默認1次,建議大於1)
tm-commit-retry-count: 3
# 一階段全局回滾結果上報TC重試次數(默認1次,建議大於1)
tm-rollback-retry-count: 3
support:
# 數據源自動代理開關(默認false關閉)
spring-datasource-autoproxy: false
service:
vgroup-mapping:
# TC 集群(必須與seata-server保持一致)
my_tx_group: seata-server
grouplist:
default: seata-server:8091
registry:
type: eureka
eureka:
serviceUrl: //eureka-chengdu:8761/eureka/,//eureka-hangzhou:8762/eureka/
TCC模式
TCC模式實踐需要四個服務,除了seata-server外,其他服務調用關係如下:
business服務是全局事務的發起者,需要增加@GlobalTransactional註解
@Override
@GlobalTransactional
public String processTcc(Map<String, String> params) {
String xid = RootContext.getXID();
System.out.println(("---》》》》xid:" + xid));
uploadFeign.upload(params);
downloadFeign.download(params);
return xid;
}
business服務會通過feign遠程調用upload和download服務,這兩個服務都要聲明TCC的三個介面,並通過TwoPhaseBusinessAction註解聲明。
upload服務:
@LocalTCC
public interface TccService {
@TwoPhaseBusinessAction(name = "upload", commitMethod = "commitTcc", rollbackMethod = "cancel")
String upload(@BusinessActionContextParameter(paramName = "params") Map<String, String> params);
boolean commitTcc(BusinessActionContext context);
boolean cancel(BusinessActionContext context);
}
具體實現,這裡模擬了TCC結果並放到Result中,通過restful介面可以查看,實際業務需要考慮防懸掛和空回滾問題,例子只是簡單描述如何使用TCC模式:
@Slf4j
@Service
public class TccServiceImpl implements TccService {
@Value("${spring.application.name}")
private String appName;
@PostConstruct
private void initAppName() {
Result.getResult().setAppName(appName);
}
@Override
public String upload(Map<String, String> params) {
String xid = RootContext.getXID();
System.out.println(("---》》》》xid: " + xid));
return "success";
}
@Override
public boolean commitTcc(BusinessActionContext context) {
String xbid = context.getXid();
System.out.println(("---》》》》xid: " + xbid + "提交成功"));
Result.getResult().setActionResult(context.getXid(), +context.getBranchId(), "Commit", context.getActionContext("params"));
return true;
}
@Override
public boolean cancel(BusinessActionContext context) {
System.out.println(("---》》》》xid: " + context.getXid() + "回滾成功"));
Result.getResult().setActionResult(context.getXid(), context.getBranchId(), "Rollback", context.getActionContext("params"));
return true;
}
}
download服務
download服務也同樣需要聲明一個TCC介面,實現上在Try階段模擬每三次調用,,延遲30s失敗一次場景
@Override
public String download(Map<String, String> params) {
String xid = RootContext.getXID();
System.out.println(("---》》》》xid: " + xid));
if (count.incrementAndGet() % 3 == 0) {
try {
TimeUnit.SECONDS.sleep(30);
} catch (InterruptedException e) {
log.warn("InterruptedException", e);
}
throw new RuntimeException("服務異常");
}
return "success";
}
測試
1、通過restful介面調用兩次,返回全局事務ID
2、查看download和upload服務結果,可以看到結果都是成功。
upload結果:
3、通過日誌查看
seata-server:
business服務日誌:
第三次調用
第三次模擬的是download服務失敗場景,所以能看到download結果是失敗回滾
但是upload服務並沒有異常,來看下是否能夠和download保證事務的一致性,結果都是回滾呢?
從結果看到兩個服務結果是相同的,從而也看出保證了事務一致性。
從seata-server日誌也能看到回滾成功的資訊:
AT模式
AT模式實踐需要四個服務,除了seata-server外,其他服務調用關係如下:
模擬電商場景,下訂單、減庫存,處理成功後,第三次調用時延時30s拋出異常
業務觸發測,也就是全局事務發起服務business服務:
@Override
@GlobalTransactional(rollbackFor = Exception.class)
public String processAt(String userId, int orderMoney, String commodityCode, int count) throws InterruptedException {
String xid = RootContext.getXID();
System.out.println("---》》》》xid:" + xid);
System.out.println(("------->創建訂單開始"));
orderFeign.create(userId, commodityCode, count, orderMoney);
System.out.println(("------->創建訂單結束"));
System.out.println(("------->扣減庫存開始"));
storageFeign.deduct(commodityCode, count);
System.out.println(("------->扣減庫存結束"));
if (visitCount.incrementAndGet() % 3 == 0) {
TimeUnit.SECONDS.sleep(30);
throw new RuntimeException("process failed");
}
return xid;
}
order服務、storage服務
除了配置中增加seata外,與普通的入庫服務是一樣的
@Service
public class OrderDao {
@Autowired
private JdbcTemplate jdbcTemplate;
public boolean createOrder(Order order) {
String sql = "INSERT INTO product_order (user_id,product_id,count,money,status) VALUES('" + order.getUserId() + "', " + order.getProductId() + "," + order.getCount() + ", " + order.getMoney() + ",0);";
return jdbcTemplate.update(sql) > 0;
}
}
調用之前:數據:
order資料庫為空,
storage資料庫中庫存欄位為100:
調用兩次後:
資料庫結果:
第三次調用是模擬延時30s後失敗場景,也就是書庫更新後,處理數據失敗,應該從資料庫看到數據回滾過程,延遲30s也是為了更好的觀察結果,也可以用debug方式觀察結果
也可以看到
rollback_info中:
30s後重新查詢書庫可以看到storage庫存變回98,order記錄減少為2條,同時undo_log和seata相關表中數據被清空。
從seata-server日誌也能看到回滾資訊。
華為
同時看下華為的分散式事務解決方案,相比於seata直觀的就是多了交互命令行,從上面例子也可以看出seata目前還只能通過資料庫查看結果
其他和seata類似提供了TCC和非侵入兩種方案
seata-golang
參考容器時代:seata-golang 接入指南
總結
例子中涉及的程式碼已上傳到github
//github.com/stevenniu9527/nerry
如果有時間還是建議自己敲一遍程式碼,看別人的東西都會覺得很簡單,一看就會
但是當自己實操時就會發現各種奇奇怪怪的異常,一用就廢。
紙上得來終覺淺,絕知此事要躬行,
比如例子中子pom依賴為什麼不需要配置版本、eureka兩個怎麼互為副本的、seata相關表中具體數據是什麼、debug和延遲30s是否會對seata有影響
這些問題自己敲一遍會有更深的理解,更何況程式碼量是如此的少。
最後覺得寫的還行,求關注,求點贊,求轉發