数据库事务

Hbase 列式存储以流的方式在列中存储所有的数据 。对于任何记录，索引都可以快速地获取列上的数据；列式存储支持行检索，但这需要从每个列获取匹配的列值，并重新组成行。HBase（Hadoop Database）是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase是Google BigTable的开源实现，模仿并提供了基于Google文件系统的BigTable数据库的所有功能。HBase可以直接使用本地文件系统或者Hadoop作为数据存储方式，不过为了提高数据可靠性和系统的健壮性，发挥HBase处理大数据量等功能，需要使用Hadoop作为文件系统。HBase仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务，主要用来存储非结构化和半结构化的松散数据。 Hbase中表的特点：大，稀疏，面向列 Hadoop生态系统中的各层系统 HBase位于结构化存储层； HDFS为HBase提供了高可靠性的底层存储支持； MapReduce为HBase提供了高性能的计算能力； Zookeeper为HBase提供了稳定服务和失败恢复机制； Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单；

transaction本意是买卖、交易。数据库世界为了强调数据的原子性，中译为 事务。 SQL标准规定不同隔离级别下产生的问题不同，会出现脏读、幻读与不可重复读的现象。对应四种事务的隔离级别： Read UnCommitted 会出现脏读、幻读与不可重复读现象 ReadCommitted 只会出现幻读与不可重复读现象 Repeatable Read 只会出现幻读现象 Serializable 串行执行 不过，各种数据库实现对SQL标准支持不同。 解决脏读、幻读与不可重复读的现象的两种解决方案： 方案一：读操作使用mvcc，写操作加锁 mvcc也叫版本链。每条聚簇索引叶子节点的记录都有隐藏的列：trx_id与roll_pointer，每个事务都有唯一的id。在操作记录时，又会产生undo日志，undo日志形成的链表的引用就保存在roll_pointer位置。 在读取一条记录时，通过快照生成一个ReadView的结构，他会记录当前系统中正活动的事务id，遍历roll_pointer的版本链进行对比，如果ReadView里包含undo的事务id，则证明该事务并没有提交，不能采用此日志的处理结果。一直遍历得到的事务id不在ReadView里，并且小于ReadView的最小事务id(因为事务id有全局变量记录并递增，小的事务id说明产生的更早)的事务，则返回此事务处理后的结果。 简单的说

在 数据库的锁机制 中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以，不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 悲观锁 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。 悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 悲观锁，正如其名，它指的是对数据被外界

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

@Transactional ----------------------------------------------------------------------------------------------------------------------------- 通过AOP，在方法执行时控制事务 事务基本要素 原子性 (Atomicity): 事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 一致性 (Consistency): 事务开始前和结束后，数据库的完整性约束没有被破坏。比如A向B转账，不可能A扣了钱，B却没收到。 隔离性 (Isolation): 同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 持久性 (Durability): 事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 用法： 需要回滚不要在测试方法上使用@Rollback，用@Transactional即可 如果采用了读写分离配置，那么千万不要在测试查询的方法上加回滚事务标记，否则只会经过写库

一、锁 1、锁的概述 InnoDB存储引擎中，事务的隔离性主要是由锁机制实现的。开发多用户的应用，很大的一个难点就在于并发访问：一方面既要最大程度地实现数据库的并发访问，另一方面又要确保每个用户能以一致的方式读取、修改数据，为此，我们需要锁机制。 锁机制是数据库系统区别于文件系统的另一个关键特性，锁机制用于管理对共享资源的并发访问，保证数据的完整性和一致性。这里的共享资源不仅仅是行数据，还包括缓冲池中的LRU列表，删除、添加、移动LRU列表中的元素时，有需要锁来保证一致性。 2、锁的类型 （1）共享/排他锁 MySQL提供了两种锁的粒度：行级锁、表级锁。一般而言，锁的粒度越小，并发度越高；锁用得越多，开销越大（锁的各种操作如获取锁、释放锁、检查锁状态等都会增加系统开销）。因此我们通常只锁定尽可能少的数据量，另外我们需要在锁开销和并发度之间找好平衡点。 InnoDB存储引擎提供两种行级锁： 共享锁（S Lock）：允许事务读一行数据； 排他锁（X Lock）：允许事务删除或更新一行数据。 如果事务T1已经获得行r的共享锁，那么事务T2可以立即获得行r的共享锁以读取数据（锁兼容）；如果事务T1已经获得行r的共享锁/排他锁，那么事务T2要想获得行r的排他锁/共享锁或排他锁必须等待事务T1释放锁（锁不兼容）。共享锁和排他锁均用在事务中，随着事务的结束而释放。 （2）意向锁

