数据库事务

8.Redis的持久化 两种策略的选择： RDB持久化方式能够在指定的时间间隔内对数据进行快照存储。AOF持久化方式记录每次对服务器的写操作，当服务器重启时会重新执行这些写命令来恢复原始的数据，AOF命令以redis协议追加保存每次写操作到文件末尾。 Redis能对AOF文件进行后台重写，使得AOF文件体积不会过大 只做缓存：如果希望数据在服务器运行的时候存在，也可以不使用任何持久化方式。 官网建议如果使用，两种同时使用： 在这种情况下，redis先载入AOF文件来恢复原始数据，因为通常AOF数据比RDB数据更完整。当RDB数据不正确时，服务器重启也只会加载AOF文件。RDB用于备份数据库，快速重启，以防万一。 性能建议 RDB（Redis DataBase） 定义：在指定的时间间隔内将内存中的数据集快照写入磁盘，Snapshot快照，它恢复时是将快照文件直接读到内存里。 Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 Fork 作用是复制一个与当前进程一样的进程

简答题 1.MySQL常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别(至少5点)？ l InnoDB存储引擎 InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），其它存储引擎都是非事务安全表，支持行锁定和外键，MySQL5.5以后默认使用InnoDB存储引擎。 InnoDB主要特性 为MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在 SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中，可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来，甚至在同一个查询中也可以混合。 。 l MyISAM存储引擎 MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但不支持事务，不支持外键。 MyISAM主要特性： 被大文件系统和操作系统支持。 当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，若下一个块被删除，就扩展到下一块自动完成。 每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16。 最大的键长度是1000字节，这也可以通过编译来改变

分布式事务 通过MQ解决分布式事务的思路 1) 业务和消息生成耦合在一起 2) 业务和消息解耦 RocketMQ 中的事务消息 1) 目前RMQ3.2.6中事务消息的实现原理及存在的问题 2) 问题解决思路 本文介绍RocketMQ提供的第三种类型的消息——Transaction Message(事务消息)。在说事务消息之前，我们先来说说分布式事务的那些事！ 分布式事务 什么是分布式事务，我的理解是一半事务。怎么说，比如有2个异构系统，A异构系统要做T1，B异构系统要做T2，要么都成功，要么都失败。 要知道异构系统，很显然，不在一个数据库实例上，它们往往分布在不同物理节点上，本地事务已经失效 2阶段提交 2阶段提交协议，Two-Phase Commit，是处理分布式事务的一种常见手段。2PC，存在2个重要角色：事务协调器（TC），事务执行者。 2PC，可以看到节点之间的通信次数太多了，时间很长！时间变长了，从而导致，事务锁定的资源时间也变长了，造成资源等待时间变长！在高并发场景下，存在严重的性能问题！ 通过MQ解决分布式事务的思路 下面，我们来看看MQ在高并发场景下，是如何解决分布式事务的。 考虑生活中的场景： 我们去北京庆丰包子铺吃炒肝，先去营业员那里付款（Action1），拿到小票（Ticket），然后去取餐窗口排队拿炒肝（Action2）。思考2个问题：第一

什么是事务： 数据库是所有系统的核心模块，它存储在磁盘中，在逻辑上，以数据的形式呈现给用户，支持增删改查（CRUD）并在过程中保证数据的正确，可靠。而做到这一点的，就是事务(Transaction)。 事务的四个特性（ACID）： 1.原子性（Atomicity）： 要么全部完成，要么全部取消 ，当对数据库进行操作时，根据业务逻辑，我们会操作个表中的数据，当一步操作出错时，会让该事务中的所有操作都回滚，数据还是未操作时的样子。 举例 ： 当A向B转账时，具体操作为：A账户减少100元，B账户上增加100元，但是此时B账户添加的时候出错了，导致A账户的钱没了，B转账未成功，或者是A的资金没有减少，但是B却平白无故增加了100元，所以A,B的账户的金额要么都成功，要么都失败。 2.隔离性（Isolation）： 有多个事务同时进行，最后结束时，最终的结果应该是相同的 举例 ：A向B转账100元，同时C又给A转账300元，最后的结果是A账户上增加了200元。而不是A增加了300，B增加了100，C少了300。 3.持久性（Durability）： 当事务结束时，数据会永久的保存到数据库里 举例 ：当A刚刚往外转完账时，数据库发生崩溃，但是转完账依旧会保存到数据库里。 4.一致性（Consistency）： 保证账户的数据不会凭空消失或产生，该特性依赖原子性，隔离性 世界上有10种人

SQL Server通过在锁资源上使用不同类型的锁来隔离事务。为了开发安全的事务，定义事务内容以及应在何种情况下回滚至关重要，定义如何以及在多长时间内在事务中保持锁定也同等重要。这由隔离级别决定。应用不同的隔离级别，SQL Server赋予开发者一种能力，让他们为每一个单独事务定义与其他事务的隔离程度。事务隔离级别的定义如下： · 是否在读数据的时候使用锁 · 读锁持续多长时间 · 在读数据的时候使用何种类型的锁 · 读操作希望读已经被其他事务排他锁住的数据时，怎么办？在这种情况下， SQL Server 可以： · 一直等到其他事务释放锁 · 读没有提交的数据 · 读数据最后提交后的版本 ANSI 99定义了4种事务隔离级别，SQL Server 2005能够完全支持这些级别： · 未提交读 在读数据时不会检查或使用任何锁。因此，在这种隔离级别中可能读取到没有提交的数据。 · 已提交读 只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是 SQL Server 的 默认 隔离级别。 · 可重复读 像已提交读级别那样读数据，但会保持共享锁直到事务结束。 · 可序列化 工作方式类似于可重复读。但它不仅会锁定受影响的数据，还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围，这种情况可以导致幻像读。 此外，SQL

转载于： https://www.iteye.com/blog/chenzhou123520-1860954 最近学习了一下数据库的悲观锁和乐观锁，根据自己的理解和网上参考资料总结如下： 悲观锁介绍（百科）： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 使用场景举例：以MySQL InnoDB为例 商品goods表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单，那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。 1. 如果不采用锁，那么操作方法如下 //1.查询出商品信息 select status from t_goods where id=1; //2.根据商品信息生成订单 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status为2 update t_goods set status=2; 上面这种场景在高并发访问的情况下很可能会出现问题。

Yum Yum 是Red Hat软件包管理器，它能够查询有关可用软件包的信息，从存储库获取软件包，安装和卸载软件包，以及将整个系统更新到最新的可用版本。Yum在更新，安装或删除软件包时执行自动依赖性解析，因此能够自动确定，获取和安装所有可用的依赖软件包。 Yum可以配置新的，额外的存储库或 包源 ，还提供许多增强和扩展其功能的插件。百胜可以执行许多与 RPM 相同的任务; 此外，许多命令行选项都是类似的。Yum可以在一台计算机或一组计算机上轻松简单地进行包管理。 检查和更新包 通过Yum，可以检查系统是否有等待应用的更新。可以列出需要更新的软件包并将其作为整体进行更新，也可以更新选定的单个软件包。 查询更新 要查看系统上哪些已安装的软件包具有可用更新，请使用以下命令： yum check-update yum check-update 的输出类似这样： 更新包 您可以选择一次更新单个包，多个包或所有包。如果您更新的软件包或软件包的任何依赖项本身都有可用的更新，那么它们也会更新。 更新单个包 要更新单个程序包，请运行以下命令 root ： yum update 包名 yum 提供更新信息，然后提示您确认更新; yum默认以交互方式运行。如果您已经知道 yum 命令计划执行哪些事务，则可以使用该 -y 选项自动回答 yes yum请求的任何问题（在这种情况下，它以非交互方式运行）。但是

