事务管理

1. CAP理论 C: Consistency 一致性 A: Availability 可用性 P: Partition tolerance 分区容错性 CAP定理：一个分布式系统不可能同时满足CAP三个要求，最多只能同时满足其中两项。 1.1. CA: 放弃分区容错性，所有数据放一个节点，退回单机模式。 1.2. CP: 放弃可用性，一旦网络故障，受影响服务需要等待恢复时间，系统处于不可用状态。 1.3. AP: 放弃一致性，这里指放弃强一致性，确保最终一致性。 大多数分布式系统的选择。 2. BASE理论 BASE: B ase A vailable(基本可用)， S oft state(软状态), E ventually consistent(最终一致性)。 BASE是对CAP一致性和可用性权衡的结果。 1. 基本可用：指分布式系统出现不可预知故障时，允许损失部分可用性，响应时间合理延长，服务上适当降级。 2. 软状态: 允许分布式系统中的数据处于中间状态，允许各节点数据同步时存在延时。 3. 最终一致性：允许系统中所有数据副本，在经过一段时间同步后，最终能够达到一个一致的状态。不需要实时保证系统的数据一致性。 3. 两阶段提交 (2PC) 数据库支持2PC，又叫XA transactions。 MySQL从5.5版，Oracle从7版，SQL Server 2005开始支持

MySQL面试总结 # MySQL的存储引擎 `MyISAM`（默认表类型）：非事务的存储引擎，基于传统的`ISAM`（有索引的顺序访问方法）类型，是存储记录和文件的标准方法，不是事务安全，不支持外键，适用于频繁的查询。表锁，不会出现死锁，适合小数据和小并发。 - 为什么不会出死锁？（没有事务就不会继续持有锁） 答：因为`MyISAM`再查询的时候，会同时锁定这个`sql`里面所有用到的表（获取锁的顺序是一致的），不局限与一张表，再写锁又重叠时，就得等待。 **注意：【`MySQL5.5`之前默认的是`MyISAM`引擎了，5.5之后的版本默认都是`innodb`作为存储引擎】** `innodb`：支持事务安全的存储引擎，适用于插入和更新，支持外键，行锁，事务。适合大数据，大并发。特别是针对多个并发和`QPS`较高的情况。 - `QPS：`就是每秒查询率，`QPS`是对一个特定服务器再规定时间内能处理多少流量的衡量标准。 - `TPS：`就是每秒传输处理的事务个数。 - `innodb`的行锁模式：共享锁，排他锁，意向共享锁（表锁），意向排他锁（表锁），间隙锁。（注意：如果`sql`语句没有使用索引，`innodb`不能确定操作的行时，使用意向锁（表锁））。 - 死锁问题 - 什么是死锁？ 死锁就是当俩个事务都需要获取对方持有的排他锁才能完成事务的时候，就导致了循环锁等待

1、Zookeeper基本知识 1.1、ZooKeeper集群搭建 Zookeeper集群搭建指的是ZooKeeper分布式模式安装。通常由2n+1台servers组成。这是因为为了保证Leader选举（基于Paxos算法的实现）能过得到多数的支持，所以ZooKeeper集群的数量一般为奇数。 Zookeeper运行需要java环境，所以 需要提前安装jdk。对于安装leader+follower模式的集群， 大致过程如下： 配置主机名称到IP地址映射配置 修改ZooKeeper配置文件 远程复制分发安装文件 设置myid 启动ZooKeeper集群 如果要想使用Observer模式，可在对应节点的配置文件添加如下配置： peerType=observer 其次，必须在配置文件指定哪些节点被指定为Observer，如： server.1:node-1:2181:3181:observer 1.2、ZooKeeper概述 Zookeeper 是一个 分布式协调服务的开源框架 。主要用来解决分布式集群中应用系统的一致性问题。 ZooKeeper本质上是一个分布式的小文件存储系统 。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。 1.3

MySQL-配置文件my.cnf参数优化详解 [client] ######################################################################### # # # MySQL客户端配置 # # # ######################################################################### port = 3306 # MySQL客户端默认端口号 socket = /data/mysql/my3306/mysql.sock # 用于本地连接的Unix套接字文件存放路径 default-character-set = utf8mb4 # MySQL客户端默认字符集 [mysql] ######################################################################### # # # MySQL命令行配置 # # # ######################################################################### auto-rehash # 开启tab补齐功能 socket = /data/mysql/my3306/mysql.sock #

SSIS可靠性和扩展性—事务 在这一个随笔中将介绍在package中如何使用事务来保证数据的完整性和一致性。在SSIS中有两种事务： 　　分布式事务处理事务（Distributed Transaction Coordinator Transactions）：在task，package中使用单独一个或者多个事务处理 　　本地事务（Native Transaction）：SQL Server引擎级别的事务，在一个连接中使用T-SQL中的事务 注意：在SQL Server联机丛书中MSDTC是这样定义的：Microsoft 分布式事务处理协调器 (MS DTC) 允许应用程序跨两个或多个 SQL Server 实例扩展事务。此外，该协调器还允许应用程序参与由符合 Open Group DTP XA 标准的事务管理器管理的事务。 在这里我们将用4个小的练习来学习SSIS中的事务，他们分别是： 　　单个的package：使用DTC建立一个事务 　　 单个的package：使用DTC扩展多个事务 　　2个package：使用DTC建立一个事务 单个package：使用T-SQL中的事务，就是本地事务 在package中使用该事务需要设置package或者task的属性。如果动手做这些练习，会看到这些属性更加精确的解释，如下图1 图1 　　

