事务

使用django.db中的transaction from django.db import transaction 此库封装了一个方法atomic() 包含开启事务，回滚和提交 1使用transaction需在settings数据库设置定义如下，表示使用全局事务,相当于一个排它锁 'ATOMIC_REQUESTS':True 2 在views视图文件中不使用事务的方法加上装饰器,表示不使用事务 @transaction.non_atomic_requests 3 在需要使用事务的位置调用atomic()方法 with transaction.atomic(): order.save() 来源： CSDN 作者： qq_29507011 链接： https://blog.csdn.net/qq_29507011/article/details/104066050

1、查询长时间不返回： 在表 t 执行下面的 SQL 语句： mysql> select * from t where id=1; 查询结果长时间不返回。 一般碰到这种情况的话，大概率是表 t 被锁住了。接下来分析原因的时候，一般都是首先执行一下 show processlist 命令，看看当前语句处于什么状态。然后我们再针对每种状态，去分析它们产生的原因、如何复现，以及如何处理。等 MDL 锁如下图所示，就是使用 show processlist 命令查看 Waiting for table metadata lock 的示意图。 出现这个状态表示的是，现在有一个线程正在表 t 上请求或者持有 MDL 写锁，把 select 语句堵住了。 不过，在 MySQL 5.7 版本下复现这个场景，也很容易。如图 3 所示，我给出了简单的复现步骤。 session A 通过 lock table 命令持有表 t 的 MDL 写锁，而 session B 的查询需要获取 MDL 读锁。所以，session B 进入等待状态。这类问题的处理方式，就是找到谁持有 MDL 写锁，然后把它 kill 掉。但是，由于在 show processlist 的结果里面，session A 的 Command 列是“Sleep”，导致查找起来很不方便。不过有了 performance_schema 和

1、 消息队列应用场景 异步处理、应用解耦、流量削峰、日志收集、事务最终一致性等 服务雪崩： 一个基础服务不可用，导致整个系统不可用。 流量削峰：将短时间的流量持久化，然后逐步处理 事务最终一致性： 处理分布式事务的规范： XA XA主要定义了全局事务管理器和局部事务管理器之间的接口；但是XA性能不高。 如何保证分布式事务的一致性呢？ 引入事件表 2、消息队列功能支持 消息发送、接收和暂存 解决消息堆积、消息持久化、可靠投递、消息重复、严格有序、集群等问题 严格有序： 创建订单、支付完成、已发货、已收货、订单完成等环节； 需按照顺序消费消息， 否则就不对； 来源： CSDN 作者： jupiter_888 链接： https://blog.csdn.net/jupiter_888/article/details/104060292

性能调优系列前序文章索引： 程序员必须掌握的性能调优 ：老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，以及介绍了从 X、Y、Z 三个维度优化性能的思路。 从 X 维度优化系统的性能 ：老兵哥分享了从 X 维度优化系统性能的思路，包括让客户端分计算存储任务、优化交互设计等，主要是作为引子拓宽我们性能调优的思路。 应用容器 Tomcat 性能调优 ：Y 维度就是从业务 HTTP 请求的横向处理流程来看，HTTP 请求会穿越网络、计算机、应用容器（Tomcat）、Spring、ORM（Hibernate）、数据库等节点，在这个流程中每个节点都有许多可以可优化的地方，此文主要介绍通过优化应用容器（Tomcat）来优化系统性能的方法。 程序员在转型架构师的过程中需要建立流程化、结构化、系统化的思维方式，而性能调优是非常难得的契机，它既给了我们压力，也给了我们动力，跨越它就是突破自己的过程。建议在阅读本文内容前，先参考下面这个系列的文章了解 Web 应用是怎样处理 HTTP 请求的： 图解 Spring：HTTP 请求的处理流程与机制【1】 图解 Spring：HTTP 请求的处理流程与机制【2】 图解 Spring：HTTP 请求的处理流程与机制【3】 图解 Spring：HTTP 请求的处理流程与机制【4】 图解 Spring：HTTP 请求的处理流程与机制