转载： 对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题， 但话又说回来了，既然逃避不掉，那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧。 为了更好的理解并发和同步，我们需要先明白两个重要的概念: 同步和异步 1、同步和异步的区别和联系 　　所谓同步，可以理解为在执行完一个函数或方法之后，一直等待系统返回值或消息，这时程序是出于阻塞的，只有接收到 返回的值或消息后才往下执行其它的命令。 异步，执行完函数或方法后，不必阻塞性地等待返回值或消息，只需要向系统委托一个异步过程，那么当系统接收到返回 值或消息时，系统会自动触发委托的异步过程，从而完成一个完整的流程。 同步在一定程度上可以看做是单线程，这个线程请求一个方法后就待这个方法给他回复，否则他不往下执行(死心眼)。 异步在一定程度上可以看做是多线程的(废话，一个线程怎么叫异步)，请求一个方法后，就不管了，继续执行其他的方法。 　　 同步就是一件事，一件事情一件事的做。 异步就是，做一件事情，不引响做其他事情。 例如：吃饭和说话，只能一件事一件事的来，因为只有一张嘴。 但吃饭和听音乐是异步的，因为，听音乐并不引响我们吃饭。 对于Java程序员而言，我们会经常听到同步关键字synchronized，假如这个同步的监视对象是类的话

回滚段 可以说是用来保持数据变化前映象而提供一致读和保障事务完整性的一段磁盘存储区域。当一个事务开始的时候，会首先把变化前的数据和变化后的数据先写入日志缓冲区，然后把变化前的数据写入回滚段，最后才在数据缓冲区中修改（日志缓冲区内容在满足一定的条件后可能被写入磁盘，但在事务提交的时候日志必须写入磁盘，而数据缓冲区中的数据依赖于检查点的发生和DBWR进程的活动） Rollback是一个代价昂贵的操作，如果一个系统的事务回退率过高，应该检查系统是否正常或者程序设计思路是否存在问题。查询数据库启动依赖的 事务回退率，如果发现太高，一定要引起重视。 --查询回退率的sql SELECT NAME, VALUE FROM v$sysstat WHERE NAME IN ('user commits', 'transaction rollbacks'); 关于回滚段的数据，如果是delete操作，则回滚段将回记录整个行的数据；如果是update，则只记录被修改了的字段的变化前的数据（前映像）；如果是insert，则只记录插入记录的rowid。所以，假如commit，那么回滚段中简单标记该事务已经提交；假如rollback，则操作是 delete的话，把回滚段中的数据重新写回数据块，操作是update的话则把变化前的数据修改回去，操作是insert的话则根据rowid把该记录删除

说说你对Spring 的IoC 机制 的理解？ 没有Spring之前： 写一套系统，web服务器，tomcat，一旦启动之后，他就可以监听一个端口号的http请求，然后可以把请求转交给你的servlet，jsp，配合起来使用的，servlet处理请求。 比如在我们的一个tomcat + servlet的这样的一个系统里，有几十个地方，都是直接用MyService myService = new MyServiceImpl()，直接创建、引用和依赖了一个MyServiceImpl这样的一个类的对象。 这个系统里，有几十个地方，都跟MyServiceImpl类直接耦合在一起了。 如果我现在不想要用MyServiceImpl了，我们希望用的是NewServiceManagerImpl，implements MyService这个接口的，所有的实现逻辑都不同了，此时我们很麻烦，我们需要在系统里，几十个地方，都去修改对应的MyServiceImpl这个类，切换为NewServiceManagerImpl这个类。 改动代码成本很大，改动完以后的测试的成本很大，改动的过程中可能很复杂，出现一些bug，此时就会很痛苦。 归根结底，代码里， 各种类之间完全耦合在一起，出现任何一丁点的变动，都需要改动大量的代码 ，重新测试，可能还会有bug。 有Spring之后： Spring IoC,