前言:
此刻同学们对“java显示数据库数据”大约比较注重,我们都需要了解一些“java显示数据库数据”的相关资讯。那么小编也在网络上汇集了一些有关“java显示数据库数据””的相关资讯,希望朋友们能喜欢,看官们一起来学习一下吧!基本概念:
数据一致性定义 是任务人、任何时间、任何地点、任何接入方式、任何服务数据都是一致性的;数据不一致产生原因一般都有几点,例如数据分散在多处(多个DB,或者是DB和缓存),再来看一个 二手交易平台案例,它有用户、商品、交易等功能,如下图所示,所以如果控制不好往往会出现数据不一致的现象
一、案例驱动
1、电商平台购买商品过程 下单->减库存->支付
一个请求分布在多个数据库上面,此时本地事务已经不奏效,要用分布式事务去解决
二、分布式事务场景
1、电商下单场景
① 下单
② 发送消息到MQ
2、一致性保证
① 本地事务
(1)下单操作;
(2)发送MQ消息操作;
(3)放进一个本地事务;
三、分布式事务分类
1、刚性分布式事务有 强一致性、 XA模型、 CAP中的CP
① 满足传统事务特性
(1)ACID(Atomicity-原子性、Consistency-一致性、Isolation-隔离性、Durability-持久性)
XA模型
(1)XA是X/Open CAE Specification(Distributed Transaction Processing)模型中定义,XA规范由AP、RM、TM组成;
(2)其中应用程序(Application Program 简称AP);AP定义事务边界(定义事务开始和结束)并访问事务边界内的资源;
(3)资源管理器(Resource Manager 简称RM);RM管理计算机共享的资源,资源即数据库等;
(4)事务管理器(Transaction Manager 简称TM);负责管理全局事务,分配事务唯一标识,监控事务的执行进度,并负责事务的提交、回滚、失败恢复等;
② 两阶段提交
(1)过程
* 两阶段提交是XA规范标准的实现;
* TM发起prepare投票;
* RM都同意后,TM再发起commit;
* commit过程出现宕机等异常,节点服务重启后,根据XA recover再次进行commit补偿;
(2)缺点
* 同步阻塞模型;
* 数据库资源锁定时间过长;
* 全局锁(隔离级别串行化),并发低;
* 不适合长事务场景
2、柔性分布式事务
① CAP
分布式环境下P一定需要,CA权衡折中,柔性事务中会选择A
② BASE理论
* Basically Available -基本可用
* Soft state -柔性状态
* Eventual consistency -最终一致性
③ 架构考虑
* 柔性事务是对XA协议的妥协,它通过降低强一致性要求,从而降低数据库资源锁定时间,提升可用性;
④ 典型架构实现
TCC模型
(1)Try-Confirm-Cancel
(2)TCC模型完全交由业务实现,每个子业务都需要实现Try-Confirm-Cancel接口,对业务侵入大,它最大的特点就是资源的锁定交由业务方;
(3)Try:尝试执行业务,完成所有业务检查,预留必要的业务资源;
(4)Confirm:真正执行业务,不再做业务检查;
(5)Cancel:释放Try阶段预留的业务资源;
(6)汇款服务、收款服务案例:A用户向B用户汇款500元;
汇款服务
* Try:
a 检查A账号有效性,即查看A账号的状态释放为“转账中”或“冻结”;
b 检查A账号余额是否充足;
c 从A账号中扣减500元,并将状态置为“转账中”;
d 预留扣减资源,将从A往B账号转账500元这个事件存入消息或日志中;
* Confirm:
a 不做任何操作,因为在这个案例中这个动作在Try中的c已经做了
* Cancel:
a A 账号增加500元
b 从日志或者消息中,释放扣减资源
收款服务
* try:
a 检查B账号是否有效;
* Confirm:
a 读取日志或者消息,B账号增加500元;
b 从日志或者消息中,释放扣减资源;
* Cancel:
a 不做任务操作
Saga模型
(1)起源于1987年Hector&Kenneth发表的论文Sagas;
(2)Saga模型把一个分布式事务拆分为多个本地事务,每个本地事务都有相应的执行模块和补偿模块(对于TCC中的Confirm和Cancel);
(3)当Saga事务中任意一个本地事务出错时,可以通过调用相关的补偿方法恢复之前的事务,达到事务最终一致性;
(4)当每个Saga子事务T1,T2,...,Tn 都有对应的补偿定义C1,C2,...,Cn-1,那么Saga系统可以保证
* 子事务序列T1,T2,...,Tn得以完成(最佳情况)
* 或者序列T1,T2,...,Tj,Cj-1,...,C2,C1, 0<j<n,得以完成;
(5)Saga隔离性
* 业务层控制并发,在应用层加锁,应用层预先冻结资源等;
(6)Saga恢复方式
* 向后恢复:补偿所有已完成的事务,如果任一子事务失败;
* 向前恢复:重试失败的事务,假设每个子事务最终都会成功;
四、分布式事务对比(刚性分布式事务VS柔性分布式事务)
(1)柔性分布式事务通用处理思路
* 本地事务->短事务
* 分布式事务->长事务
* 转变成多个短事务
* 案例:A【下单】->B【减库存】->C【支付】
A ->DB1;B->DB2;C->DB3;A/B/C都成功;A/B成功,C失败就进行补偿;
(2)柔性分布式事务 业务场景
① 异步场景:基于MQ消息驱动分布式事务;
方案一:业务方提供本地操作成功回查功能
* 事务消息:MQ提供类似X/Open XA的分布式事务功能,通过MQ事务消息能达到分布式事务最终一致;
* 半消息:暂不能投递的消息,发送方已经将消息成功发到了MQ服务端,但是服务端未收到生产者对该消息的二次确认,此时该消息被标记成“暂不能投递”状态,处于该种状态下的消息即为半消息;
* 消息回查:由于网络闪断、生产者应用重启等原因,导致某条事务消息的二次确认丢失,MQ服务端通过扫描发现某条消息长期处于“半消息”时,需要主动向消息生产者询问该消息的最终状态(Commit或是Rollback),即消息回查;
MQ分布式事务设计方案
* MQ事务消息设计事务消息作为一种异步确保性事务,将两个事务分支通过MQ进行异步解耦,MQ事务消息的设计流程同样借鉴了两阶段提交理论,整体交互流程如下图所示:
1.事务发起方首先发送prepare消息到MQ;
2.在发送prepare消息成功后执行本地事务;
3.根据本地事务执行结果返回commit或者是rollback;
4.如果消息是rollback,MQ将删除该prepare消息不进行下发,如果是commit消息,MQ会将消息发送给consumer端;
5.如果执行本地事务过程中,执行端挂掉或者超时,MQ服务器端将不停的询问producer来获取事务状态;
6.Consumer端的消费成功机制有MQ保证;
方案一总结:
优点:通用,
缺点:
1、业务方需提供回查接口,对业务侵入大;
2、发送消息非幂等;
3、消费端需要处理幂等;
4、MQ服务端需要提供半消息功能,需要定时对半消息进行遍历的功能;
方案二:本地事务消息表
* 本地操作和发送消息通过本地事务强一致性
a 本地事务操作表
b 本地事务消息表 mqMessages(msgid,content,topic,status)
方案二:本地事务消息表总结
(1)发送端消息不幂等,最少发发送一次;
(2)消费端处理消息幂等(利用分布式锁)
(3)A->B->C
A/B成功,C失败
* 记录错误日志;
* 报警;
* 人工介入;
(4)优点:业务侵入小
② 同步场景:基于异步补偿分布;
架构设计的三大关键
总体架构设计
业务逻辑层Proxy设计(基于AOP实现)
1、逻辑层调用上加上事务注解@Around("execution(**(..))&&@annotation(TX)")
2、Proxy在真正业务逻辑被调用之前,生成一个全局唯一TXID标识事务组,TXID保存在ThreadLocal变量里,方法开始前写入,完成后清除,并向远端数据库写入TXID并把事务组置为开始状态;
3、业务逻辑层调用数据访问层之前,通过PRCProx代理记录当前调用请求参数;
4、如果业务正常,调用完成后,当前方法的调用记录存档或删除;
5、如果业务异常,查询调用链反向补偿;
数据访问层设计
1、原子接口
2、补偿接口
① 业务方来提供
② 幂等性保证
3、基于原则接口方法,在方法名上加注解标注补偿方名@Compensable(cancelMethod="cancelRecord")
分布式事务补偿服务
1、事务组表(数据库表TDB)
① 记录事务组状态;
② txid、state、timestamp
2、事务调用组表(数据库表TDB)
① 记录事务组内的每一次调用以及相关参数;
② txid、actionid(操作步骤)、callmethod、pramatype、params
3、补偿策略
① 调用执行失败、修改事务组状态;
② 分布式事务补偿服务异步执行补偿;
例如向上面的一个下单的操作:A【下单】->B【减库存】->C【支付】,当进行这一操作的时候会在事务组表里面新增一条记录
state: 1:代表下单触发业务;2:代表成功下单支付完成;3:代表失败;4:代表补偿成功;5:代表补偿失败;
在事务调用组表里有相应三条记录
所以对应它的一次下单操作,它有相应的三个本地事务的执行逻辑,actionid标识着这个下单操作内部的逻辑顺序,当整个下单操作成功时,会将事务组表里面的state更新为2成功,如果失败更新为3然后由分布式事务补偿服务按照事务调用组表里面的该事务001对应的顺序进行执行回滚补偿方法,回滚成功则将事务组表里面的state更新为4,回滚失败更新为5,这个时候就要介入人工操作了;
成功案例
失败案例
如果分布式事务本身补偿失败,则进行
1、记录错误日志;2、报警;3、人工介入
标签: #java显示数据库数据