MyISAM是MySQL的默认数据库引擎（5.5版之前），由早期的ISAM（Indexed Sequential Access Method：有索引的顺序访问方法）所改良。虽然性能极佳，但却 有一个缺点：不支持事务处理（transaction） 。不过，在这几年的发展下，MySQL也导入了InnoDB（另一种数据库引擎），以强化参考完整性与并发违规处理机制，后来就逐渐取代MyISAM。 InnoDB，是MySQL的数据库引擎之一，为MySQL AB发布binary的标准之一。InnoDB由Innobase Oy公司所开发，2006年五月时由甲骨文公司并购。与传统的ISAM与MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事务（Transaction）功能，类似于PostgreSQL。目前InnoDB采用双轨制授权，一是GPL授权，另一是专有软件授权。 MyISAM和InnoDB两者之间有着明显区别，简单梳理如下: 1) 事务支持 MyISAM不支持事务，而InnoDB支持。InnoDB的AUTOCOMMIT默认是打开的，即每条SQL语句会默认被封装成一个事务，自动提交，这样会影响速度，所以最好是把多条SQL语句显示放在begin和commit之间，组成一个事务去提交。 MyISAM是非事务安全型的，而InnoDB是事务安全型的，默认开启自动提交，宜合并事务，一同提交

回到目录 相关文章 将不确定变为确定~transactionscope何时提升为分布式事务 将不确定变为确定~transactionscope何时提升为分布式事务~续 将不确定变为确定~transactionscope何时提升为分布式事务~再续（避免引起不必要的ＭＳＤＴＣ） 对于frameworks的TransactionScope大家应该都很熟悉了，它是一个分布式事务的语句块，被包含起来的语句可以一起被提交，当出现异常后，统一进行回滚，这一切都是托管的。 当ＷＥＢ服务器没有开启ＭＳＤＴＣ服务时，会出现这个提示： 对于servers.msc中的ＭＳＤＴＣ服务，它经常性的被挂掉 注意一下：如果你的msdtc服务挂了，当下一次WWW程序需要用到它时，它会自由重启。 而对于你的事务块，如果这个ＭＳＤＴＣ服务被挂了后，如果你的事务块中包含“跨库”操作，它将会被自动提升到ＭＳＤＴＣ分布式事务， 这时你整个代码块将会中断，并抛出你的异常！ 1 public abstract class DAL<T> : IDAL<T> where T : class 2 { 3 4 public DAL(DbContext db) 5 { 6 DB = db; 7 } 8 9 10 #region Properies 11 /// <summary> 12 /// 静态上下文 13 /// </summary

一、QPS/TPS QPS：Queries Per Second的缩写，意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS： Transactions Per Second的缩写，也就是事务数/秒（每秒处理的事务数）。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 TPS即每秒处理事务数，包括了 用户请求服务器 服务器自己的内部处理 服务器返回给用户 这三个过程，每秒能够完成N个这三个过程，TPS也就是N； QPS基本类似于TPS （有时候也会把两者当成一个），但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。 例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q” 二、系统吞吐量 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）

一、Mysql的四个隔离级别 预备工作： 先创建一个test数据库及account表， create database test;use test; create table account( id int not null, balance float not null, PRIMARY KEY ( id) ) 向account中插入两条测试数据 INSERT INTO table(id,balance) VALUES (1,1000); INSERT INTO table(id,balance) VALUES (2,1000); 　　 开启两个控制台窗口，当做两个用户（A和B） 1.1 READ UNCOMMITTED（未提交读） 也即RU，在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 A用户操作如下： set session transaction isolation level read uncommitted; start transaction; select * from

①:hibernate对自动提交默认为false，必须加入事务手动提交，也可以在hibernate配置文件中加入属性connection.autocommit并设置为true（不推荐这样），这样不加入事物也可以自动提交，在没有设置改属性之前，如果不加入事物，即使调用session.flush()，数据也不能插入数据库。 ②: Hibernate中的save方法 有事务的情况下： save方法执行时，并没有真正的去执行一条insert语句，而是仅仅从数据库中获取下一个id，并赋值给domain对象，获取当时domain对象信息的一个快照，计划执行一条insert语句，然后在事务提交时才会去真正执行该语句，在真正执行前，如果你向数据库中插入一条记录，该记录则会使用下一个id，即domain对象虽然还没有数据库插入，但是已经占据一个id了。执行完该insert语句后会发现当前的domain对象和已经持久化的domain对象是不一致的，然后就需要执行一次update语句。 没有事务的情况下： save方法在没有事务的情况下，仍然计划执行一条insert语句，同时从数据库中获取一个可用id，虽然最终没有insert，但是此id已被占用。 总结：当使用save方法插入数据的时候，真正把数据持久化到数据库其实执行的是update语句。 来源： CSDN 作者： Dug_Zhang 链接：

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring