数据库事务

Seata 是什么？ Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。在 Seata 开源之前，Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。经过多年沉淀与积累，商业化产品先后在阿里云、金融云进行售卖。2019.1 为了打造更加完善的技术生态和普惠技术成果，Seata 正式宣布对外开源，未来 Seata 将以社区共建的形式帮助其技术更加可靠与完备。 seata的官方文档： http://seata.io/zh-cn/index.html seata github地址： https://github.com/seata/seata 设计初衷 对业务无侵入：即减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入 高性能：减少分布式事务解决方案所带来的性能消耗 发展远景 架构 TC - 事务协调者 维护全局和分支事务的状态，驱动全局事务提交或回滚。 TM - 事务管理器 定义全局事务的范围：开始全局事务、提交或回滚全局事务。 RM - 资源管理器 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 微服务框架支持 目前已支持 Dubbo、Spring Cloud、Sofa-RPC

目录 1.spring-data-redis项目简介 1.1 spring-data-redis项目的设计 1.2 RedisTemplate 1.3 Spring对Redis数据类型操作的封装 1.4 SessionCallback和RedisCallback 2.Spring Boot中配置和使用Redis 2.1 配置Redis 2.2 操作Redis数据类型 2.2.1 字符串和散列的操作 2.2.2 列表操作 2.2.3 集合操作 2.3 Redis的特殊用法 2.3.1 Redis事务 2.3.2 Redis流水线 2.3.3 Redis发布订阅 2.3.4 使用Lua脚本 在现今互联网应用中，NoSql已经广泛应用，在互联网中起到加速系统的作用。有两种NoSQL使用最为广泛，那就是Redis和MongoDB。 Redis是一种运行在内存的数据库，支持7种数据类型的存储。Redis的运行速度很快，大约是关系数据库几倍到几十倍的速度。如果我们将常用的数据存储在Redis中，用来代替关系数据库的查询访问，网站性能将可以得到大幅提高。在现实中，查询数据要远远大于更新数据，一般一个正常的网站查询和更新的比例大约是1:9到3:7，在查询比例较大的网站使用Redis可以数倍地提升网站的性能。 Redis自身数据类型比较少，命令功能也比较有限，运算能力一直不强，所以在Redis2

原子性(Atomicity) 一个事务事务的操作要么全部成功，要么全部失败 一致性(Consistency) 事务开始之前和结束之后，数据库的完整性没有被破坏，写入的资料完全符合所有的预设的规则 这里一致性可能比较难理解，比方说：A转账给B用户100元，但是A只有90元，转完之后A就是-10元了，站在数据结构层是没有问题的，但是在应用层，这个就不符合预设的规则（我们要保证用户的钱>=0） 隔离性(Isolation) 数据库允许并发的事务同时对数据库读写和修改的能力，可以防止多个事务并发执行时导致数据不一致性 持久性(Durability) 事务处理结束后，对数据的修改是永久的，即便系统故障也不会丢失 三 事务并发带来的问题 3.1 脏读 1.事务B更新年龄18 2.事务A读取数据库信息，年龄是18 3.事务B回滚 那么这个就是脏读 3.2 不可重复读 1.事务A先读取数据，年龄为16 2.事务B跟新数据，年龄为18 3.事务B提交 4.事务A再读取数据，年龄为18 事务A连续读取两次的数据都不一样，为不可重复读 3.3 幻读 1.事务A读取年龄大于15的数据，发现有1条记录 2.事务B插入一条记录，并提交 3.事务A再读取年龄大于15的数据，发现有2条记录 事务A就好像出现了幻觉一样，一般幻读出现在范围查询 解决上面的3个问题，就要通过事务的隔离性来解决了

性能调优系列前序文章索引： 程序员必须掌握的性能调优 ：老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，以及介绍了从 X、Y、Z 三个维度优化性能的思路。 从 X 维度优化系统的性能 ：老兵哥分享了从 X 维度优化系统性能的思路，包括让客户端分计算存储任务、优化交互设计等，主要是作为引子拓宽我们性能调优的思路。 应用容器 Tomcat 性能调优 ：Y 维度就是从业务 HTTP 请求的横向处理流程来看，HTTP 请求会穿越网络、计算机、应用容器（Tomcat）、Spring、ORM（Hibernate）、数据库等节点，在这个流程中每个节点都有许多可以可优化的地方，此文主要介绍通过优化应用容器（Tomcat）来优化系统性能的方法。 程序员在转型架构师的过程中需要建立流程化、结构化、系统化的思维方式，而性能调优是非常难得的契机，它既给了我们压力，也给了我们动力，跨越它就是突破自己的过程。建议在阅读本文内容前，先参考下面这个系列的文章了解 Web 应用是怎样处理 HTTP 请求的： 图解 Spring：HTTP 请求的处理流程与机制【1】 图解 Spring：HTTP 请求的处理流程与机制【2】 图解 Spring：HTTP 请求的处理流程与机制【3】 图解 Spring：HTTP 请求的处理流程与机制【4】 图解 Spring：HTTP 请求的处理流程与机制

