事务

分布式事务解决方案： 一. 基于XA协议的两阶段提交； 二.消息事务+最终一致性 所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败。 开源的RocketMQ就支持这一特性.该方案采用最终一致的，牺牲了一致性，换来了性能的大幅度提升。存在造成数据不一致的风险。 来源： https://www.cnblogs.com/ZJOE80/p/12181728.html

1.原子性：原子表示不可分割，一个事务一般包含一组（即多个操作），我们将一个事务看做一个整体，一个事务执行之后的结果有两种，要么所有的操作都成功，要么所有得操作都失败。只要事务中有一个操作失败，那么视为整个事务执行失败。事务会回滚到执行之前的状态。 2.一致性：事务在执行的前后数据的整体是保持一致的，类似于物理上的能量守恒。例如：某银行A用户有1000元，B用户有500元A用户向B用户转账1000元，在把转账整个过程视为一个事务，分为两个步骤，A用户转出1000元，B用户收账1000元，在事务执行的前后总金额都是1500元。 3.隔离性：一个事务在执行的时候不能被其他事务所干扰（我在做完一件事之前你做的事不能对我做的事产生影响），即当一个事务在操作某一个数据的时候其他的事务不能对该事物进行操作，例如：在事务操作数据库的某个字段的时候，数据库会将该字段锁起来，等该事务全部完成之后，才能有其他的事务对该字段进行操作。 4.持久性：一个事务执行完毕之后，它对数据的影响就已经确定了，比如一个事务将数据库中的某个表中的某个字段的值进行了修改，那么它对这个字段的修改就是永久性的，如果没有其他的事务或者操作对该字段进行修改，那么这个值永远不变。 来源： CSDN 作者： YangJianzuiniubi 链接： https://blog.csdn.net/YangJianzuiniubi

1.MySQL的逻辑架构 2.并发控制 并发控制存在于MySQL的两个层面中：服务器层以及存储引擎层。 2.1 读写锁 共享锁（读锁）是共享的，或者说是相互不堵塞的。多个客户在同一时刻可以同时读取同一个资源而互不干扰。排他锁（写锁）是互斥的，也就是说一个写锁会阻塞其他的写锁和读锁。 2.2 锁粒度 一种提高共享资源并发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。任何时候，在给定的资源上，锁定的数据越少，则系统的并发程度就越高。 常见的锁粒度包括 表锁 以及 行锁 。表锁会锁定整张表，行锁同理。行级锁只会在存储引擎层实现，而MySQL服务器层则没有实现。 当然，每一种MySQL存储引擎都可以实现自己的锁策略和锁粒度。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，但却会失去对另外一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案。 3.事务 事务就是一组原子性的SQL查询，或者说是一个独立的工作单元。 事务内的语句，要么全部执行，要么全部执行失败。 可以用 start transaction 语句开始一个事务，然后要么使用 commit 提交事务将修改的数据持久保留，要么使用 rollback 撤销所有的修改。 系统需要严格的ACID测试保证事务的概念性（原子性、一致性、隔离性以及持久性）

数据库设计步骤: 表结构 字段类型、是否允许为null、是否有默认值 索引设计 数据库引擎的选择 MySql数据库引擎: 　　概念:决定数据库数据增删改查的方式,MySQL的核心就是存储引擎； 　　InnoDB：默认的引擎，支持事务、外键，查询效率相对较低，安全性较高; 　　MyISAM：不支持事务，查询效率相对较高，增删改效率较低。 SHOW ENGINES # 命令来查看MySQL提供的引擎 SHOW VARIABLES LIKE 'storage_engine'; # 查看数据库默认使用哪个引擎 　　 如果要提供提交、回滚、崩溃恢复能力的事物安全（ACID兼容）能力，并要求实现并发控制，InnoDB是一个好的选择 如果数据表主要用来插入和查询记录，则MyISAM引擎能提供较高的处理效率 如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存中的Memory引擎，MySQL中使用该引擎作为临时表，存放查询的中间结果 如果只有INSERT和SELECT操作，可以选择Archive，Archive支持高并发的插入操作，但是本身不是事务安全的。Archive非常适合存储归档数据，如记录日志信息可以使用Archive 使用哪一种引擎需要灵活选择，一个数据库中多个表可以使用不同引擎以满足各种性能和实际需求，使用合适的存储引擎，将会提高整个数据库的性能

