事务

文章目录 简介 传统IT中心问题 共享服务体系优势 分布式框架 单体架构 中心化框架 去中心化框架 微服务 dubbo 服务中心 定义 划分原则 数据拆分 纵向拆分 横向拆分 分库分表原则 数据库中间件 异步化 方式 传统分布式事务 柔性事务 缓存和秒杀 数字化运营 服务调用监控 日志处理 稳定平台 简介 传统IT中心问题 烟囱式系统建设模式 。弊端： 重复功能建设和维护带来的重复投资。 系统间的交互和集成成本高昂。ESB这种总线式SOA代价高昂。 不利于业务的沉淀和持续发展。项目制造成设计扩展性、维护积极性不高。 业务支持是IT中心的职能 。原因： IT中心人不懂业务，无法对业务发展有自己的看法，无法优化创新业务流程。 项目制重复劳动较多，对能力的提升不是线性的，IT人无法对业务有足够了解和沉淀。 共享服务体系优势 服务重用 。 SOA的本质是服务重用，但是ESB中则作为集成工具，没有实现松耦合带来的业务复用。 ESB中同类数据如订单等分散在各个模块，打通成本高。 滋养服务 。 项目制度造成服务提供者没有积极性发展已有的服务。 新服务不稳定，应该是做强服务，而不是定制。 业务创新 。 共享中心接触各种业务场景，培养特定业务专家，带来创新。 业务快速试错 。 小前台协作效率高、方向调整快，可以用较小的成本决定是投入还是放弃该业务。 发展大数据 。 ESB数据分布广、格式不统一

1.外键 1.1 概念： a.什么是外键 外键约束是指有关联的两个数据表之间的跨表条件约束。 b.为什么使用外键 ？ 1.保证主表和从表数据的合理性。 2.防止误删主表数据。 3.限制不合理数据插入从表。 2.2 使用外键 a.外键添加 语法： alter table 从表 add [constraint 约束名字] foreign key (外键字段) references 主表(关联字段) [操作]; b.外键删除 语法： alter table 从表 drop foreign key 约束名字; c.外键高级 语法： alter table 从表 add [constraint 约束名字] foreign key (外键字段) references 主表(关联字段) [on delete {级别}] [on update {级别}] 分为3个级别的操作： 1.严格限制：restrict。严格限制不允许任何操作。默认就是严格限制。 2.级联操作：cascade。主表（关联字段）更新或删除时，从表也跟着改变。 3.置NULL：set null。主表（关联字段）更新或删除时，从表置NULL。 d.外键注意事项 1. 2个表的引擎必须是InnoDB。 2. 2个表的关联字段数据类型必须一致。 3. 创建外键的字段必须是索引类型，如果不是，系统会自动创建。 4.

redo--> undo-->datafile insert一条记录时, 表跟undo的信息都会放进 redo 中, 在commit 或之前, redo 的信息会放进硬盘上. 故障时, redo 便可恢复那些已经commit 了的数据. redo解释： 在Oracle数据库中，执行数据修改操作后， 并不是马上写入数据文件，而是首先生成重做信息 ，并写入SGA中的一块叫LOG_BUFFER的固定区域，LOG_BUFFER的空间并不是无限大，事实上它非常小，一般设置在3～5MB左右。LOG_BUFFER有一定的触发条件，当满足触发条件后，会有相应进程将LOG_BUFFER中的内容写入一个特定类型的文件，就是传说中的联机重做日志文件。 UNDO： undo->记录更改前的一份copy，但你系统rollback时，把这份copy重新覆盖到原来的数据 redo->记录所有操作， 用于恢复 （redo records all the database transaction used for recovery） undo->记录所有的前印象， 用于回滚 （undo is used to store uncommited data infor used for rollback） redo->已递交的事务,实例恢复时要写到数据文件去的 undo->未递交的事务. redo的原因是

使用位置 : @Transactional事务注解 既可以写在方法上也可以写在类上 @Transactional( rollbackFor = Exception.class ) 使用: 1.默认值为UncheckedException，包括了RuntimeException和Error. 2.当我们直接使用 @Transactional 不指定 rollbackFor 时，Exception及其子类都不会触发回滚 详情细节参考大佬 : https://zhuanlan.zhihu.com/p/38208248 https://www.cnblogs.com/clwydjgs/p/9317849.html 下面情况会回滚: 1.如果没有加@Transactional注解，那么这两个操作就不在一个事务里面，不具有原子性。如果deleteAll之后抛异常，那么就会导致只删除不新增。 2.加了@Transactional之后，这两个动作在一个事务里头，具有原子性，要么全部成功，要么全部失败。如果deleteAll之后抛异常，则事务回滚，恢复原先被删除的数据。 @Transactional public void deleteAllAndAddOneTransactional(Customer customer) { customerRepository.deleteAll(); if (

