第1个回答 2022-11-14
问题一：数据库：事务的一致性是什么意思呢？ 举例说明如下：
银行A账户向B账户汇款100元，数据库执行如下过程
从A账户减少100元，然后在B账户增加100元，这个过程称为一个事务
但是：
如果从A账户减少100元后系统出故障了或者出现了其他意外造成B账户没有增加100元（这种事情相信无论是谁遇到也会很无语吧？好吧言归正传）这种情况称为事务不一致，因为一个事务没有做完，所以数据库会将整个过程回滚，你可以理解为就当什么事也没发生过，这种回滚机制就是事务的一种特征，目的就是为了保持数据库的数据库的事务一致性。
我想我应该说明白了吧
问题二：如何理解数据库事务中的一致性的概念 定义：数据库一致性（Database Consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
数据库状态如何变化？每一次数据变更就会导致数据库的状态迁移。如果数据库的初始状态是C0，第一次事务T1的提交就会导致系统生成一个SYSTEM CHANGE NUMBER（SCN），这是数据库状态从C0转变成C1。执行第二个事务T2的时候数据库状态从T1变成T2，以此类推，执行第Tn次事务的时候数据库状态由C(n-1)变成Cn。
定义一致性主要有2个方面，一致读和一致写。
一致写：事务执行的数据变更只能基于上一个一致的状态，且只能体现在一个状态中。T(n)的变更结果只能基于C(n-1)，C(n-2), ...C(1)状态，且只能体现在C(n)状态中。也就是说，一个状态只能有一个事务变更数据，不允许有2个或者2个以上事务在一个状态中变更数据。至于具体一致写基于哪个状态，需要判断T(n)事务是否和T(n-1)，T(n-2),...T(1)有依赖关系。
一致读：事务读取数据只能从一个状态中读取，不能从2个或者2个以上状态读取。也就是T(n)只能从C(n-1），C(n-2)... C(1)中的一个状态读取数据，不能一部分数据读取自C(n-1)，而另一部分数据读取自C(n-2)。
摆事实
一致写：
定义100个事务T(1)...T(100)实现相同的逻辑 update table set i=i+1，i的初始值是0，那么并发执行这100个事务之后i的值是多少？可能很容易想到是100。那么怎么从一致性角度去理解呢？
数据库随机调度到T(50)执行，此时数据库状态是C(0)，而其它事务都和T(50)有依赖关系，根据写一致性原理，其它事务必须等到T(50)执行完毕后数据库状态变为C(1)才可以执行。因此数据库利用锁机制阻塞其它事务的执行。直到T(50)执行完毕，数据库状态从C(0)迁移到C(1)。数据库唤醒其它事务后随机调度到T(89)执行，以此类推直到所有事务调度执行完毕，数据库状态最终变为C(100)。
一致读：
还是上面的例子，假设T(1)...T(100)顺序执行，在不同的时机执行select i from table，我们看到i的值是什么？
1. T(1)的执行过程中。数据库状态尚未迁移，读到的i=0
2. T(1)执行完毕，T(2)的执行过程中，数据库状态迁移至C(1)，读到的i=1
问题三：数据库事务的一致性是什么意思？ 一个查询select 开始头 可能要查很长时间， 不管他查多久 如果返回结果 那么结果为 查询开始时间的结果，不会有一半结果是 查询开始时的 一半是查询过程中的，因为整个过程中可能发生很多事务 很多 数据变化。
问题四：mysql下的事务一致性怎么解释？ 你好：说白了就是要不都提交成功，要不就都直接回滚。一般都是遇到exception；
如果事物提交后，那么只能回滚未提交的。
问题五：如何理解数据库事务中的一致性的概念 数据库一致性（Database Consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
问题六：java中怎么控制事务的一致性 不用控制.事务全部成功就一起提交,有一个失败就回滚.这样就保证事务一致性了.
问题七：数据库事务里的原子性和一致性的区别 5分 原子性， 一个事务 要么完全提交 要么完全回滚，不会介于2者之间。
一致性，一个查询发起后，不管数据发生了多少变化 多少事务，查询结果应当为发起查询时间一致的数据
问题八：如何保证事务的一致性 不用控制.事务全部成功就一起提交,有一个失败就回滚.这样就保证事务一致性了.
问题九：如何解决分布式系统数据事务一致性问题 用户在京东上下了一个订单，发现自己在京东的账户里面有余额，然后使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。假设订单系统，支付系统，仓库系统是三个独立的应用，是独立部署的，系统之间通过远程服务调用。
订单的有三个状态：I:初始 P:已支付 W:已出库，订单金额100, 会员帐户余额200
如果整个流程比较顺利，正常情况下，订单的状态会变为I->P->W，会员帐户余额100，订单出库。
但是如果流程不顺利了？考虑以下几种情况
1：订单系统调用支付系统支付订单，支付成功，但是返回给订单系统数据超时，订单还是I（初始状态），但是此时会员帐户余额100,会员肯定会马上找京东骂京东，为啥不给老子发货，我都付钱了
2：订单系统调用支付系统成功，状态也已经更新成功，但是通知仓库发货失败，这个时候订单是P（已支付）状态，此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。
3：订单系统调用支付系统成功，状态也已经更新成功，然后通知仓库发货，仓库告诉订单系统，没有货了。这个时候数据状态和第二种情况一样。
对于问题一，我们来分析一下解决方案，能想到的解决方案如下
1 假设调用支付系统支付订单的时候先不扣钱，订单状态更新完成之后，在通知支付系统你扣钱
如果采用这种设计方案，那么在同一时刻，这个用户，又支付了另外一笔订单，订单价格200，顺利完成了整个订单支付流程，由于当前订单的状态已经变成了支付成功，但是实际用户已经没有钱支付了，这笔订单的状态就不一致了。即使用户在同一个时刻没有进行另外的订单支付行为，通知支付系统扣钱这个动作也有可能完不成，因为也有可能失败，反而增加了系统的复杂性。
2 订单系统自动发起重试，多重试几次，例如三次，直到扣款成功为止。
这个看起来也是不错的考虑，但是和解决方案一样，解决不了问题，还会带来新的问题，假设订单系统第一次调用支付系统成功，但是没有办法收到应答，订单系统又发起调用，完了，重复支付，一次订单支付了200。
假设支付系统正在发布，你重试多少次都一样，都会失败。这个时候用户在等待，你怎么处理？
3 在第二种方案的基础上，我们先解决订单的重复支付行为，我们需要在支付系统上对订单号进行控制，一笔订单如果已经支付成功，不能在进行支付。返回重复支付标识。那么订单系统根据返回的标识，更新订单状态。
接下来解决重试问题，我们假设应用上重试三次，如果三次都失败，先返回给用户提示支付结果未知。假设这个时候用户重新发起支付，订单系统调用支付系统，发现订单已经支付，那么继续下面的流程。如果会员没有发起支付，系统定时（一分钟一次）去核对订单状态，如果发现已经被支付，则继续后续的流程。
这种方案，用户体验非常差，告诉用户支付结果未知，用户一定会骂你，你丫咋回事情，我明明支付了，你告诉我未知。假设告诉用户支付失败，万一实际是成功的咋办。你告诉用户支付成功，万一支付失败咋办。
4 第三种方案能够解决订单和支付数据的一致性问题，但是用户体验非常差。当然这种情况比较可能是少数，可以牺牲这一部分的用户体验，我们还有没有更好的解决方案，既能照顾用户体验，又能够保证资金的安全性。
我们再回来看看第一种方案，我们先不扣钱，但是有木有办法让这一部分钱不让用户使用，对了，我们先把这一部分钱冻结起来，订单系统先调用支付系统成功的时候，支付系统先不扣钱，而是先把钱冻结起来，不让用户给其他......>>