事务管理

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

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

视图 视图概念 视图是存储的查询语句,当调用的时候,产生结果集,视图充当的是虚拟表的角色。其实视图可以理解为一个表或多个表中导出来的表，作用和真实表一样，包含一系列带有行和列的数据 视图中，用户可以使用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 ;

分布式事务Saga (一) TCC vs Saga 分布式事务Saga（二）事务管理者SagaTransactionalAspect 分布式事务Saga（三）事务参与方管理SagaParticipantAspect 分布式事务Saga（四）事务恢复SagaRecoveryManager 文章目录 TCC流程 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 saga 正常流程图 saga 异常流程图 结论 项目地址： https://github.com/yangxb2010000/saga 该项目的实现本质上说不是一个严格意义上的Saga实现，更像是一个简化版的TCC事务 先对比一下Saga与TCC的区别 TCC流程 Try 预留资源 （如：库存服务的预占库存，支付服务的冻结部分账户余额） Confirm 如果所有的事务参与者try 操作都执行成功了，就会调用所有事务参与者的confirm操作，确认资源。（如：库存服务的减库存，支付服务的扣减账户余额） Cancel 如果有事务参与者在try阶段执行失败，就调用所有已执行try阶段成功的参与方的cancel方法，释放try阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额） ####正常逻辑时序图 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 confirm 直接执行资源操作，（如

1 、 @Entity(name="EntityName") 必须 ,name 为可选 , 对应数据库中一的个表 2 、 @Table(name="",catalog="",schema="") 可选 , 通常和 @Entity 配合使用 , 只能标注在实体的 class 定义处 , 表示实体对应的数据库表的信息 name: 可选 , 表示表的名称 . 默认地 , 表名和实体名称一致 , 只有在不一致的情况下才需要指定表名 catalog: 可选 , 表示 Catalog 名称 , 默认为 Catalog(""). schema: 可选 , 表示 Schema 名称 , 默认为 Schema(""). 3 、 @id 必须 @id 定义了映射到数据库表的主键的属性 , 一个实体只能有一个属性被映射为主键 . 置于 getXxxx() 前 . 4 、 @GeneratedValue(strategy=GenerationType,generator="") 可选 strategy: 表示主键生成策略 , 有 AUTO,INDENTITY,SEQUENCE 和 TABLE 4 种 , 分别表示让 ORM 框架自动选择, 根据数据库的 Identity 字段生成 , 根据数据库表的 Sequence 字段生成 , 以有根据一个额外的表生成主键 , 默认为AUTO generator:

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 掌握了JDBC最基本的与数据库交互后，接下来，我们要修炼进阶篇了，此篇涉及大量的专业名词，需要有一定天赋的修行者修炼，不过，我相信，能够轻松通过第一篇的你，绝对是那个骨骼精奇，天资聪慧的修行者~那么，我们进入此次的修行把---JDBC的事务管理 事务：在一个业务场景中，保持一系列操作的整体性，我们称作事务~简单来讲，在一系列的操作中，要么，所有操作都生效，要么所有操作都不生效，不存在某些操作生效，某些操作不生效的情况。举个例子~业务场景：小鱼儿转10定金子给花无缺；涉及的操作：1.钱从小鱼儿的兜里转出~2.钱转入到花无缺的兜中~，两个操作缺一不可，如果操作1在途中受阻，那么钱就会回到小鱼儿的兜中，只有这样，才能保证我业务操作的完整性。 事务的特性： 1、原子性（atomicity）：组成事务的语句形成了一个逻辑单元，不能只执行一部分； 2、一致性（consistency）：在事务处理执行前后，数据库与理论值是一致的（数据库完整性约束）； 3、隔离性（isolcation）：一个事务处理和另一个事务处理相互间互不影响； 4、持续性（durability）：事务处理的效果能够被永久保存下来。 隔离级别： 1、多线程并发执行可能会产生以下三个问题： 　　脏读（dirtyreads）

