精华内容
下载资源
问答
  • 1数据库事务概念简单回忆事务的四点就是ACID事务的几个特性就是表明要构成事务必须具备这些特性原子性(Atomicity)指的事务一个不可分割的执行单位,事务的执行,要么全部成功,要么全部失败;一致性(Consistency)...

    1

    数据库事务概念简单回忆

    事务的四点就是ACID

    事务的几个特性就是表明要构成事务必须具备这些特性

    原子性(Atomicity)

    指的是事务是一个不可分割的执行单位,事务的执行,要么全部成功,要么全部失败;

    一致性(Consistency)

    事务前后的数据完整性必须一致;

    隔离性(Isolation)

    事务的隔离性指的是多个用户并发访问数据库的时候,数据库为每一个用户开启的事务,不能被其他的事务操作数据所干扰,多个并发事务之间要相互隔离;

    持久性(Durability)

    持久性指的是一个事务一旦被提交之后,它对数据库的改变就是永久性的,接下来即使发生故障也不应该对其有任何影响;

    2

    MySQL的InnoDB是怎么实现ACID的

    在说InnoDB实现事务之前有必要提一提几个概念

    MySQL对于SQL的操作,往往是先建立在一个内存区域的,也就是Buffer Pool,为什么需要这个Buffer Pool呢?

    如果说每次执行一条SQL,无论是增删改查,数据库都会优先从内存当中先看看有没有数据,如果没有数据,就访问数据磁盘,就行IO读取到内存当中,而这个访问数据磁盘的时候,并不是说每次只读一次就放到这个Buffer Pool;

    每一次从db file当中读取数据,其实采用了页(page)的概念,每一次进行读取的时候,都是把所读到的数据所在page全部读取到buffer pool,这个page通常是16k

    刚刚的情况是没有数据的情况下采取

    先操作db file到Buffer Pool

    那么如果Buffer Pool当中有数据的时候,

    就会先修改Buffer Pool当中的数据

    然后将修改的操作记录到Redo Log当中

    每隔一段时间将Redo Log的记录执行

    刷新磁盘当中的真实数据

    Redo Log中文名称称之为重做日志

    (这个就是保证事务的持久性操作的)

    Redo Log在数据库突然重启的之后

    Redo Log会检查是否还有数据未完成持久化

    如果有,会自动执行

    为啥需要Redo Log再写入到数据磁盘当中

    这个其实与顺序IO和随机IO操作的性能有关

    Redo Log的写入是顺序的IO,操作db file是采用随机IO

    ceaad39b515a145ced988fa8c2236955.png

    Redo Log的几个要点

    1. 数据写入磁盘不用同步写入, 可以后台线程以异步的方式

    进行写入。

    2. Redo是以追加的方式记录, 将以前数据写入磁盘的随机IO

    , 转换成顺序IO。

    在Redo Log没真正刷新磁盘当中的数据的时候,Buffer Pool当中存在的数据,我们称之为脏页,Redo Log刷新数据磁盘的过程,我们称之为刷脏;

    顺手来一张经典图

    上图来自MySQL官方文档

    Undo Log与Redo Log

    一起就完成了事务的原子性,Undo Log是记录操作之前的数据集,Undo Log我们称之为撤销日志,也就是事务操作失败的时候,进行回滚的日志;

    Undo Log应遵从以下两个条件:

    1. 事务在修改了某一个数据的时候,应该是新数据未写入磁盘之前,现将Undo Log操作完成;例如:事务T修改了数据库元素X, 形式如的日志记录必须在X的新值写到磁盘之前写入磁盘中。

    2. 如果事务提交, 则COMMIT日志记录必须在事务改变的所

    有数据库元素先写到磁盘之后写到磁盘中, 但应尽快;

    以上就是MySQL的的Atomicity与Durability特性,那么我们还缺两个;

    Isolation这个特性不得不提到MVCC与锁机制问题

    ·(一个事务)写操作对(另一个事务)读操作情况下:MVCC

    保证隔离性;

    ·(一个事务)写操作对(另一个事务)写操作情况下:锁机制保证隔离性;

    MVCC:全称是Multi-Version Concurrency Control(多版本的并发控制协议),采用版本控制,让不同的事务读取到的数据版本是不一样的一种机制(MVCC是一种无锁的高效解决办法,A事务在进行写操作的时候,B事务可以进行读取数据,并且可以保证数据的隔离性问题);

    MVCC实现的原理

    Innodb表在记录行上其实还有三个不可见的字段的

    a) 6字节的事务ID

    b) 7字节的指向回滚段的指针

    c) 6字节的ROW_ID

    锁机制:A事务在修改数据之前,需要获取相对应的锁;获得锁之后,A事务才可以进行修改数据,如果此时有B数据想要进来操作A事务正在操作的数据,那么需要等待A事务先释放锁资源,才可以进行对于数据的操作;(A事务只有在commit或者rollback之后才会释放锁);

    对于事务的Consistency,只有在事务的前三个特性完成的前提下,才可以完成相应的功能;

    展开全文
  • 在分析这几种实现方案之前我们先来想一下,我们需要的分布式锁应该是怎么样的?(这里以方法锁为例,资源锁同理) 可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行。...

    针对分布式锁的实现,目前比较常用的有以下几种方案:

    基于数据库实现分布式锁 基于缓存(redis,memcached,tair)实现分布式锁 基于Zookeeper实现分布式锁

    在分析这几种实现方案之前我们先来想一下,我们需要的分布式锁应该是怎么样的?(这里以方法锁为例,资源锁同理)

    可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行。

    这把锁要是一把可重入锁(避免死锁)

    这把锁最好是一把阻塞锁(根据业务需求考虑要不要这条)

    有高可用的获取锁和释放锁功能

    获取锁和释放锁的性能要好


    基于数据库实现分布式锁

    基于数据库表

    要实现分布式锁,最简单的方式可能就是直接创建一张锁表,然后通过操作该表中的数据来实现了。

    当我们要锁住某个方法或资源时,我们就在该表中增加一条记录,想要释放锁的时候就删除这条记录。

    基于缓存实现分布式锁

    相比较于基于数据库实现分布式锁的方案来说,基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的,可以解决单点问题。

    目前有很多成熟的缓存产品,包括Redis,memcached以及我们公司内部的Tair。以上实现方式同样存在几个问题:

    1、这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在tair中,其他线程无法再获得到锁。

    2、这把锁只能是非阻塞的,无论成功还是失败都直接返回。

    3、这把锁是非重入的,一个线程获得锁之后,在释放锁之前,无法再次获得该锁,因为使用到的key在tair中已经存在。无法再执行put操作。

    当然,同样有方式可以解决。

    • 没有失效时间?tair的put方法支持传入失效时间,到达时间之后数据会自动删除。
    • 非阻塞?while重复执行。
    • 非可重入?在一个线程获取到锁之后,把当前主机信息和线程信息保存起来,下次再获取之前先检查自己是不是当前锁的拥有者。

    但是,失效时间我设置多长时间为好?如何设置的失效时间太短,方法没等执行完,锁就自动释放了,那么就会产生并发问题。如果设置的时间太长,其他获取锁的线程就可能要平白的多等一段时间。这个问题使用数据库实现分布式锁同样存在


    总结

    可以使用缓存来代替数据库来实现分布式锁,这个可以提供更好的性能,同时,很多缓存服务都是集群部署的,可以避免单点问题。并且很多缓存服务都提供了可以用来实现分布式锁的方法,比如Tair的put方法,redis的setnx方法等。并且,这些缓存服务也都提供了对数据的过期自动删除的支持,可以直接设置超时时间来控制锁的释放。

    使用缓存实现分布式锁的优点

    性能好,实现起来较为方便。

    使用缓存实现分布式锁的缺点

    通过超时时间来控制锁的失效时间并不是十分的靠谱。


    基于Zookeeper实现分布式锁

    基于zookeeper临时有序节点可以实现的分布式锁。

    大致思想即为:每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。 当释放锁的时候,只需将这个瞬时节点删除即可。同时,其可以避免服务宕机导致的锁无法释放,而产生的死锁问题。

    来看下Zookeeper能不能解决前面提到的问题。

    • 锁无法释放?使用Zookeeper可以有效的解决锁无法释放的问题,因为在创建锁的时候,客户端会在ZK中创建一个临时节点,一旦客户端获取到锁之后突然挂掉(Session连接断开),那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。

    • 非阻塞锁?使用Zookeeper可以实现阻塞的锁,客户端可以通过在ZK中创建顺序节点,并且在节点上绑定监听器,一旦节点有变化,Zookeeper会通知客户端,客户端可以检查自己创建的节点是不是当前所有节点中序号最小的,如果是,那么自己就获取到锁,便可以执行业务逻辑了。

    • 不可重入?使用Zookeeper也可以有效的解决不可重入的问题,客户端在创建节点的时候,把当前客户端的主机信息和线程信息直接写入到节点中,下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样,那么自己直接获取到锁,如果不一样就再创建一个临时的顺序节点,参与排队。

    • 单点问题?使用Zookeeper可以有效的解决单点问题,ZK是集群部署的,只要集群中有半数以上的机器存活,就可以对外提供服务。

    使用ZK实现的分布式锁好像完全符合了本文开头我们对一个分布式锁的所有期望。但是,其实并不是,Zookeeper实现的分布式锁其实存在一个缺点,那就是性能上可能并没有缓存服务那么高。因为每次在创建锁和释放锁的过程中,都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行,然后将数据同不到所有的Follower机器上。

    其实,使用Zookeeper也有可能带来并发问题,只是并不常见而已。考虑这样的情况,由于网络抖动,客户端可ZK集群的session连接断了,那么zk以为客户端挂了,就会删除临时节点,这时候其他客户端就可以获取到分布式锁了。就可能产生并发问题。这个问题不常见是因为zk有重试机制,一旦zk集群检测不到客户端的心跳,就会重试,Curator客户端支持多种重试策略。多次重试之后还不行的话才会删除临时节点。(所以,选择一个合适的重试策略也比较重要,要在锁的粒度和并发之间找一个平衡。)


    总结

    使用Zookeeper实现分布式锁的优点

    有效的解决单点问题,不可重入问题,非阻塞问题以及锁无法释放的问题。实现起来较为简单。

    使用Zookeeper实现分布式锁的缺点

    性能上不如使用缓存实现分布式锁。 需要对ZK的原理有所了解。


    三种方案的比较

    上面几种方式,哪种方式都无法做到完美。就像CAP一样,在复杂性、可靠性、性能等方面无法同时满足,所以,根据不同的应用场景选择最适合自己的才是王道。

    从理解的难易程度角度(从低到高)

    数据库 > 缓存 > Zookeeper

    从实现的复杂性角度(从低到高)

    Zookeeper >= 缓存 > 数据库

    从性能角度(从高到低)

    缓存 > Zookeeper >= 数据库

    从可靠性角度(从高到低)

    Zookeeper > 缓存 > 数据库

     

    摘自:http://www.hollischuang.com/archives/1716

    转载于:https://www.cnblogs.com/bonelee/p/6430754.html

    展开全文
  • 本文主要分析在不牵扯分布式的情况下事务与一致性的实现办法。先说一下事务的ACID四个特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 其他的几个特性应该很好理解,...

        本文主要分析在不牵扯分布式的情况下事务与一致性的实现办法。先说一下事务的ACID四个特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

        其他的几个特性应该很好理解,但是一致性这个概念不太好理解,在这一致性指的是数据比较合理,在经过一系列的操作之后数据依然是我们想要看到的,并不是指的语法上的规则,常见的说明例子就是转账问题。

        redu和undo机制是数据库实现事务的基础。redu日志用来在断电/数据库崩溃等状况发生时重演一次刷数据的过程,把redo日志里的数据刷到数据库里,保证了事务的持久性(Durability);undo日志是在事务执行失败的时候撤销对数据库的操作,保证了事务的原子性(Atomicity)。

        但是只有只有原子性和持久性是无法保证数据一致性的,例如:事务1对A用户加了100元,首先获取A的数据,但是这时事务2也对A加了100元,结果应该是加了200元,但是事务1覆盖了事务2,最后只加了100元,所以需要把两个事务隔离起来,即隔离性(Isolation),使的两个事务并发和串行执行的结果都是一致的。

        数据库使用锁的方式保证隔离性(也就是最终数据保证了一致性),InnoDB实现的方式有以下两种:

    1. 悲观锁控制
    2. 乐观锁(数据多版本)控制

    悲观锁:拿来数据就先上锁,这样别的线程拿数据就会阻塞。像行锁,页锁,表锁以及共享锁,排它锁都是悲观锁。我们说的那些锁一般都是悲观锁。

    乐观锁:悲观锁只是一种概念,其实没有锁,MySql默认其他线程不会改变数据,所以不加锁,只是在提交的时候判断是不是被更改过了,一般用版本戳(MVCC )来实现乐观锁。

    一,使用(悲观)锁控制

    按照锁的使用方式分为共享锁和排它锁。

    共享锁(Share Locks,S锁):一个线程给数据加上共享锁后,其他线程只能读取数据,不能修改。

    排它锁(eXclusive Locks,X锁):一个线程给数据加上排它锁后,其他线程不能读取也不能修改。

    没有锁:InnoDB所有的普通select都是快照读,都不加锁。

    兼容性规则为:共享锁和共享锁兼容,排它锁和其他的锁都排斥。

        如果一个请求的锁模式与当前的锁兼容,InnoDB就将请求授予该事务,反之,如果两者不兼容,该事物就会等到锁释放。

        对于update,delete和insert语句,InnoDB会自动给涉及的数据加排它锁,所以如果插入操作卡住了也无法查询;

        对于普通的select语句,InnoDB不会加任何锁;

    事务也可以通过以下语句手动的给事务加共享锁和排它锁:

        select * from table_name where  ... lock in share mode 会给事务加上共享锁;

        select * from table_name where ... for update 会给事务加上排它锁。

     

    按照锁的粒度分为行锁和表锁以及间隙锁

    行锁是通过给索引上的索引项加锁来实现的,只有通过索引条件来检索数据才会用到行锁,否则InnoDB将会使用表锁。

    表锁:select * from table_nane where name = ‘小巷’  for update 。name字段不是唯一索引字段,所以是表锁。

    行锁:select * from table_name where  id = 1 for update 。id 字段为唯一索引字段,所以使用的就是行锁,且是排它锁。

    页锁(又叫Gap锁):又称为间隙锁。所谓表锁锁表,行锁锁行,那么页锁折中,锁相邻的一组数据,可以用来防止幻读。

    通过加锁控制,可以保证数据的一致性,但是同样一条数据,不论用什么样的锁,只可以并发读,并不可以读写并发(因为写的时候加的是排他锁所以不可以读),这时就要引入数据多版本控制了,也就是乐观锁这个概念。

     

    二,使用数据多版本(MVCC)控制

        使用锁控制并发时,只要是写数据的任务没有完成,数据就不可以被其他的任务获取,就连读数据的select操作也会阻塞,这对并发度要求较大的环境有很大的影响,为了解决这个问题引出了数据多版本。

    数据多版本实现的原理是:

    1,写任务发生时,首先复制一份旧数据,以版本号区分

    2,写任务操作新克隆的数据,直至提交

    3,并发读的任务可以继续从旧数据(快照)读取数据,不至于堵塞

    • 排它锁 是 串行执行
    • 共享锁 是 读读并发
    • 数据多版本 是 读写并发

     

    三,redo,undo,回滚段

    在InnoDB的具体实现上,依赖redo日志,undo日志,回滚段(rollback segment)

    redo日志的作用?

        数据库事务提交后,按照随机方式写入磁盘上性能太低,为了提高效率先写到redo日志里,再刷到磁盘上(此时变成了顺序写)。

    假如我在提交事务时数据库崩溃了,重启时,会从redo日志里把没有刷到磁盘的数据刷到磁盘上(redo意为把刷磁盘的操作进行一次重演)。简言之,redo的作用是为了保障已提交事务的ACID特性,也就是保证了数据的D(Durability)持久性。

    undo日志的作用?

        数据库修改数据但未提交时,会将事务修改数据的镜像(即旧数据)存到undo日志里,当事务回滚或数据库崩溃时,会从undo日志里获取旧数据,避免未提交数据对数据库的影响。简言之,undo的作用是为了保障未提交的事务不会对数据库的ACID产生影响。也就是保证了操作的A(Atomicity)原子性。

    回滚段的作用?

        存储undu日志的地方,就是回滚段。

     

    • InnoDB所有的普通select都是快照读,快照读不加锁。这也是InnoDB支持高并发的一个原因之一

     

     

    参考:

    https://www.zhihu.com/question/30272728

    https://blog.csdn.net/xiangwanpeng/article/details/55106732

    https://blog.csdn.net/tanga842428/article/details/52748531

    展开全文
  • 首先明确几个概念:事务的四大特征,redo log,undo log,mysql锁技术(共享锁/排他锁),...2. 一致性(Consistency)一致性指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和...

    首先明确几个概念:

    事务的四大特征,redo log,undo log,mysql锁技术(共享锁/排他锁),MVCC

    四大特性(ACID)

    1.原子性(Atomicity)

    原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。失败回滚的操作事务,将不能对事务有任何影响。

    2. 一致性(Consistency)

    一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。

    例如:A和B进行转账操作,A有200块钱,B有300块钱;当A转了100块钱给B之后,他们2个人的总额还是500块钱,不会改变。

    3. 隔离性(Isolation)

    隔离性是指当多个用户并发访问数据库时,比如同时访问一张表,数据库每一个用户开启的事务,不能被其他事务所做的操作干扰(也就是事务之间的隔离),多个并发事务之间,应当相互隔离。

    例如同时有T1和T2两个并发事务,从T1角度来看,T2要不在T1执行之前就已经结束,要么在T1执行完成后才开始。将多个事务隔离开,每个事务都不能访问到其他事务操作过程中的状态;就好比上锁操作,只有一个事务做完了,另外一个事务才能执行。

    4. 持久性(Durability)

    持久性是指事务的操作,一旦提交,对于数据库中数据的改变是永久性的,即使数据库发生故障也不能丢失已提交事务所完成的改变。

    redo log

    重做日志,是用来实现事务的持久性。重做日志缓冲(redo log buffer)(内存中)以及重做日志文件(redo log)(磁盘中)。当事务提交之后会把所有修改信息都会存到该日志中。

    实例:把张三的银行账户中的余额转到他的理财账户中。

    c55d6f0fdd5798bbf0f2ad07cb63918c.png

    32936aa32a416547ffc33a6d6d2257f9.pngsql实现:

    start transaction;select balance from bank where name="zhangsan";update bank set balance = balance - 400;update finance set amount = amount + 400;commit;

    redolog的工作流程图

    435e67c6d3798a451e2cb57ef2ad6506.png

    作用:mysql 为了提升性能不会把每次的修改都实时同步到磁盘,而是会先存到Boffer Pool(缓冲池)里头,把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

    说简单点就是redolog就是存执行sql的日志,万一数据丢失了,可以从日志里读取,重新执行,保证了事务持久性的特点。

    undo log

    回滚日志,用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反,重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化,为了在发生错误时回滚之前的操作,需要将之前的操作都记录下来,然后在发生错误时才可以回滚。

    91d0d6c0825be18f0e12f95be9dcb0c6.png

    作用:undo log 记录事务修改之前版本的数据信息,因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。

    说简单点就是保存redolog里面的反向sql日志,发生异常回滚的时候执行undo log里面的sql,回滚的事务执行以前,也就是事务回滚的原理,也就是他保证了事务的原子性。

    Mysql共享锁/排他锁

    1、共享锁(shared lock),又叫做"读锁":读锁是可以共享的,或者说多个读请求可以共享一把锁读数据,不会造成阻塞。就是说可以多个人或者多个线程来读,但是不能进行写操作。

    2、排他锁(exclusive lock),又叫做"写锁":写锁会排斥其他所有获取锁的请求,一直阻塞,直到写入完成释放锁。就是说只能一个人或者一个线程来操作,可以读也可以写。

    总结:通过读写锁,可以做到读读可以并行,但是不能做到写读,写写并行。

    MVCC

    通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。

    MVCC在mysql中的实现依赖的是undo log与read view

    undo log :undo log 中记录某行数据的多个版本的数据。

    read view :用来判断当前版本数据的可见性

    说简单点就相当于乐观锁,有了版本号的概念,每行数据都有版本,只能读取到与自己版本相同的数据,要是版本不同就升级版本

    21160b9e15dba4847218011d6892f8b0.png

    事务的隔离性是通过 (读写锁+MVCC)来实现的,而事务的一致性,就是上述所说的redolog,undolog,(读写锁+mvcc)共同来实现的。

    展开全文
  • 首先说说什么是ACID: 它们分别Atomicity(原子性),Consistency(一致性),Isolation(隔离性),Transaction(持久性) 原子性: 意为单个事务里的多个操作要么一起成功,要么一起失败.比如现在有三个插入操作,那么前两个...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"ok,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 总内容 数据库的三范式是什么 一张自增表里面总共有17条数据,删除了最后2条数据,重启mysql数据库,又插入了一条数据,此时id是几 如何获取当前数据库版本 ...mysql索引是怎么实现的 怎么验证my...
  • 2019-01-08 回答乐观锁与悲观锁不同的,它一种逻辑上的锁,而不需要数据库提供锁机制来支持当数据很重要,回滚或重试一次需要很大的开销时,需要保证操作的acid性质,此时应该采用悲观锁而当数据对即时的一致性...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 6.5 事务实现原理之1:Redo Log介绍事务怎么用后,下面探讨事务的实现原理。事务有ACID四个核心属性:A:原子性。事务要么不执行,要么完全执行。如果执行到一半,宕机重启,已执行的一半要回滚回去。C:一致性。...
  • 面试官:”你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“ 你:”我只知道隔离性是怎么做的balabala~~” 面试官:”还是回去等通知吧~” OK,回到正题。说到事务的四大特性原子性(Atomicity)...
  • mysql中事务ACID的实现

    2019-07-17 14:05:40
    引言 场景: ...面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“ 你:“我只知道隔离性是怎么做的balabala~~” 面试官:“还是回去等通知吧~” 正文 我们以从A账户转...
  • 分布式数据库的数据一致性管理其最重要的内核技术之一,也保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技术也在不断的演进,...
  • 介绍事务怎么用后,下面探讨事务的实现原理。事务有ACID四个核心属性: A:原子性。事务要么不执行,要么完全执行。如果执行到一半,宕机重启,已执行的一半要回滚回去。 C:一致性。各种约束条件,比如主键不能为空...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用Mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • Mysql的innoDB存储引擎是怎么实现数据持久化的?一 面试官:数据库ACID属性了解吗? xx:就是原子性、一致性、隔离性、持久性。 面试官:就没了?那你知道Mysql的innoDB存储引擎是怎么实现 D属性 持久性的呢? xx...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 引言照例,我们先来一个场景~面试官:"知道..."面试官:"你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?“你:"我只知道隔离性是怎么做的balabala~~"面试官:"还是回去等通知吧~"OK,回到正题。说...
  • 乐观锁与悲观锁不同的,它一种逻辑上的锁,而不需要数据库提供锁机制来支持当数据很重要,回滚或重试一次需要很大的开销时,需要保证操作的ACID性质,此时应该采用悲观锁而当数据对即时的一致性要求不高,重试一...
  • MySQL事务ACID实现原理

    2020-08-16 10:28:45
    面试官:“你们是用mysql数据库吧,能简单说说innodb中怎么实现这四大特性的么?” 你:"我只知道隔离性是怎么做的balabala~~" 面试官:"还是回去等通知吧~" OK,回到正题。说到事务的四大特性原子性(Atomicity)、...
  • 乐观锁与悲观锁不同的,它一种逻辑上的锁,而不需要数据库提供锁机制来支持当数据很重要,回滚或重试一次需要很大的开销时,需要保证操作的ACID性质,此时应该采用悲观锁而当数据对即时的一致性要求不高,重试一...

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 155
精华内容 62
关键字:

数据库是怎么实现acid的