琪琪色原网站,琪琪色影院,琪琪色原网站影音先锋_是全亚洲更新最快

BeetlSQL 3.1.0 发布,Spring Saga 事务支持

2020年11月17日

本次发布增强了Saga在spring下的支持,使用kafka提供重试以及重试失败后放入丢弃队列里

Saga是用来在微服务中的长事务管理,具备ACID中的ACD,不具备I,隔离性。在一定业务条件下,可以使用Saga非常简单和方便的管理微服务事务。同理,也可以用于管理多库事务

Saga要求微服务提供回滚操作,然后如果需要回滚,有Saga编排调度各个微服务对应的回滚服务。BeetlSQL提供了SagaMapper,内置的操作都有对应的回滚操作,也提供@SagaSql,用户提供正向SQl,也提供回滚SQL。这样,在多库环境下,BeetlSQL能正确回滚数据而不依赖于数据库提供的事务

maven

<dependency>
  <groupId>com.ibeetl</groupId>
  <artifactId>beetlsql</artifactId>
  <version>3.1.0-RELEASE</version>
</dependency>
<dependency>
  <groupId>com.ibeetl</groupId>
  <artifactId>sql-saga-springkafa</artifactId>
  <version>3.1.0-RELEASE</version>
</dependency>
@Transactional(propagation = Propagation.NEVER)
public boolean normal(){
	SagaContext sagaContext = SagaContext.sagaContextFactory.current();
	try{
		UserInfoInDs1 ds1 = new UserInfoInDs1();
		ds1.setId(100);
		ds1.setName("ces");

		UserInfoInDs2 ds2 = new UserInfoInDs2();
		ds2.setId(100);
		ds2.setName("abs");
		//俩个数据库
		userInfoDs1Mapper.insert(ds1);
		userInfoDs2Mapper.insert(ds2);
		//模拟一个错误
		int a = 1/0;
	}catch(Exception ex){
		sagaContext.rollback();
		return false;
	}
	return true;
}

需要配置重试队列和丢弃队列名字,以及重试次数,以及kafka序列化方式

beetlsql-saga.kafka.retry-topic=retryTopic002
beetlsql-saga.kafka.fail-topic=failTopic002


spring.kafka.bootstrapServers=127.0.0.1:9092
spring.kafka.consumer.group-id=saga
spring.kafka.consumer.auto-offset-reset=latest
spring.kafka.listener.type=single
spring.kafka.listener.ack-mode=record

spring.kafka.consumer.value-deserializer=org.beetl.sql.saga.kafka.JacksonDeserializer
spring.kafka.producer.value-serializer=org.beetl.sql.saga.kafka.JacksonSerializer
展开阅读全文
6 收藏
分享
加载中
精彩评论
作者还是一贯有些随意,第二个依赖的坐标kafka写成了kafa。
2020-11-18 07:29
1
举报
支持一个,从方案到实现做的真快
2020-11-17 15:02
1
举报
最新评论 (12)
作者还是一贯有些随意,第二个依赖的坐标kafka写成了kafa。
2020-11-18 07:29
1
回复
举报
了解我.... 我下次版本改一下
2020-11-18 11:37
0
回复
举报
哈哈,跟大赋老相识了,还是了解的,没有贬义,就是觉得我们可以做到更严谨一点,包括代码的空格,空行什么的,单词拼写。
2020-11-18 11:44
0
回复
举报
现在的版本使用mapper的insert(),有没有什么办法返回主键?
2020-11-17 21:21
0
回复
举报
主键自动包含在对象里了
2020-11-18 11:38
0
回复
举报
单元测试代码:

2020-11-17 15:45
0
回复
举报
支持一个,从方案到实现做的真快
2020-11-17 15:02
1
回复
举报
看看有啥漏洞没?
2020-11-17 15:42
0
回复
举报
心有余而力不足啊,最近在做项目,等以后有时间再来跑跑看。不过两个关键点如果你都注意到就应该问题不大,一个是事务重入问题,在分布式事务进行或回滚期间,必须有个柔性锁标记告知其它事务不要覆盖当前事务中的数据。一个是网线在任意时候断掉都不影响最终数据一致性,这个包括手工恢复。当然硬件损坏这种不算。
2020-11-17 16:10
0
回复
举报
必须有个柔性锁标记告知其它事务不要覆盖当前事务中的数据,这个咋搞?那岂不是阻止其他正常业务执行了?
2020-11-17 17:08
0
回复
举报
seata是这样做的,在提交过程中记录每个SQL访问了哪些表格的哪些记录,然后以这个记录作为锁, 下一次事务提交之前,也要记录每个SQL访问了哪些表格的哪些记录,并和现有的锁对比,如果有重复记录说明事务重入了,就不提交第二个事务,这样可以保证隔离性,这是个业务无侵入的方案。我的方案和seata类似,但只支持实体CRUD,不支持SQl,靠ORM工具来生成每个实体ID的锁记录。你用saga方案,可以在事务一头一尾检查和设立一个业务相关的标记,比方说最外层锁定订单,最里层的事务提交时解锁标记,或回滚到最外层事务时解锁标记,这样可以保证事务不重入。
以上三种方式都是柔性事务,不保证第三方工具无视锁记录直接修改数据库这种情况,但这种情况一般不会出现,除非编程出错。
2020-11-18 00:19
0
回复
举报
嗯,我个人倾向”事务一头一尾检查和设立一个业务相关的标记“,我看微服务模式里里的saga也提到了这种方式,这需要开发人员更多的考虑
2020-11-18 11:40
0
回复
举报
更多评论
12 评论
6 收藏
分享
返回顶部
顶部