数据库事务

事务是定义一系列操作在逻辑上可以看成一个完整的操作，具有ACID特性； Atomicity (原子性) 　　要求事务中所有的操作要么全部完成，要么全部没有发生，如果部分操作失败，则整个事务操作都会失败。 Consistency (一致性) 　　要求事务中的操作，符合容器(如：数据库)的各种规则，保证数据是合法、与规定好的方式运行，一般通过原子性来保证，数据在事务中会有各种状态，但是结果必须需要语义。 　　与原子性强调开始/结束状态不一样，一致性强调的是在事务过程中数据状态的不稳定，其他事务是不可见的。(隔离级别会有一些妥协) Isolation (隔离性) 　　事务与事务间不会相互影响，就像串行执行一样，相互之间并行时是不可见的。 Durability (持久性) 　　事务完成后，数据状态就保持不变，永久存储。 目前大致有两种比较流行的技术来实现事务： 预写日志(WAL)和影子分页(SP) 。 预写日志(write-ahead logging) ，主要提供ACID中的 原子性和持久性 两种特性的操作： 　　日志分为redo和undo信息， 　　undo用于记录修改前的信息，redo用于记录修改后的信息；undo可用于做事务失败的回滚操作，redo可用于做事务提交过程中故障恢复。log文件一般采用追加的方式，I/O效率高。 　

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

原文： http://skaka.me/blog/2016/04/21/springcloud1/ 不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一种方法同样可以解决分布式事务问题, 并且性能较好, 这就是我这篇文章要介绍的使用事件,本地事务以及消息队列来实现分布式事务. 我们从一个简单的实例入手. 基本所有互联网应用都会有用户注册的功能. 在这个例子中, 我们对于用户注册有两步操作: 1. 注册成功, 保存用户信息. 2. 需要给用户发放一张代金券, 目的是鼓励用户进行消费. 如果是一个单一架构应用, 实现这个功能非常简单: 在一个本地事务里, 往用户表插一条记录, 并且在代金券表里插一条记录, 提交事务就完成了. 但是如果我们的应用是用微服务实现的, 可能用户和代金券是两个独立的服务, 他们有各自的应用和数据库, 那么就没有办法简单的使用本地事务来保证操作的原子性了. 现在来看看如何使用事件机制和消息队列来实现这个需求.(我在这里使用的消息队列是kafka, 原理同样适用于ActiveMQ

十三、处理并发 1 、事务的隔离级别 不考虑隔离级别出现的问题： 脏读：一个线程中的事务读到了另外一个线程中未提交的数据。 不可重复读：一个线程中的事务读到了另外一个线程中提交的 update （更新）的数据。 虚读：一个线程中的事务读到了另外一个线程中提交的 insert （插入）的数据。 事务的隔离级别： 1 ： READ UNCOMMITTED: 脏读、不可重复读、虚读（幻读）都可能发生。 2 ： READ COMMITTED: 避免脏读；不可重复读、虚读（幻读）都可能发生。 4 ： REPEATABLE READ: 避免脏读、不可重复读，虚读（幻读）可能发生。 8 ： SERIALIZABLE: 避免脏读、不可重复读、虚读（幻读）。 通过配置参数 hibernate.connection.isolation=1|2|4|8 进行设置。 MySQL ：默认 4 Oracle ：默认 2 2 、第二类更新丢失 1 //线程1 2 @Test 3 public void test1(){ 4 Session s = HibernateUtil.getSession(); 5 Transaction tx = s.beginTransaction(); 7 Customer c1 = s.get(Customer.class, 1); 8 c1.setName("泰斯特"); 9

原子性（Atomicity） 　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 持久性（Durability） 　　持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。 　　例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交

Hibernate实现悲观锁和乐观锁。 1，悲观锁 用例代码如下： 数据库DDL语句： hibernate.cfg.xml java类 以上代码（除下面的main之外）同乐观锁。 main 1 package a3_Version; 2 import org.hibernate.LockOptions; 3 import org.hibernate.Session; 4 import daoUtil.HibernateUtil; 5 6 public class Test_pessiLock { 7 8 public static void main(String[] args) { 9 Session session = HibernateUtil.getSession(); 10 11 try { 12 Cat cat = (Cat)session.get(Cat.class, "8a6cc5a34c54de57014c54de588e0000", LockOptions.UPGRADE); 13 14 System.out.println("这行设置断点，到数据库"); 15 System.out.println("使用SQL:select * from CAT t WHERE T.ID='"+cat.getId()+"' FOR UPDATE"); 16 System

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如

说到数据库，那就一定会聊到事务，事务也是面试中常问的问题，我们先来一个面试场景： 面试官:"事务的四大特性是什么?" 我:"ACID，即原子性(Atomicity)、隔离性(Isolation)、持久性(Durability)、一致性(Consistency)！" 面试官:"在 MySQL 数据库的 InnoDB 引擎是怎么实现这四大特性的？" 我:"这个...这个....，还真没有了解过哎" 面试官:"那我们就先这个吧，先回去吧，我们会通知你的~" 这可能是比较常见的面试场景了，你也许回答到了事务的四大特性，但是不一定知道他的实现原理。今天我们就来一起打卡事务的四大特性和实现原理，对于原理的实现，这篇文章只是粗略的介绍一下，更多的细节可以关注我后续的文章。 数据库的事务有四大特性： 原子性、隔离性、永久性、一致性 ，下面将介绍这四大特性的定义和在 InnoDB 引擎中是怎么实现的。 原子性 定义 一次操作是不可分割的，要么全部成功，要么全部失败。比如我们的转账操作，不允许出款方成功，收款方失败这种情况，要么都成功，要么多失败，不可能出现中间状态。 实现 InnoDB 引擎使用 undo log（归滚日志）来保证原子性操作 ，你对数据库的每一条数据的改动（INSERT、DELETE、UPDATE）都会被记录到 undo log 中，比如以下这些操作： 你插入一条记录时

什么是事务 事务时包含1条或多条语句的逻辑单元。事务中的语句是一个整体，要么一起提交，要么一起撤销。事务在提交前可以回滚，一旦提交就不能撤销修改了，是永久性的修改。 为什么使用事务 可以例举生活中的例子，比如银行转账：A向B转100万。程序的执行顺序：1.A账户减掉100万 2.B账户增加100万。若是都成功执行倒没什么，假设1成功执行，2执行失败，就会出问题。运用事务就不会出现这种问题，因为只要其中有一步操作失败，事务就会回滚，之前的所有操作将会被撤销。 事务的基本控制语句 1.BEGIN TRANSACTION:事务开始 2.COMMIT TRANSACTION:事务提交 3.ROLLBACK TRANSACTION:事务回滚 事务的特性（ACID） 1.ATOMIC（原子性）：事务中程序是数据库的逻辑工作单元，对数据的修改要么全执行，要么全不执行。 2.CONSISTENT（一致性）：事务执行前后数据一致，事务完成之后数据的修改才可见。 3.ISOLATED（隔离性）：并发事务之间不能相互干扰 4.DURABLE（持久性）：事务一旦提交就是对数据的永久修改。 下面是一个包含事务的存储过程的例子： 1 ALTER proc [dbo].[Proc_InsertStudent] 2 @stuName nvarchar(50),@stuClassId int,@stuAge int

直接copy知乎上的内容 https://www.zhihu.com/question/51513268 作者：尹发条地精 链接：https://www.zhihu.com/question/51513268/answer/127777478 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 ①在mysql中有表锁， LOCK TABLE my_tabl_name READ; 用读锁锁表，会阻塞其他事务修改表数据。 LOCK TABLE my_table_name WRITe; 用写锁锁表，会阻塞其他事务读和写。 ②Innodb引擎又支持行锁，行锁分为 共享锁，一个事务对一行的共享只读锁。 排它锁，一个事务对一行的排他读写锁。 ③这两中类型的锁共存的问题 考虑这个例子： 事务A锁住了表中的 一行 ，让这一行只能读，不能写。 之后，事务B申请 整个表 的写锁。 如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。 数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。 数据库要怎么判断这个冲突呢？ step1：判断表是否已被其他事务用表锁锁表 step2：判断表中的每一行是否已被行锁锁住。 注意step2，这样的判断方法效率实在不高，因为需要遍历整个表。 于是就有了意向锁。 在意向锁存在的情况下