原文: MySQL 架构 MySQL架构和结构分析 官方架构图： MySQL DB 各模块架构图如下： MySQL安装方式 MySQL初始化 简介：什么是事务； 事务： ACID ： 事务确保了银行不会弄丢你的钱，而这种特性在应用逻辑设计中是很难实现的，甚至不可实现。一个ACID兼容的数据库服务器，要为事务处理大量的复杂工作确保ACID特性的实现，而这也许是用户未能察觉到的。 事务： ACID ： A ：原子性(Atomicity) ： 一个事务必须被视为一个单独的内部”不可分“的工作单元，以确保整个事务要么全部执行，要么全部回滚。当一个事务具有原子性时,该事务绝对不会被部分执行,要么完全执行，要么根本就不执行。 C：一致性 (consistency)： 数据库总是从一种一致性状态转换到另一种一致性状态。只要是最终事务没有被提交，任何事务处理过程中所做的数据改变，也不会影响到数据库的内容。 I：隔离性 (leolation) ： 某个事务的结 果只有在完成之后才对其它事务可见 D：持久性(durability) ： 一旦一 个事务提交，事务所做的数据改变是永久的。这意味着数据改变已被记录，即使系统崩溃，数据也不会因此丢失，持久性是个有点模糊的概念，因为实际上持久性也分为很多级别。 隔离： 隔离级别 read uncommitted ： 读 未提交内容：在read

核心API 编辑 Hibernate的API一共有6个，分别为: Session 、 SessionFactory 、 Transaction 、 Query 、 Criteria 和Configuration。通过这些 接口 ，可以对持久化对象进行存取、事务控制。 Session Session 接口负责执行被持久化对象的 CRUD 操作(CRUD的任务是完成与数据库的交流，包含了很多常见的SQL语句)。但需要注意的是 Session对象 是非 线程安全 的。同时，Hibernate的 session 不同于JSP应用中的HttpSession。这里当使用session这个术语时，其实指的是Hibernate中的session，而以后会将HttpSession对象称为用户session。 SessionFactory SessionFactory接口负责初始化Hibernate。它充当数据存储源的代理，并负责创建Session对象。这里用到了 工厂模式 。需要注意的是SessionFactory并不是轻量级的，因为一般情况下，一个项目通常只需要一个SessionFactory就够，当需要操作多个数据库时，可以为每个数据库指定一个SessionFactory。 Transaction Transaction 接口是一个可选的API，可以选择不使用这个接口

在 关于分布式事务的理解 一文中，最后留了一个坑是关于TCC框架的。当时由于时间问题耽搁了，最近总算有时间把这个坑填上了。 本文会大致介绍下两阶段和三阶段提交，以及TCC模式。 分布式事务分为 两阶段型 补偿型 异步确保型 最大努力通知型几种 上文我们已近介绍了 异步确保型 和 最大努力通知 这两种服务模式的具体应用，接下来介绍下剩下两种。 两阶段提交（2PC）型 两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。 （注意：若成功这里其实每个参与者已经执行了事务操作） 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功， 则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚

一、前言 　　 在大数据系统中，分布式系统已经成为一个无法避免的组件，如zookeeper已经成为了工业届的标准。所以对于大数据的研究，也必须要研究分布式系统的特点。 二、集中式系统 　　由一台或多台计算机组成的中心节点，数据集中存储在这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。其部署简单，不用考虑多个节点间的分布式协作问题。 三、分布式系统 　　分布式系统是一个由硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点 　　 3.1 分布性 　　分布式系统中的多台计算机都会在空间中随意分布，同时，机器的分布情况也会随时变动。 　 　3.2 对等性 　　分布式系统中的计算机没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的， 副本 指的是分布式系统对数据和服务提供的一种冗余方式，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。 数据副本 是指在不同的节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。 服务副本 是只多个节点提供同样的服务，每个节点都有能力接受来自外部的请求并进行相应的处理。 　 　3.3 并发性 　　同一分布式系统中的多个节点