数据库一致性

redo--> undo-->datafile insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据. redo解释： 在Oracle数据库中，执行数据修改操作后， 并不是马上写入数据文件，而是首先生成重做信息 ，并写入SGA中的一块叫LOG_BUFFER的固定区域，LOG_BUFFER的空间并不是无限大，事实上它非常小，一般设置在3～5MB左右。LOG_BUFFER有一定的触发条件，当满足触发条件后，会有相应进程将LOG_BUFFER中的内容写入一个特定类型的文件，就是传说中的联机重做日志文件。 UNDO： undo->记录更改前的一份copy，但你系统rollback时，把这份copy重新覆盖到原来的数据 redo->记录所有操作， 用于恢复 （redo records all the database transaction used for recovery） undo->记录所有的前印象， 用于回滚 （undo is used to store uncommited data infor used for rollback） redo->已递交的事务,实例恢复时要写到数据文件去的 undo->未递交的事务. redo的原因是

目录 事务简介 事物的定义 事务的目的 事务的状态 事务的ACID属性 ACID简介 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） 总结 参考文献 版权声明：本文为Heriam博主原创文章，遵循CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接： https://jiang-hao.com/articles/2019/backend-transactions-acid.html 事务简介 事物的定义 事务（Transaction）是由一系列对系统中数据进行访问或更新的操作所组成的一个程序执行逻辑单元（Unit）。在计算机术语中，事务通常就是指 数据库 事务 。 在数据库管理系统（DBMS）中，事务是数据库恢复和并发控制的基本单位。它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。 例如，银行转帐工作：从源帐号扣款并使目标帐号增款，这两个操作必须要么全部执行，要么都不执行，否则就会出现该笔金额平白消失或出现的情况。所以，应该把他们看成一个事务。 在现代数据库中，事务还可以实现其他一些事情，例如，确保你不能访问别人写了一半的数据；但是基本思想是相同的——事务是用来确保 无论发生什么情况，你使用的数据都将处于一个合理的状态 ： transactions

redis存储缓存，mysql存储数据。缓存进行有效期设置。但是更新mysql，不会更新缓存。这样导致缓存和数据库的一致性问题比较长 mysql更新后，进行更新redis缓存。查询的时候先查询redis缓存，如果没有缓存，只查询数据库进行更新缓存；缓存和数据库一致性的短 mysql更新后，通过mq消息消费，异步进行redis更新；这样可以减少连接过多的问题；但是无法解决时序性问题，同样的键值被两个服务更新后。但是无法保证进入消息系统的顺序是准确的 监听binlog，时序性问题得到解决；也进行了异步控制 来源： CSDN 作者： 龙仔1984 链接： https://blog.csdn.net/ma_ru_long/article/details/104113221

分布式–BASE原则 概念 BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。 BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。 基本可用（Basically Available） 什么是基本可用呢？指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。**假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言： 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。 软状态 什么是软状态呢？ 相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。 软状态指的是： 指允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在延时。 最终一致性 上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后

兴起原因 Not only SQL 传统的关系性数据库 关系代数理论基础 RDBMS只能纵向扩展：通过一台服务器增加性能终究难以满足数据量增长。 严格的数据库模式 索引机制，查询优化引擎：适当量级查询效率高 事务一致性：ACID 数据完整性：主键、约束 标准化：sql标准 技术支持：商业数据库 可维护：管理员维护 关系型数据库主从模式 面对日益增长的数据量，多台服务器的写主读从，分离单台服务器压力，但效果有限，且： 集群部署配置复杂 主库压力带来延迟 扩容重新分区复杂 web2.0的需求 关系型数据库事务机制需要额外的开销，但是在Web2.0通常不要求严格的数据库事务 不需要严格的读写实时性 不包含复杂的sql查询：连接操作牺牲性能节约空间 扩充关系型数据库无法实现的特点 1.灵活的可扩展性 2.灵活的数据模型 3.与云计算紧密结合：根据负载动态伸缩集群节点 NoSQL数据库优势 1.海量数据管理需求 2.高并发需求：动态数据实时生成性能需求 3.可扩展、高可用：突发事务访问量急剧增大 NoSQL数据库劣势 缺乏底层理论基础 事务强一致性：不适用关键业务 数据模型 不同场景下需要不同的数据模型 四大类型 键值数据库 如Redis存储键值对， 适合内容缓存 简单的数据模型 频繁读写 非结构化信息同时也有一些缺点，在一些场景下是不适合的：条件查询效率低、键与键之间没有办法反应联系关系