事物管理对于企业应用来说是至关重要的，好使出现异常情况，它也可以保证数据的一致性。 spring 支持编程式事务管理和声明式事务管理两种方式。 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。 显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。 声明式事务管理也有两种常用的方式

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、微服务以及分布式数据管理中存在的问题 单体应用通常使用单个关系型数据库，由此带来的好处在于应用能够使用 ACID 事务，后者提供了重要的操作特性： 原子化： 原子粒度的更改 一致性： 数据库的状态始终保持一致 隔离： 并发执行的事务显示为串行执行 持久： 事务一旦提交就不会被撤销 如此，应用能够简单地开始事务、更改（插入、更新和删除）多行、以及提交事务。 使用关系型数据库的另一大好处是它支持 SQL。SQL 是一门丰富、可声明的和标准化的查询预约。用户能够轻松通过查询将多个表中的数据组合起来，然后 RDBMS 查询调度器决定执行查询的最优方法。用户不必关心底层细节，比如如何访问数据库。此外，由于所有的应用数据在一个数据库中，很容易查询。 然而，微服务架构中的数据访问变得复杂许多。每个微服务拥有的数据专门用于该微服务，仅通过其 API 访问。这种数据封装保证了微服务松散耦合，并且可以独立更新。但如果多个服务访问相同数据，架构更新会耗费时间、也需要所有服务的协调更新。 更糟糕的是，不同的微服务通常使用不同类型的数据库。现代应用存储和处理各种类型的数据，而关系型数据库并非总是好选择。对于一些使用场景，特定的 NoSQL 数据库能提供更方便的数据模型、更好的性能和可扩展性。譬如，服务使用 Elasticsearch

一. 基本概念 事务回滚：如果在一个事务中某个SQL执行事务，希望回到事务的原点，保证数据库数据的完整性。 在MyBatis中默认是关闭了JDBC的自动提交功能。 （1）每一个SqlSession默认都是不自动提交事务； （2）session.commit()提交事务； （3）openSession(true)。自动提交。setAutoCommit(true). MyBatis底层是对JDBC的封装。 （1）JDBC中excuteUpdate()执行新增，删除，修改的SQL。返回值是int,表示受影响的行数。 （2）MyBatis中 <insert><delete><update> 标签没有resultType属性，其返回值都是int。 在openSession()时，Mybatis会在创建SqlSession的同时创建一个Transaction(事务对象)，autoCommit都为True。如果出现异常，使用session.rollback()回滚事务。 二. 新增 在PeopleMapper.xml中使用 <insert> 标签 <insert id="ins" parameterType="people"> insert into people values(default,#{name},#{age}) </insert> 测试类 try { int index =

视图 视图概念 视图是存储的查询语句,当调用的时候,产生结果集,视图充当的是虚拟表的角色。其实视图可以理解为一个表或多个表中导出来的表，作用和真实表一样，包含一系列带有行和列的数据 视图中，用户可以使用SELECT语句查询数据，也可以使用INSERT，UPDATE，DELETE修改记录，视图可以使用户操作方便，并保障数据库系统安全，如果原表改名或者删除则视图也失效。 视图操作 创建视图 语法结构： CREATE [ OR REPLACE ] VIEW [ view_name ] AS [ SELECT_STATEMENT ] ; 释义： CREATE VIEW ： 创建视图 OR REPLACE : 可选，如果添加原来有同名视图的情况下会覆盖掉原有视图 view_name ： 视图名称 SELECT_STATEMENT ： SELECT 语句 e . g . create view c1 as select name , age from class_1 ; 视图表的增删改查操作 视图的增删改查操作与一般表的操作相同，使用insert update delete select即可，但是原数据表的约束条件仍然对视图产生作用。 删除视图 drop view [IF EXISTS] 视图名； IF EXISTS 表示如果存在，这样即使没有指定视图也不会报错。 drop view c1 ;