数据库事务

3 月，跳不动了？>>> 有时候我们需要将大量数据批量写入数据库，直接使用程序语言和Sql写入往往很耗时间，其中有一种方案就是使用MySql Load data infile导入文件的形式导入数据，这样可大大缩短数据导入时间。 假如是从MySql客户端调用，将客户端的文件导入，则需要使用 load local data infile. LOAD DATA INFILE 语句以很高的速度从一个文本文件中读取行到一个表中。文件名必须是一个文字字符串。 1，开启load local data infile. 假如是 Linux 下编译安装， 如果使用源码编译的 MySQL ，在configure的时候，需要添加参数：--enable-local-infile 客户端和服务器端都需要，否则不能使用local参数。 ./configure --prefix=/usr/local/mysql --enable-local-infile make install 若是其它系统，可在配置文件中配置： 在MySql 配置文件My.ini文件中下面项中加入local-infile=1： add: [mysqld] local-infile=1 [mysql] local-infile=1 客户端和服务端度需要开启，对于客户端也可以在执行命中加上--local-infile=1 参数： mysql -

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。 我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。 Spring在 TransactionDefinition 接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。 Java代码 TransactionDefinition public interface TransactionDefinition { int getPropagationBehavior(); int getIsolationLevel(); int getTimeout(); boolean isReadOnly(); } getTimeout()方法，它返回事务必须在多少秒内完成。 isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。 getIsolationLevel(

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

99% 的人都能看懂的「补偿」以及最佳实践 也许你对降级已经有了一些认识，这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。 「补偿」机制的意义 以电商的购物场景为例： 客户端 ----> 购物车微服务 ----> 订单微服务 ----> 支付微服务。 这种调用链非常普遍。 那么为什么需要考虑补偿机制呢？ 正如之前几篇文章所说，一次跨机器的通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。 而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。 但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 可能你会问，之前也看到过「补偿」和「事务补偿」或者「重试」，它们之间的关系是什么？ 你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。 题外话：在笔者看来，不管用什么方式，只要通过额外的方式解决了问题都可以理解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，而后者则是一个正向操作。 只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”

using System; using System.Data; using System.Xml; using System.Data.SqlClient; using System.Collections; using System.Configuration; namespace BookDAL { /// /// SqlServer数据访问帮助类 /// public sealed class SqlHelper { #region 私有构造函数和方法 private SqlHelper() { } /// /// 将SqlParameter参数数组(参数值)分配给SqlCommand命令. /// 这个方法将给任何一个参数分配DBNull.Value; /// 该操作将阻止默认值的使用. /// /// 命令名 /// SqlParameters数组 private static void AttachParameters(SqlCommand command, SqlParameter[] commandParameters) { if (command == null) throw new ArgumentNullException("command"); if (commandParameters != null) { foreach (SqlParameter p

1. 事务消息原理图 　RocketMQ除了支持普通消息，顺序消息之外，还支持了事务消息。 1. 什么是分布式事务？ 　　分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. RocketMQ中分布式事务的使用 　　在RocketMQ中分布式事务执行过程分为三个阶段，RocketMQ第一阶段发送 Prepared消息 时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。当RocketMQ确认消息发送失败时，RocketMQ会定期扫描消息集群中的事物消息，如果发现了 Prepared消息 ，它会向消息发送端(生产者)确认，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。 　　实现方式： 　　Producer实现： package com.wangx.rocketmq.transaction; import org.apache.rocketmq.client

本地事务 事务类型 事务可以分为本地事务和分布式事务两种类型。这两种事务类型是根据访问并更新的数据资源的多少来进行区分的。本地事务是在单个数据源上进行数据的访问和更新，而分布式事务是跨越多个数据源来进行数据的访问和更新。在这里要说的事务是基于数据库这种数据源的。 JDBC 事务 在 JAVA 中，我们使用 JDBC 来连接数据库，访问和更新数据。那么在 JDBC 中是如何实现事务的，事务是被谁来管理的？这个答案当然是数据库， JDBC 本身并没有处理事务的能力，而是依赖于底层数据库，底层数据库来提供事务的服务。在很多资料上会提到， JDBC 的事务是基于连接的，也就是那个 Connection 对象，这个连接的本质其实是连接到数据库的一个 Socket ，与数据库建立连接以后就可以向数据库发送指令和数据，最终数据库会根据接收到的指令和数据来进行增删改查以及事务的处理。另外，事务是被限制在单个连接上的，这就好像我们去银行的营业厅办理业务，营业厅有多个窗口，我们只会在自己的窗口上与银行工作人员进行沟通并处理自身的业务，而不能跨窗口，告诉别的窗口的工作人员把那哥们的钱转到自己卡上，这事也就只能想想。 数据库事务例子 下面先看一个 MYSQL 数据库事务的例子： 1、创建表 创建用户表 CREATE TABLE USERS ( USER_ID INT NOT NULL AUTO

数据库优化 建表优化 1）数据库范式 l 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。 如电话列可进行拆分---家庭电话、公司电话 l 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 l 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。 比如 Student 表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话） 这样一个表结构，就存在上述关系。 学号 --> 所在院校 --> ( 院校地址，院校电话 ) 这样的表结构，我们应该拆开来，如下。 （学号，姓名，年龄，性别，所在院校） -- （所在院校，院校地址，院校电话） 满足这些规范的数据库是简洁的、结构明晰的；同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。 2）数据类型选择 l 数字类型 Float 和 double 选择（尽量选择 float ） 区分开TINYINT / INT / BIGINT，能确定不会使用负数的字段，建议添加 unsigned定义 能够用数字类型的字段尽量选择数字类型而不用字符串类型的 l 字符类型 char,varchar,TEXT的选择：非万不得已不要使用 TEXT 数据类型，定长字段，建议使用

分布式事务解决方案整理 1.2PC/3PC模式 1.1 介绍： 依赖资源管理器(mysql, redis)支持XA协议， 数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务, 所有结点要么全做要么全不做。 1.2 特点: 需要依赖资源管理器RM(数据库)对XA的支持。 整个处理过程需要锁住事务资源，性能比较低。 场景一： 1）协调者节点向所有参与者节点发出”正式提交(commit)”的请求。 2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”完成”消息。 4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。 场景二： 1）协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。 2）参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。 3）参与者节点向协调者节点发送”回滚完成”消息。 4）协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。 2. TCC模式 2.1介绍 2PC的另类实现，TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑的调度来实现分布式事务，

环境搭建 导入maven依赖 <!--spring提供的数据库操作工具--> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>5.0.2.RELEASE</version> </dependency> <!--c3p0 数据库连接池--> <dependency> <groupId>com.mchange</groupId> <artifactId>c3p0</artifactId> <version>0.9.5.5</version> </dependency> <!--mysql连接器--> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.48</version> </dependency> 配置数据库相关信息 @Configuration @ComponentScan("com.spring.tx") public class TxConfig { /** * 配置数据源 */ @Bean public DataSource dataSource() throws