在这里主要介绍Spring对事务管理的一些理论知识，实战方面参考上一篇博文: http://www.cnblogs.com/longshiyVip/p/5061547.html 1. 事务简介： 事务管理是企业级应用程序开发中必不可少的技术，用来确保数据的完整性和一致性 事务就是一系列的动作，它们被当作一个单独的工作单元。这些动作要么全部完成，要么全部不起作用 2. 事务的四个关键属性(ACID) ① 原子性(atomicity):事务是一个原子操作，有一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用 ② 一致性(consistency):一旦所有事务动作完成，事务就被提交。数据和资源就处于一种满足业务规则的一致性状态中 ③ 隔离性(isolation):可能有许多事务会同时处理相同的数据，因此每个事物都应该与其他事务隔离开来，防止数据损坏 ④ 持久性(durability):一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响。通常情况下，事务的结果被写到持久化存储器中 3. Spring中的事务管理 作为企业级应用程序框架，Spring在不同的事务管理API之上定义了一个抽象层。而应用程序开发人员不必了解底层的事务管理API，就可以使用Spring的事务管理机制。 Spring既支持编程式事务管理(也称编码式事务)，也支持声明式的事务管理

MyISAM是MySQL的默认数据库引擎（5.5版之前），由早期的ISAM（Indexed Sequential Access Method：有索引的顺序访问方法）所改良。虽然性能极佳，但却 有一个缺点：不支持事务处理（transaction） 。不过，在这几年的发展下，MySQL也导入了InnoDB（另一种数据库引擎），以强化参考完整性与并发违规处理机制，后来就逐渐取代MyISAM。 InnoDB，是MySQL的数据库引擎之一，为MySQL AB发布binary的标准之一。InnoDB由Innobase Oy公司所开发，2006年五月时由甲骨文公司并购。与传统的ISAM与MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事务（Transaction）功能，类似于PostgreSQL。目前InnoDB采用双轨制授权，一是GPL授权，另一是专有软件授权。 MyISAM和InnoDB两者之间有着明显区别，简单梳理如下: 1) 事务支持 MyISAM不支持事务，而InnoDB支持。InnoDB的AUTOCOMMIT默认是打开的，即每条SQL语句会默认被封装成一个事务，自动提交，这样会影响速度，所以最好是把多条SQL语句显示放在begin和commit之间，组成一个事务去提交。 MyISAM是非事务安全型的，而InnoDB是事务安全型的，默认开启自动提交，宜合并事务，一同提交

一 视图 视图是一个虚拟表（非真实存在），其本质是【根据SQL语句获取动态的数据集，并为其命名】，用户使用时只需使用【名称】即可获取结果集，可以将该结果集当做表来使用。 使用视图我们可以把查询过程中的临时表摘出来，用视图去实现，这样以后再想操作该临时表的数据时就无需重写复杂的sql了，直接去视图中查找即可，但视图有明显地效率问题，并且视图是存放在数据库中的，如果我们程序中使用的sql过分依赖数据库中的视图，即强耦合，那就意味着扩展sql极为不便，因此并不推荐使用 #两张有关系的表 mysql> select * from course; +-----+--------+------------+ | cid | cname | teacher_id | +-----+--------+------------+ | 1 | 生物 | 1 | | 2 | 物理 | 2 | | 3 | 体育 | 3 | | 4 | 美术 | 2 | +-----+--------+------------+ rows in set (0.00 sec) mysql> select * from teacher; +-----+-----------------+ | tid | tname | +-----+-----------------+ | 1 | 张磊老师 | | 2 | 李平老师 | |

一、Mysql的四个隔离级别 预备工作： 先创建一个test数据库及account表， create database test;use test; create table account( id int not null, balance float not null, PRIMARY KEY ( id) ) 向account中插入两条测试数据 INSERT INTO table(id,balance) VALUES (1,1000); INSERT INTO table(id,balance) VALUES (2,1000); 　　 开启两个控制台窗口，当做两个用户（A和B） 1.1 READ UNCOMMITTED（未提交读） 也即RU，在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 A用户操作如下： set session transaction isolation level read uncommitted; start transaction; select * from

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring

本地事务 事务Transaction由一组SQL组成，具有四个ACID特性 ACID Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况 Consistency 一致性 数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述 isolation 隔离性 事务操作的数据对象 相对于 其他事务操作的数据对象相互隔离，互不影响 durability 持久性 事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏） 事务实现 对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log 重做日志和undo log回滚日志来保证的。 redo log 当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO），也就是会发生数据丢失，如果这个时候，能够在有一个文件，当buffer pool 中的data