事务

1、类结构图 2、类分析 import org.springframework.core.Constants; import org.springframework.lang.Nullable; import org.springframework.transaction.TransactionDefinition; import org.springframework.transaction.support.TransactionTemplate; import java.io.Serializable; /** * 可以定义：事务传播、隔离级别、超时等。 * * 这个类是{@link TransactionDefinition}接口的默认实现， * 提供bean风格的配置和合理的默认值(PROPAGATION_REQUIRED、ISOLATION_DEFAULT、TIMEOUT_DEFAULT、readOnly=false)。 * * 这个类是 * {@link TransactionTemplate}和 * {@link org.springframework.transaction.interceptor.DefaultTransactionAttribute} * 的基类。 */ @SuppressWarnings("serial") public class

TransactionDefinition 实例(默认描述传播行为、隔离级别、超时等。 类图如下： 接口分析如下： package org.springframework.transaction; import org.springframework.jdbc.datasource.DataSourceTransactionManager; import org.springframework.lang.Nullable; import org.springframework.transaction.PlatformTransactionManager; import org.springframework.transaction.jta.JtaTransactionManager; import org.springframework.transaction.support.AbstractPlatformTransactionManager; import java.sql.Connection; /** * 定义与spring兼容的事务属性的接口，可以设置传播行为、隔离级别、超时等。 * 基于类似于EJB CMT属性的传播行为定义。 * * 注意，除非启动一个实际的新事务，否则不会应用隔离级别和超时设置。 * 因为只有{@link #PROPAGATION_REQUIRED}

一、Redis 数据类型 1. string 字符型。 2.hash hash 结构化的对象。 key不可重复 3.list 队列 lpush rpop lpop rpush 4. set 集合 value不可重复 5. zset 有序集合 set的基础上加了分数（排序）。 二、Redis事务 1.multi (事务启动) 、 exec (事务执行) 、 watch（监视某几个键有没有被别的客户端进行修改，一旦有任何的键被修改过,exec的时候都会直接返回一个nil，不执行事务）、discard（立刻取消事务，清空事务队列中所有命令）。 2.redis数据库里会存在一个watched_keys字典，这个字典里 key为被监视的key，值为一个链表，链表里记录着监视该key的客户端，一旦被监视的key发生了修改，该key对应的客户端会打开REDIS_DIRTY_CAS标识，代表该客户端的事务安全性被破坏了。这就是watch命令的实现。 3.为什么redis的事务不支持回滚？ 　　因为这种复杂的功能和redis的设计理念不符。并且redis事务中出错原因通常是编程错误，只在开发环境出现，生产环境可避免。 4.redis事务中命令执行出错的结果? 　　redis并不会中断事务的执行，会继续执行后续的操作命令。exec的时候，出错的命令会被标识出来，并给出原因。 5.

文章目录 1.mysql元数据 获取服务器元数据 2.mysql函数 2.1 常用的字符串函数 2.2 数字函数 2.3 日期函数 2.4 高级函数 3.MySQL索引 3.1 普通索引 3.1.1 创建索引 3.1.2 修改表结构(添加索引) 3.1.3 创建表的时候直接指定 3.1.3 删除索引的语法 3.2 唯一索引 3.2.1 创建索引 3.2.2 修改表结构 3.2.3 创建表的时候直接指定 3.3 使用ALTER 命令添加和删除索引 3.4 使用 ALTER 命令添加和删除主键 3.5 显示索引信息 4.MySQL 事务 4.1、事务控制语句： 4.2、MYSQL 事务处理主要有两种方法： 1.mysql元数据 你可能想知道MySQL以下三种信息： 查询结果信息： SELECT, UPDATE 或 DELETE语句影响的记录数。 数据库和数据表的信息： 包含了数据库及数据表的结构信息。 MySQL服务器信息： 包含了数据库服务器的当前状态，版本号等。 在MySQL的命令提示符中，我们可以很容易的获取以上服务器信息。 获取服务器元数据 以下命令语句可以在 MySQL 的命令提示符使用，也可以在脚本中 使用，如PHP脚本。 命令 描述 SELECT VERSION( ) 服务器版本信息 SELECT DATABASE( ) 当前数据库名 (或者返回空) SELECT

1简介 ORACLE数据库除了可以保存永久表外，还可以建立临时表temporary tables。这些临时表用来保存一个会话SESSION的数据， 或者保存在一个事务中需要的数据。当会话退出或者用户提交commit和回滚rollback事务的时候，临时表的数据自动清空， 但是临时表的结构以及元数据还存储在用户的数据字典中。 临时表只在oracle8i以及以上产品中支持。 2详细介绍 Oracle临时表分为 会话级临时表和事务级临时表。 会话级临时表是指临时表中的数据只在会话生命周期之中存在，当用户退出会话结束的时候，Oracle自动清除临时表中数据。 事务级临时表是指临时表中的数据只在事务生命周期中存在。当一个事务结束（commit or rollback），Oracle自动清除临时表中数据。 临时表中的数据只对当前Session有效，每个Session都有自己的临时数据，并且不能访问其它Session的临时表中的数据。因此， 临时表不需要DML锁.当一个会话结束(用户正常退出 用户不正常退出 ORACLE实例崩溃)或者一个事务结束的时候，Oracle对这个会话的表执行 TRUNCATE 语句清空临时表数据.但不会清空其它会话临时表中的数据. 你可以索引临时表和在临时表基础上建立视图.同样,建立在临时表上的索引也是临时的,也是只对当前会话或者事务有效. 临时表可以拥有触发器.

文章纲要 此次分享的缘由 目前分布式事务问题是怎么解决的 行业中有什么解决方案 这些解决方案分别有什么优缺点 别人是怎么做的 我们可以怎么来做 此次分享的缘由 支付重构 考虑支付重构的时候，自然想到原本属于一个本地事务中的处理，现在要跨应用了要怎么处理。拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户服务。原本收到充值回调后，可以将修改订单状态和增加金币放在一个mysql事务中完成的，但是呢，因为服务拆分了，就面临着需要协调2个服务才能完成这个事务 所以就带出来，我们今天要分享和讨论的话题是： 怎么解决分布式场景下数据一致性问题，暂且用分布式事务来定义吧。 同样的问题还存在于其他的场景： 送礼： 调用支付服务：先扣送礼用户的金币，然后给主播加相应的荔枝，确认第一步成功后，播放特效，发聊天室送礼评论等复制代码 充值成功消息： 完成充值订单，发送订单完成的kafka消息，在涉及支付交易等付费接口的时候，数据一致性的问题就显得尤为重要，因为都是钱啊 目前分布式事务是怎么解决的呢？ 问题肯定不是新问题，也就是目前已经有相应的解决方案了，那就看一下现在是怎么来解决这类问题的吧。 以购买基础商品成功后发送支付订单完成消息为例：假设支付下单购买基础商品，此刻已经收到支付回调，订单已经处理成功了，这个时候kafka服务故障，消息发送失败

面试官心理分析 只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。 现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，如果是分布式系统，肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如 TCC 方案的网络问题、XA 方案的一致性问题。 面试题剖析 分布式事务的实现主要有以下 5 种方案： XA 方案 TCC 方案 本地消息表 可靠消息最终一致性方案 最大努力通知方案 两阶段提交方案/XA方案 所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。 这种分布式事务方案，比较适合单块应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 Spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。 这个方案，我们很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下，

数据库访问是通过事务完成的，首先我们搞清楚什么是事务？ 被视为整体的一组工作 这组工作要么完全完成，要么全部不完成，不存在部分完成情况 真实生活中以转账说明事务： 第一步，从账户A中减去X元金额； 第二步，将X元金额存入账户B 这些多步操作必须全部完整完成，不能半途而废。数据库事务的工作方式与此相同。他们能保证，无论发生什么事情，数据的操作处理都被看成是原子的（你永远不会看到“转变一半”的情况）。 原子性是DBMS维护ACID属性的一部分，ACID包括： Atomicity原子性 : 事务中所有操作要么全部发生，要么全部不。 Consistency一致性 : 数据库从一致状态开始到一致状态结束。 Isolation隔离性 : 一个事务的执行是隔离于其他事务的。 Durability :如果事务已经确认提交，其效果是持久保存在数据库中。 那么在并发访问数据库的情况下会发生什么问题？并发流程可能会改变隔离性和一致性这两个属性。让我们假设两个用户预订了一架飞机的同一个座位： 客户1 发现一个空座位 客户2 发现同样的空座位 客户1预订了这个座位 客户2也同时预订了这个座位 我们将事务的顺序执行称为 schedule 调度，它表示基于时间先后的一系列事务执行，在这里客户1和客户2分别存在两个事务，这个两个事务同时发生，我们需要通过串行化 serializability 来保证事务正确执行

用表锁定代替事务 在MySQL 的MyISAM类型数据表中，并不支持COMMIT（提交）和ROLLBACK（回滚）命令。当用户对数据库执行插入、删除、更新等操作时，这些变化的数据都被立刻保存在磁盘中。这样，在多用户环境中，会导致诸多问题，为了避免同一时间有多个用户对数据库中指定表进行操作。可以应用表锁定来避免在用户操作数据表过程中受到干扰。当且仅当该用户释放表的操作锁定后，其他用户才可以访问这些修改后的数据表。 应用表锁实现伪事务 实现伪事务的一般步骤如下： 对数据库中的数据表进行锁定操作，可以对多个表做不同的方式锁定 执行数据库操作，向锁定的数据表中执行添加、删除、修改操等操作 释放锁定的数据表，以便让正在队列中等待查看或操作的其他用户可以浏览数据表中的数据或对操作表执行各种数据的操作。 事务和性能 应用不同孤立级的事务可能会对系统造成一系列影响，采用不同孤立级处理事务，可能会对系统稳定性和安全性等诸多因素造成影响。另外，有些数据库操作中，不需要应用事务处理，则用户在选择数据表类型时，需要选择合适的数据表类型。所以，在选择表类型时，应该考虑数据表具有完善的功能，且高效的执行前提下，也不会对系统增加额外的负担。 应用小事务 应用小事务的意义在于：保证每个事务不会在执行前等待很长时间，从而避免各个事务因为互相等待而导致系统的性能大幅度下降。 选择合适的孤立级

RabbitMQ 解决方案 1、生产者将消息传输给mq时丢失 A：可以使用 RabbitMQ 提供的事务功能； 生产者 发送数据之前 开启 RabbitMQ 事务 channel.txSelect ，再发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 channel.txRollback ，然后重试发送消息；如果收到了消息，那么可以提交事务 channel.txCommit 。 // 开启事务 channel.txSelect try { // 这里发送消息 } catch (Exception e) { channel.txRollback // 这里再次重发这条消息 } // 提交事务 channel.txCommit 这样会降低吞吐量，降低性能。 B： 开启 confirm 模式； 生产者开启 confirm 模式之后，每次写的消息都会分配一个唯一的 id，如果写入了 RabbitMQ 中，RabbitMQ 会回传一个 ack 消息，表示这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调生产者 nack 接口表示消息接收失败，生产者可以重试。而且生产者可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么可以重发。 事务机制和 cnofirm