　　 隔离级别 　　在 TransactionDefinition.java 接口中，定义了“ 四种 ”的隔离级别枚举： /** * 【Spring 独有】使用后端数据库默认的隔离级别 * * MySQL 默认采用的 REPEATABLE_READ隔离级别 * Oracle 默认采用的 READ_COMMITTED隔离级别 */ int ISOLATION_DEFAULT = -1; /** * 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读 */ int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED; /** * 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生 */ int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED; /** * 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。 */ int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ; /** * 最高的隔离级别

导语 上篇我们对 Transactional 注解进行了详细的解释，还没看的小伙伴，快看过来 https://blog.csdn.net/weixin_38937840/article/details/103939034 ，本节我们将对事务的使用与回滚进行演示！ Transactional 事务使用与回滚策略 @Transactional public void save ( ) { Demo demo = Demo.builder ( ) .id ( uid ( )) .name ( "javayh" ) .adder ( "beijing" ) .build ( ) ; demoDao.save ( demo ) ; } 我们启动项目，进行接口调用，进行一个简单的插入，小编为了方便这次使用的是JPA，下面我们看一执行的过程； 从下图我们可以看出， 首先Spring为我创建了默认的事务，并进行了默认配置，还不了接的请看上篇的现象介绍 之后进行了数据库的操作，这是我的代码执行完成，没有任何的异常 最后进行了事务的提交和关闭 然后我对上面的代码进行修改 @Transactional public void save ( ) { Demo demo = Demo.builder ( ) .id ( uid ( )) .name ( "javayh" ) .adder (

spring事务失效场景 添加@Transactional后的方法，不会直接操作数据库，例如保存方法，在执行完保存语句后，数据库并没有出现该数据，只有方法结束之后，才会正式保存到数据库。 1 、首先使用如下代码 确认你的bean 是代理对象吗？ 必须是Spring定义（通过XML或注解定义都可以）的Bean才接受事务。 直接new出来的对象添加事务是不起作用的。 可以通过以下方式判断是否是代理对象： AopUtils.isAopProxy(Object object) AopUtils.isCglibProxy(Object object) //cglib AopUtils.isJdkDynamicProxy(Object object) //jdk动态代理； 2 、如使用mysql且引擎是MyISAM，则事务会不起作用，原因是MyISAM不支持事务，可以改成InnoDB； 3 、@Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，事务也会失效。这一点由Spring的AOP特性决定的； 4 、如果你使用了springmvc，可能是context:component-scan重复扫描引起的； 5

原文： MySQL中的锁（表锁、行锁，共享锁，排它锁，间隙锁） 作者： 唐大麦 锁是计算机协调多个进程或线程并发访问某一资源的机制。 在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 表级锁： 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁： 开销大，加锁慢；会出现死锁

-------------------锁及事务的高级使用-------------------- 锁是数据库用来控制共享资源并发访问的机制。 锁用于保护正在被修改的数据 直到提交或回滚了事务之后，其他用户才可以更新数据 一致性 - 一次只允许一个用户修改数据 完整性 - 为所有用户提供正确的数据。如果一个用户进行了修改并保存，所做的修改将反映给所有用户 并行性 －允许多个用户访问同一数据 ----------------------行级锁 行级锁:对正在被修改的行进行锁定。其他用户可以访问除被锁定的行以外的行 行级锁是一种排他锁，防止其他事务修改此行 在使用以下语句时，Oracle会自动应用行级锁： INSERT UPDATE DELETE SELECT … FOR UPDATE SELECT … FOR UPDATE 语句允许用户一次锁定多条记录进行更新 使用 COMMIT 或 ROLLBACK 语句释放锁 SELECT … FOR UPDATE 语法: 　 SELECT … FOR UPDATE [ OF columns ] [ WAIT n | NOWAIT ] ; 说明:　 OF 子句用于指定即将更新的列，即锁定行上的特定列。 　WAIT 子句指定等待其他用户释放锁的秒数，防止无限期的等待 SQL > SELECT * FROM order_master WHERE

为什么要有锁？ 我们都是知道，数据库中锁的设计是解决多用户同时访问共享资源时的并发问题。在访问共享资源时，锁定义了用户访问的规则。根据加锁的范围，MySQL 中的锁可大致分成全局锁，表级锁和行锁三类。在本篇文章中，会依次介绍三种类型的锁。在阅读本篇文章后，应该掌握如下的内容： 为什么要在备份时使用全局锁？ 为什么推荐使用 InnoDB 作为引擎进行备份？ 设置全局只读的方法 表级锁的两种类型 MDL 导致数据库挂掉的问题 如何利用两段锁协议减少锁冲突 如何解决死锁 对于热点表，如何避免死锁检测的损耗？ 全局锁 什么是全局锁？ 全局锁会让整个库处于只读状态，其他线程语句（DML，DDL，更新事务类）的语句都被会阻塞。 使用全局锁的场景 在做全库逻辑备份时，会把整库进行 select 然后保存成文本。 为什么要使用全局锁？ 想象这样一个场景，要备份一个购买系统，其中购买操作设计到更新账号余额表和用户课程表。 现在进行逻辑备份，在备份过程中，一位用户购买了一门课程，这时需要在余额表扣掉余额，然后在购买的课程中加上一门课。正确的顺序肯定是先进行购买操作，减少余额和增加课程然后在进行备份。但却有可能出现这样的问题： 如果在时间顺序上先备份余额表 (u_account)，然后用户购买(操作两张表)，再备份用户课程表(u_course)？ 这时用备份的数据做恢复时，会发现用户没花钱却买了一堂课