事务

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

三级封锁协议 一级封锁协议 事务修改数据时必须加 X 锁，直到事务结束才释放锁。 可以解决丢失修改问题，因为不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。 二级封锁协议 在一级的基础上，要求读取数据时必须加 S 锁，读取完马上释放 S 锁。 可以解决读脏数据问题，因为如果一个事务在对数据进行修改，根据一级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。 三级封锁协议 在二级的基础上，要求读取数据时必须加 S 锁，直到事务结束了才能释放 S 锁。 可以解决不可重复读的问题，因为读数据时，其它事务不能对该数据加 X 锁，从而避免了在读的期间数据发生改变。 来源： CSDN 作者： 喵了个咪的回忆丶 链接： https://blog.csdn.net/dl674756321/article/details/103743760

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

PXC简介： galera产品是以galera cluster方式为mysql提高高可用集群解决方案的。galera cluster就是集成了galera插件的mysql集群。galera replication是codership提供的mysql数据同步方案，具有高可用性，方便扩展，并且可以实现多个mysql节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。 PXC属于一套近乎完美的mysql高可用集群解决方案，相比那些比较传统的基于主从复制模式的集群架构MHA和MM+keepalived，galera cluster最突出特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们相互的关系是对等的。本身galera cluster也是一种多主架构。galera cluster最关注的是数据的一致性，对待事物的行为时，要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证MySQL集群的数据一致性； 对galera cluster的封装有两个，虽然名称不同，但实质都是一样的，使用的都是galera cluster。一个MySQL的创始人在自己全新的MariaDB上实现的MAriaDB cluster；一个是著名的MySQL服务和工具提供商percona实现的percona

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

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 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 中，比如以下这些操作： 你插入一条记录时

更多内容关注公众号：SAP Technical 各位可以关注我的公众号：SAP Technical 第一种最简单的方法就是右键任务栏——结束会话。 第二种也很简单，就是点击左上角的小图标——停止事务。 第三种则是利用事务代码SM50——选中条目——菜单“管理”——删除会话。 至于网上所说利用SM12踢出用户所执行的程序，这个仅仅用于对象被锁住的情况。 第四种还是利用事务代码SM04——工具栏“会话”——删除会话。 第五种还是利用事务代码SM66，同SM50类似。 其他的欢迎补充。 来源： CSDN 作者： SAPmatinal 链接： https://blog.csdn.net/SAPmatinal/article/details/103948364

在数据库工具类编写的过程中，对事务的处理操作想避免各个原子操作的事务对象赋值重复操作，想对外暴露的方法为如下形式 public bool ExecuteTransition(Action TransitionAction, out string ExceptionStr) 外部传入的数据库操作都使用委托统一打包，内部进行事务操作。我们首先需要明白的是，数据库事务操作在ADO.NET的编码中的体现是，DbConnection为同一个，DbCommand的Transaction为同一个。 ​ 首先我们需要识每一个数据库操作的上下文，是否在TransitionAction这个委托中，为了简单明了，在执行TransitionAction时开启一个Task，取得当前线程的ThreadID作为这个事务委托的唯一标识，并生成一个DbTransaction放入一个TransactionDic中，在SqlHelper执行类中执行SQL语句创建Connection时，取得当前的ThreadID去TransactionDic中查找，如果有对应的Transition则说明该SQL语句的执行是在一个事务中，Connection直接取Transition的数据库连接，并给DbCommand的Transition对象赋值 ​

Controller层 @Controller ：与 @Component 一样声明为Spring的Bean，同时标志为Spring的Controller类。 @ResponseBody :不经过视图处理器，直接将Java对象转换为json数据输出到前端 @RestController : @Controller 和 @ResponseBody 的功能混合 @RequestBody : 一般Post请求使用 将HTTP输入流中的数据装配到目标类中，会根据json字符串中的key来匹配对应实体类的属性，如果匹配一致且json中的该key对应的值符合，则会调用用实体类的setter方法赋值。 json中，如果key对应的value为“ ”的话，实体类属性为String，则为“ ”，如果是Integer、Doublie属性的话，为null @PathVariable : 用于请求中的占位符映射 @RequestParam : 将请求参数绑定到方法参数上 value：参数名 required：是否包含该参数，默认为true，表示该请求路径中必须包含该参数，如果不包含就报错。 defaultValue：默认参数值，如果设置了该值，required=true将失效，自动为false,如果没有传该参数，就使用默认值 @ModelAttribute 在方法上 添加注解，会在 所有带有