事务

转自：http://www.jianshu.com/p/af7043e6c8f9 Redis基础类型回顾 String Redis中最基本，也是最简单的数据类型。注意，VALUE既可以是简单的String,也可以是复杂的String，如JSON，在实际中常常利用fastjson将对象序列化后存储到Redis中。另外注意mget批量获取可以提高效率。 Hash Hash结构适用于存储对象，相较于String，存储占用更少的内存。Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值，而且还可以快速定位数据。比如，如果我们把表User中的数据可以这样放置到Redis中：Hash存储，KEY：User，Field:USERID，VALUE：user序列化后的string。 List 既可以当做栈、又可以当做队列。实际上，可以利用List的先进先出或者先进后出的特性维护一段列表，比如排行榜、实时列表等，甚至还可以简单的当做消息队列来使用。 Set Set是String类型的不重复无序集合。Set的特点在于，它提供了集合的一些运算，比如交集、并集、差集等。这些运算特性，非常方便的解决实际场景中的一些问题，如共同关注、共同粉丝等。 ZSet ZSet就是SortedSet。实际中，很多排序场景都可以考虑ZSet来做。 Redis发展过程中的三种模式：主从、哨兵、集群

SQL 语言共分为四大类：数据查询语言 DQL ，数据操纵语言 DML ， 数据定义语言 DDL ，数据控制语言 DCL 。其中用于定义数据的结构，比如 创建、修改或者删除数据库； DCL 用于定义数据库用户的权限；在这篇文章中我将详细讲述这两种语言在 Oracle 中的使用方法。 DML 语言 DML 是 SQL 的一个子集，主要用于修改数据，下表列出了 ORACLE 支持的 DML 语句。 语句 用途 INSERT 向表中添加行 UPDATE 更新存储在表中的数据 DELETE 删除行 SELECT FOR UPDATE 禁止其他用户访问 DML 语句正在处理的行。 LOCK TABLE 禁止其他用户在表中使用 DML 语句 插入数据 INSERT 语句常常用于向表中插入行，行中可以有特殊数据字段，或者可以用子查询从已存在的数据中建立新行。 列目录是可选的，缺省的列的目录是所有的列名，包括 comlumn_id,comlumn_id 可以在数据字典视图 ALL_TAB_COLUMNS,USER_TAB_COLUMNS, 或者 DBA_TAB_COLUMNS 中找到。 插入行的数据的数量和数据类型必须和列的数量和数据类型相匹配。不符合列定义的数据类型将对插入值实行隐式数据转换。 NULL 字符串将一个 NULL 值插入适当的列中。关键字 NULL 常常用于表示将某列定义为

用一个银行账号转钱的案例来说明spring事务的实现。 在转钱过程中，一个账号钱增加，另一个减少，那么当有异常产生时，就会出现钱转丢了的现象 一个减少了，而另一个没有增加，这个时候就需要把这两个行为绑定到一起，要么同时发生，要么都不发生 这就用到了事务，事务就是指在逻辑上的一组操作，这组操作要么全部成功，要么全部失败 实现spring事务的四种方式分别为： （1）编程式事务管理：需要手动编写代码，在实际开发中很少使用 （2）声明式事务管理： （2.1）基于TransactionProxyFactoryBean的方式，需要为每个进行事务管理的类做相应配置 （2.2）基于AspectJ的XML方式，不需要改动类，在XML文件中配置好即可 （2.3）基于注解的方式，配置简单，需要在业务层类中添加注解 （2.2）和（2.3）在开发中使用比较多，前者配置一目了然，可以在XML文件中得到所有信息，后者配置简单方便 需要做的一些准备工作： 1.在数据库中新建一张account数据表 SQL脚本： CREATE TABLE `account` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, `money` double DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE

Spring事务的基本原理 Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。对于纯JDBC操作数据库，想要用到事务，可以按照以下步骤进行： 获取连接 Connection con = DriverManager.getConnection() 开启事务con.setAutoCommit(true/false); 执行CRUD 提交事务/回滚事务 con.commit() / con.rollback(); 关闭连接 conn.close(); 使用Spring的事务管理功能后，我们可以不再写步骤 2 和 4 的代码，而是由Spirng 自动完成。那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢？解决这个问题，也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下，注解方式为例子 配置文件开启注解驱动，在相关的类和方法上通过注解@Transactional标识。 spring 在启动的时候会去解析生成相关的bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据@Transaction的相关参数进行相关配置注入，这样就在代理中为我们把相关的事务处理掉了（开启正常提交事务，异常回滚事务）。 真正的数据库层的事务提交和回滚是通过binlog或者redo

一、脚本录制 1、启动loadrunner，点击Start Record开始录制 Start Recording对话框中的内容解释： Application type：一般默认为Internet Applications，B/S应用；若测试非B/S的内容，则需按实际情况进行选择。 Program to record：指定录制时使用的浏览器，默认为IE。 （注：若调用浏览器出现异常，可手工填写IE的完整的绝对路径。另外，建议浏览器保持干净，不安装多余的插件，否则会出现各种问题。） URL Address：填写要录制的程序地址URL。 Working directory：脚本存放的工作目录。 Record into Action：包含vuser_init、Action和vuser_end。区别：vuser_init和vuser_end中的脚本代码只执行一次，Action中可以执行设定的次数。同时集合点也只能在Action中设置。目前默认选择Action。 2、开始录制后，桌面会显示如下所示工具条，通过该工具条上的按钮，可完成停止录制、暂停录制、Action切换以及其他动作 录制状态的按钮不停闪烁，则正在进行录制 3、脚本回放 回放之前要先单击上图中第二个标出的按钮，编译检查脚本是否存在语法错误，然后再单击第一个按钮回放脚本。 若脚本在运行过程中出现错误

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说

什么是MySQL InnoDB下的当前读和快照读？ 当前读 它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。 快照读 快照读的前提是隔离级别不是可串行化，串行级别下的快照读会退化成当前读。 快照读是基于提高并发性的考虑，快照读的实现基于MVCC。可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作。 快照读可能读到的并不一定是最新版本，而有可能是之前的历史版本。 MVCC就是为了实现读或写冲突不加锁，而这个读指的就是快照读，而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现。 MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突 MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突 MVCC是为了解决什么问题？ 锁机制可以控制并发操作，但是其系统开销较大，而MVCC可以在大多数情况下代替行级锁，使用MVCC能降低系统开销。 MVCC基本原理 MVCC的实现通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，意味着在同一个时刻不同事物看到的相同表里的数据可能是不同的。 不同存储引擎的MVCC实现是不同的，典型的有乐观并发控制和悲观并发控制。 基本特征： 每个数据都存在一个版本，每次更新数据时都更新该版本。

汇总篇： http://www.cnblogs.com/dunitian/p/4822808.html#tsql 异常处理汇总-数据库系列 http://www.cnblogs.com/dunitian/p/4522990.html 我这种情况应该算是情况之一吧 先贴图： 看看磁盘：。。。 把事务模式改成“简单”，然后收缩一下日记和数据文件 命令可以参考这篇文章： http://www.cnblogs.com/dunitian/p/6047709.html 可以了， 如果需要后期恢复之类的，建议不要把事务模式改成简单，直接收缩，然后扩盘或者移个磁盘吧 完事之后，恢复事务模式为原来的即可 我的解决方案：迁移下位置呗： 先分离，再附加 exec sp_detach_db BigData_TestInfo_PartialData go exec sp_attach_db BigData_TestInfo_PartialData,N'D:\SQL Server 2016\BigData_TestInfo_AnyData.mdf',N'G:\SQLData\BigData_TestInfo_PartialData_log.ldf' go 来源： https://www.cnblogs.com/dunitian/p/6255584.html

一、微服务简介 1. 微服务的诞生 微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 2. 微服务架构与SOA架构的区别 微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。 微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。 3. 微服务架构引发的问题 随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。