我前两天看见同事用写了用AOP技术实现缓存的方案，于是好奇看了一下这是怎么实现的。原来是用了.NET中的一个类ContextBoundObject和Attribute相关技术。其实个类在.NET Framework很早就有，至今才认识它，是有点相见恨晚的感觉。网上一搜，已经有了很多使用ContextBoundObject类实现AOP的例子，其中我就看到一篇利用ContextBoundObject和Attribute实现AOP事务实现例子，我想应该和实现AOP缓存是一个道理。下面我就把这篇文章分享出来： 前言 使用Attribute来实现方法级别事务一直是我的梦想，浅谈Attribute [C# | Attribute | DefaultValueAttribute]有体现我的无奈，Attribute确实是真真切切的非侵入式的东西(其实我是想侵入的: ) )，前有DUDU的Attribute在.net编程中的应用系列文章，但是总是离想象和需求有那么点出入，通过三天的努力，Google的陪伴，下面和大家一起分享我这三天的成果 用Attribute实现AOP事务 吧！ 致谢文章 1. Aspect-Oriented Programming Enables Better Code Encapsulation and Reuse 关键性的CallContext是在这里发现的。 2. C#

本文主要讲述springboot提供的声明式的事务管理机制。 一、一些概念 声明式的事务管理是基于AOP的，在springboot中可以通过@Transactional注解的方式获得支持，这种方式的优点是： 1）非侵入式，业务逻辑不受事务管理代码的污染。 2）方法级别的事务回滚，合理划分方法的粒度可以做到符合各种业务场景的事务管理。 本文使用目前最常用的mybatis框架来配置springboot的事务管理机制。下面进入配置方法介绍。 二、springboot mybatis事务配置 1、看一下pom依赖 其中： 1）<parent></parent>标签引入springboot父依赖 2）使用了spring和mybatis集成包，整合spring和mybatis 3）mysql数据库驱动包 4）序列化支持fastjson <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.4.3.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId

目录 Spring：声明式事务 回顾事务 Spring中的事务实现的几种方式 转账的事务管理 思考问题？ Spring：声明式事务 回顾事务 事务在项目开发过程非常重要，涉及到数据的一致性的问题，不容马虎！ 事务管理是企业级应用程序开发中必备技术，用来确保数据的完整性和一致性。 事务就是把一系列的动作当成一个独立的工作单元，这些动作要么全部完成，要么全部不起作用。 事务四个特性ACID 原子性（atomicity） 事务是原子性操作，由一系列动作组成，事务的原子性确保动作要么全部完成，要么完全不起作用 一致性（consistency） 一旦所有事务动作完成，事务就要被提交。数据和资源处于一种满足业务规则的一致性状态中 隔离性（isolation） 可能多个事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏 持久性（durability） 事务一旦完成，无论系统发生什么错误，结果都不会受到影响。通常情况下，事务的结果被写到持久化存储器中 spring中的事务 Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。 Spring事务管理涉及的接口的联系如下： 事务管理器 Spring并不直接管理事务，而是提供了多种事务管理器

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 这一几天一直在回顾事务相关的知识，也准备把以前了解皮毛的知识进行一些深入总结，虽然这一些知识并没有用到，但是了解其实现原理还是很有必要的，因为知道了原理，你也能把它实现出来。 在上一节事务的编程模型里面，主要说明了三种编程模型，一般情况下，我们都接触的是单一资源的事务，也就是单独对一个数据库进行操作。如果需要跨多个资源保证事务一致性 举个例子：在ATM机取钱的时候，需要对用户的账户进行扣款处理，然后发送一条消息给消息服务器（假设消息服务器是用JMS实现的），由消息服务器异步通过短信通知用户。如果用户取款失败，那么消息服务器不应该发送短信给用户。如何保证 用户帐务扣款 和 消息服务器的消息保持一致性，也就是说 取款成功，消息服务器就持久化消息，然后发送短信给用户，取款失败，消息服务器就回滚消息，啥都不做。 在上面这种情况下，就需要使用分布式事务，也就是跨越多个资源的保证数据一致性。 X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由这个厂商进行具体的实现。这个思想在java 平台里面到处都是。 X/Open DTP 定义了三个组件： AP

一、事务管理 1.事务概述 事务指的是逻辑上的 一组 操作，组成这组操作的各个单元要么全都成功，要么全都失败。 事务作用：保证在一个事务中多次操作，要么全都成功，要么全部失败。 一组 ：无论多少SQL语句，必须使用同一个连接对象操作，包括insert，update，delete，不包括select，因为select不改变原有数据 2.mysql事务操作 sql语句 描述 start transaction； 开启事务 commit； 提交事务 rollback； 回滚事务 准备数据 # 创建一个表：账户表 . create database webdb ; # 使用数据库 use webdb ; # 创建账号表 create table account ( id int primary key auto_increment , name varchar ( 20 ) , money double ) ; # 初始化数据 insert into account values ( null , 'jack' , 10000 ) ; insert into account values ( null , 'rose' , 10000 ) ; insert into account values ( null , 'tom' , 10000 ) ; 操作：