COMMIT和数据一致性

标签: commit 数据 一致性 | 发表时间:2014-05-10 22:36 | 作者:sanmao6139
出处:http://www.iteye.com

[align=justify; direction: ltr; unicode-bidi: embed; vertical-align: baseline;]2.在执行一条update语句后一直未提交,数据会写到数据文件中吗?

一致性查询及一致性读原理

Select * from test where object_id = 2;
如果8点钟可以查询出两条记录,假设一下,如果此查询很慢,从8点开
始查,9点才能结束。在此期间不巧被删了一条数据,请问最终返回的结果是一条数据还是两条数据?

原理:
两个前提:
•1. 了解数据库的SCN(System change Number),是数据库内部的时钟,可以与时间相互转换,是一个只会增加不会减少的数字,存在于Oracle的最小单位块里,当某块改变时SCN就会递增。
•2. 数据库的回滚记录事务槽,如果你更新了某块,事务就被写进事务槽里。如果未提交或回滚,改块就存在活动事务,数据库读到此块可以识别到这种情况的存在。



 


 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [commit 数据 一致性] 推荐:

COMMIT和数据一致性

- - Oracle - 数据库 - ITeye博客
[align=justify; direction: ltr; unicode-bidi: embed; vertical-align: baseline;]2.在执行一条update语句后一直未提交,数据会写到数据文件中吗. 一致性查询及一致性读原理. 如果8点钟可以查询出两条记录,假设一下,如果此查询很慢,从8点开.

科普:Git Commit Guidelines

- - IT瘾-dev
降低Review成本,可以明确知道本次提交的改变和影响. 规范整个Team的提交习惯,对技术素养的养成有益. 可以通过统一工具,抽取规范的message自动形成change log. 目前Github的Angular项目,就是完全采用规范的Git Message来进行日常的提交管理和发布管理的,下面是这个项目的Commit记录,和自动根据commit生成的change log.

大数据的一致性

- - 阳振坤的博客
看到了一篇关于数据一致性的文章:下一代NoSQL:最终一致性的末日. (  http://www.csdn.net/article/2013-11-07/2817420 ),其中说到: 相比关系型数据库,NoSQL解决方案提供了shared-nothing、容错和可扩展的分布式架构等特性,同时也放弃了关系型数据库的强数据一致性和隔离性,美其名曰:“最终一致性”.

数据一致性的一些思考

- - 掘金 架构
没有银弹,需要根据自己的业务场景做取舍. 业务量有多少,需要主从读写分离么,需要分库分表么. 是需要多表合并,还是多行合并,还是多库合并. 该如何容灾?更新、删除缓存失败你能不能接受. 如果删除缓存失败,你还允不允许更新数据库. 要根据实际业务场景来定制方案. 大部分业务场景都是读多写少,而且数据库(mysql)写很少看到写挂的,都是读有瓶颈.

量化InnoDB group commit的效果

- - OurMySQL
前几天有位开发的同学问了个问题,InnoDB的group commit效果如何. 之前说好了回头给看下,结果险些拖过年. Group commit 背景.         InnoDB的redo log的group commit历史比较悠久了(有别于binlog的group commit). 如果设置为1,每次事务提交都至少需要写一次redolog.

数据库与缓存数据一致性解决方案

- - 掘金 后端
在分布式并发系统中,数据库与缓存数据一致性是一项富有挑战性的技术难点. 本文将讨论数据库与缓存数据一致性问题,并提供通用的解决方案. 假设有完善的工业级分布式事务解决方案,那么数据库与缓存数据一致性便迎刃而解,实际上,目前分布式事务不成熟. 在数据库与缓存数据一致解决方式中,有各种声音. 先操作数据库后缓存还是先缓存后数据库.

关于分布式系统的数据一致性问题

- - 互联网 - ITeye博客
现在先抛出问题,假设有一个主数据中心在北京M,然后有成都A,上海B两个地方数据中心,现在的问题是,假设成都上海各自的数据中心有记录变更,需要先同步到主数据中心,主数据中心更新完成之后,在把最新的数据分发到上海,成都的地方数据中心A,地方数据中心更新数据,保持和主数据中心一致性(数据库结构完全一致).

分布式系统数据一致性的6种方案(转)

- - 企业架构 - ITeye博客
编者按:本文由「高可用架构后花园」群讨论整理而成,后花园是一个面向架构师的增值服务,如需了解,请关注「高可用架构」后回复 VIP.                                                                                 问题的起源.

微服务下的数据一致性思考

- -
之前讲到了数据库层和缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案. 既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题.

如何保证缓存与数据库的双写一致性?

- -
如何保证缓存与数据库的双写一致性. 你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题. 一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去.