1 什么是数据库的事务？ 1.1 事务的典型场景 比如下单，会操作订单表，资金表，物流表等等，这个时候我们需要让这些操作都 在一个事务里面完成。在金融的系统里面事务配置是很常见的，比如行内转账的这种操 作，如果我们把它简单地理解为一个账户的余额增加，另一个账户的余额减少的情况（当 然实际上要比这复杂），那么这两个动作一定是同时成功或者同时失败的。 1.2 事务的定义 维基百科的定义：事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由 一个有限的数据库操作序列构成。 这里面有两个关键点， 第一个，它是数据库最小的工作单元，是不可以再分的。 第二个，它可能包含了一个或者一系列的 DML 语句，包括 insert delete update。 1.3 哪些存储引擎支持事务 InnoDB 支持事务，这个也是它成为默认的存储引擎的一个重要原因： https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html 另一个是 NDB。 1.4 事务的四大特性 第一个，原子性，Atomicity，也就是我们刚才说的不可再分，也就意味着我们对数 据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失 败的情况，以刚才提到的转账的场景为例，一个账户的余额减少，对应一个账户的增加， 这两个一定是同时成功或者同时失败的。

1：CAP理论核心 CAP理论的核心是：一个分布式系统不可能同时很好的满足 一致性，可用性和分区容错性 这三个需求， 最多只能同时较好的满足两个。 因此，根据CAP原理将NoSQL数据库分成了 满足CA原则、满足CP原则和满足AP原则 三大类: CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。 CP：满足一致性，分区容忍必的系统， 通常性能不是特别高 。 AP：满足可用性，分区容忍性的系统， 通常可能对一致性要求低一些 。 CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性 是我们必须需要实现的。所以我们只能在 一致性和可用性 之间进行权衡，没有 NoSQL系統能同时保证这三点。 C:强一致性 A:高可用性 P:分布式容忍性 CA：传统Oracle数据库 AP：大多数网站架构的选择 CP ：Redis、Mongodb 注意:分布式架构的时候必须做出取舍。 2：一致性与可用性抉择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。 数据库事务一致性需求： 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一 致性要求 并不高。允许实现最终一致性。 数据库的写实时性和读实时性需求： 对关系数据库来说，插入一 条数据之后立刻查询

备份的作用 灾难恢复 回滚 审计 测试 创建备库 难点 在线备份（热备份），即不停机备份 RTO（恢复时间目标）和 PRO（恢复点目标） 越来越严格 FTWRL 导致的锁表 快照备份 快照备份是指通过文件系统支持的快照功能对数据库进行备份。 备份的原理是将所有的数据库文件放在同一分区中，然后对该分区执行快照工作，对于Linux而言，需要通过 LVM(Logical Volumn Manager)来实现。LVM 使用写时复制(copy-on-write)技术来创建快照，对整个卷的某个瞬间的逻辑副本。 LVM有一个快照预留区域，如果原始卷数据有变化时，LVM保证在任何变更写入之前，会复制受影响块到快照预留区域。简单来说，快照区域内保留了快照点开始时的一致的所有old数据。对于更新很少的数据库，快照也会非常小。 对于MySQL而言，为了使用快照备份，需要将数据文件，日志文件都放在一个逻辑卷中，然后对该卷快照备份即可。 由于快照备份，只能本地，因此，如果本地的磁盘损坏，则快照也就损坏了。快照备份更偏向于对误操作防范，可以将数据库迅速恢复到快照产生的时间点，然后结合二进制日志可以恢复到指定的时间点。 Mysqldump 关键参数： –single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效

这是在网上copy下来的ACID的概念，可以直接跳过看后面： 1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 其中，原子性和持久性的概念比较好理解。但是最近发现老是把一致性和隔离性混淆。 个人理解，隔离性主要是针对读操作的。在不同事务之间，读操作隔离。比如另一个事务对数据修改后，会不会影响当前事务的读操作，要不要读到更新后的数据。 一致性，主要强调的是数据的更新是不是“正确”，即，是不是符合我们的预期，这个和读操作应该是要分开看待的，这里应该只强调写操作。 造成我对这俩个概念的混淆的原因是，在java的并发编程中，我们关注的似乎只有一致性

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体