前言 J2EE的事务管理位于业务层，Spring提供了分层设计业务层的事务处理解决方案。 spring为我们提供了一组事务控制的接口，这组接口是在spring-tx-5.0.2.RELEASE.jar中。 spring的事务控制都是基于AOP的，既可以用编程方式实现，也可以通过配置实现，重点是是基于配置的。 PlatformTransactionManager TransactionDefinition是事务的定义信息，里面有 获取事务对象名称 getName() 获取事务隔离级别 getIsolationLevel() 获取事务传播行为 getPropagationBehavior() 获取事务超时时间 getTimeout() 获取事务是否只读 isReadOnly() xml配置型 注解型 来源： CSDN 作者： 番茄发烧了 链接： https://blog.csdn.net/bless2015/article/details/103940430

第12章 使用FP-growth算法来高效发现频繁项集([代码][ch12]) FP 优点 因为 FP-growth 算法只需要对数据集遍历两次，所以速度更快。 FP树将集合按照支持度降序排序，不同路径如果有相同前缀路径共用存储空间，使得数据得到了压缩。 不需要生成候选集。 比Apriori更快。 缺点 FP-Tree第二次遍历会存储很多中间过程的值，会占用很多内存。 构建FP-Tree是比较昂贵的。 适用数据类型 标称型数据(离散型数据)。 FP-Tree算法全称是FrequentPattern Tree算法，就是频繁模式树算法，他与Apriori算法一样也是用来挖掘频繁项集的，不过不同的是，FP-Tree算法是Apriori算法的优化处理，他解决了Apriori算法在过程中会产生大量的候选集的问题，而FP-Tree算法则是发现频繁模式而不产生候选集。但是频繁模式挖掘出来后，产生关联规则的步骤还是和Apriori是一样的。 创建FP树步骤 创建根节点，用NULL标记。 统计所有的事务数据，统计事务中各个类型项的总支持度(在下面的例子中就是各个商品ID的总个数) 依次读取每条事务，比如T1， 1， 2， 5，因为按照总支持度计数数量降序排列，输入的数据顺序就是2， 1， 5，然后挂到根节点上。 -依次读取后面的事务，并以同样的方式加入的FP树中，顺着根节点路径添加

文中代码托管在码云平台，点击进入 文章目录 连接池 事务控制以及设计方法 事务的基本概念 Mybatis中的事务操作 Mybatis 基于XML配置的动态SQL语句的使用 多表查询 一对多 一对一 多对多 连接池 连接池可以减少获取连接所消耗的时间和性能，就像一个容器，把连接初始化后放在这个容器里，当要用的时候就取出连接，可以说连接池就是一个用于存储连接的容器，该容器使用 集合 实现，该集合必须是 线程安全 的，不能两个线程拿到统一的连接，该集合还必须有队列的特性（ 先进先出 ） Mybatis连接池提供了 3 种方式的配置 （1）配置的位置：主配置文件的 dataSource 标签，其type属性就是表示采用何种连接池，其值有三种： ❤ POOLED 采用传统的java.sql.DataSource规范中的连接，Mybatis中有针对规范的实现，每次使用的时候就从池中获取一个来用 ❤ UNPOOLED 采用传统的获取连接的方式，虽然也实现了java.sql.DataSource接口，但是并没有使用池的思想，每次使用的时候就创建一个新的连接来用 ❤ JNDI 采用服务器提供的JNDI技术实现来获取DATaSource对象，不同的服务器所能拿到的DataSource是不同的，如果不是web或者maven的var工程是不能使用的 。 （2）POOLED工作流程：首先查看空闲区

文章目录 隔离级别 数据库事务的知识 详解隔离级别 传播行为 传播行为的定义 @Transactional 调用失效问题 隔离级别 数据库事务的知识 数据库事务具有以下4 个基本特征， 也就是著名的ACID 。 Atomic （原子性）：事务中包含的操作被看作一个整体的业务单元， 这个业务单元中的操作要么全部成功，要么全部失败，不会出现部分失败、部分成功的场景。 Consistency （一致性）：事务在完成时，必须使所有的数据都保持一致状态，在数据库中所有的修改都基于事务，保证了数据的完整性。 Isolation （隔离性）： 这是我们讨论的核心内容，正如上述，可能多个应用程序线程同时访问同一数据，这样数据库同样的数据就会在各个不同的事务中被访问，这样会产生丢失更新。为了压制丢失更新的产生，数据库定义了隔离级别的概念，通过它的选择，可以在不同程度上压制丢失更新的发生。因为互联网的应用常常面对高并发的场景，所以隔离性是需要掌握的重点内容。 Durability （持久性）：事务结束后，所有的数据会固化到一个地方，如保存到磁盘当中，即使断电重启后也可以提供给应用程序访问。 详解隔离级别 未提交读 未提交读（ read uncommitted ）是最低的隔离级别，其含义是允许一个事务读取另外一个事务没有提交的数据。未提交读是一种危险的隔离级别，所以一般在我们实际的开发中应用不广，

MySQL事务隔离级别详解 博客分类： SQL MySQL 数据结构 SQL SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。 Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行

原文地址： http://xm-king.iteye.com/blog/770721 SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。 Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影”行