关于事务的问题，我们就不多解释了，以后在学习 MySQL 的相关内容时再深入的了解。今天我们主要是对 PDO 中操作事务的一些小测试，或许能发现一些比较好玩的内容。
当然毕竟才刚开始接触事务，所以我给自己留了条后路，说明自己学识有限，肯定有忽视的地方，还得多多学习。
结合过去几天我自己的采访，我列出了一些php面试题，并根据我自己的意见基本上回答了这些问题。 请指出错误的地方，与您讨论和分析，并希望在面试过程中能帮助到你
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。
原文链接：https://www.jianshu.com/p/8d735db9c2c0
事务具有四个特征：原子性( Atomicity )、一致性( Consistency )、隔离性( Isolation )和持续性( Durability )。这四个特性简称为 ACID 特性。
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作读某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。
我们的数据库一般都会并发执行多个事务，多个事务可能会并发的对相同的一批数据进行增删改查操作，可能就会导致我们说的脏写、脏读、不可重复读、幻读这些问题。 这些问题的本质都是数据库的多事务并发问题，为了解决多事务并发问题，数据库设计了事务隔离机制、锁机制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。接下来，我们会深入讲解这些机制，让大家彻底理解数据库内部的执行原理。
朋友的这个问题真的很无语，可能会出现在使用 SVN 的情况下，使用 Git 进行团队开发忽略以后是不会出现这种问题的
事务就是对一系列的数据库操作进行统一的提交或回滚操作，比如说做一个转账功能，要更改帐户两边的数据，这时候就必须要用事务才能算是严谨的做法。要么成功，要么失败，保持数据一致性。如果中间有一个操作出现异常，那么回滚之前的所有操作。 这样有什么好处呢。 这样可以防止在一些意外(例如说突然断电)的情况下出现乱数据，防止数据库数据出现问题。这边加了钱，那边却还是一样的数，这就完了。要是开放一个网上交易的平台，这样就会出大问题的！ 还有其他的一些操作，像是要添加多条数据，如果程序要求必须全部正确才能插入的话，事务
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算，分布式存储，分布式数据库等。
如果有分布式事务协议，那么每个软件工程师都知道它：“两阶段提交”，也称为2PC。尽管使用了几十年，但是由于缺乏云环境的支持，它却一直在稳步下降。 过去在相当长的一段时间里，它是构建企业分布式系统的实际标准。也就是说，随着云成为默认的部署模型，设计人员需要学习如何在没有云的情况下构建可靠的系统。 回答如何替换2PC的问题首先需要了解协议的含义。尽管它曾经很受欢迎，但围绕2PC仍存在许多误解。这篇文章旨在澄清其中至少一些。 2PC不提供“事务” 2PC是原子提交协议，这意味着如果所有参与者都投票“是”，则所有参与者最终都将提交，否则将使系统保持不变。当用户触发了提交操作完成后，要么应用了所有本地修改，要么都没有应用。提交可能要花很长时间才能完成，在某些失败情况下，它将永远挂起。 让我们看一个例子，看看“不提供事务”的含义。在我们的场景中，我们有两个参与者：数据库和消息队列。该图显示了两个参与者都投票“是”并且协调者正在提交。
数据库事务（简称:事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。事务的使用是数据库管理系统区别文件系统的重要特征之一。
PostgreSQL中的存储过程不支持使用savepoint、rollback to。原因是PG的存储过程中，异常处理使用子事务来实现的，也就是一旦发生异常，当前procedure的begin块中执行过的所有语句都会直接回滚：
用户定义了一系列执行SQL语句的操作，这些操作要么完全的执行，要么全部都不执行，他是一个不可分割的工作执行单位，这也是为了保证数据库的完整性。MySQL 事务主要用于处理操作量大，复杂度高的数据。
事务是由几个读取和修改数据的sql命令组成的，但是知道commit命令被执行之后，修改操作才被认为是正常的完成。显式事务常以Begin tran语句开头，以commit tran或者rollback tran语句结尾的。
PDO::commit提交一个事务(PHP 5 = 5.1.0, PECL pdo = 0.1.0)
sys.dm_db_wait_stats 返回在操作期间执行的线程所遇到的所有等待的相关信息。 可以使用此聚合视图来诊断 Azure SQL Database 以及特定查询和批处理的性能问题。 执行查询期间的特定等待时间类型可以说明查询中存在瓶颈或失效点。 同样，如果服务器级的等待时间较长或等待计数较多，说明服务器实例内交互查询交互中存在瓶颈或热点。 例如，锁等待指示查询争用数据；页 IO 闩锁等待指示 IO 响应时间较慢；页闩锁更新指示表示文件布局不正确。 列名 数据类型 说明 wait_type nva
数据库相对于其它存储软件一个核心的特征是它支持事务，所谓事务的ACID就是原子性，一致性，隔离性和持久性。其中原子性，一致性，持久性更多是关注单个事务本身，比如，原子性要求事务中的操作要么都提交，要么都不提交；一致性要求事务的操作必须满足定义的约束，包括触发器，外键约束等；持久性则要求如果事务成功提交了，无论发生什么异常，包括进程crash，主机掉电等，都应该确保事务不会丢失。而隔离性，则关注的是多个事务之间的并发。
•插入操作使用的API是sqlSession.insert(“命名空间.id”,实体对象);
假设系统中有3个服务，分别是订单服务、账户服务、库存服务，用户在下一个订单之后会扣除用户的余额，同时扣减库存容量。在这样的场景下扣款和扣库存需要强一致性保证。就可能会使用到分布式事务解决方案。
对MySQL数据库中的事务操作、存在的问题和相应的隔离级别等知识点进行整理，通过实例进行说明
提问： 事物的概念什么是脏读？不可重复读 为什么需要锁？ 因为数据库要解决并发控制问题。在同一时刻，可能会有多个客户端对Table1.rown进行操作，比如有的在读取该行数据，其他的尝试去删除它。为了保证数据的一致性，数据库就要对这种并发操作进行控制，因此就有了锁的概念。 锁的分类 从对数据操作的类型（读\写）分 读锁（共享锁）：针对同一块数据，多个读操作可以同时进行而不会互相影响。 写锁（排他锁）：当当前写操作没有完成前，它会阻断其他写锁和读锁。 从锁定的数据范围分 表锁 行锁 为了尽可能提高数据库的并发
动态管理视图 sys.dm_os_wait_stats 返回执行的线程所遇到的所有等待的相关信息。可以使用该聚合视图来诊断 SQL Server 以及特定查询和批处理的性能问题。 列名数据类型说明 wait_type nvarchar(60) 等待类型的名称。 waiting_tasks_count bigint 该等待类型的等待数。该计数器在每开始一个等待时便会增加。 wait_time_ms bigint 该等待类型的总等待时间（毫秒）
大家好！近来，我在开发一个 Go 模块时，遇到了一个分布式系统中的常见问题：如何保证跨多个系统的操作能同时成功或同时失败？今天，我们就一起来探讨其中一个重要的解决方案——两阶段提交（Two-Phase Commit，2PC）。
脏读就是指当一个事务T1正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务T2也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据(Dirty Data)，依据脏数据所做的操作可能是不正确的。
在并发的场景中，为了保证数据的一致性我们会在数据库中使用事务。然而在强一致性与性能上则需要根据具体业务来取舍，所以一般数据库提供了四种事务隔离级别： 读未提交（Read Uncommitted） 读提交（Read Committed） 可重复读（Repeatable Read） 序列化（Serializable） 由于日常工作中使用事务比较频繁，遂在此作一下总结 在了解这四种事务隔离级别之前，需要了解如下概念： 更新丢失（Lost Update）: 两个事务同时修改一行数据，其中一个事务的更新被另外一个事
随着分布式架构理念提出，软件系统架构开始迈入一个新时代。一个臃肿的应用会拆分出若干个微服务中心，按业务域维度划分系统边界，大家各司其职，在自己负责的领域深耕细作，可谓好处多多。但同时也增加了系统复杂度，每个子业务系统都涉及数据库操作，如何解决分布式事务是一个绕不开的话题。
首先要和大家说的就是大名鼎鼎的CAP理论与BASE理论了，这两个理论与解决分布式事务问题是密切相关的。
转载自 https://blog.csdn.net/lizhen1114/article/details/80110317
在单个数据库实例时候，我们可以在一个数据源的事务（本地事务）内做多步数据库操作，在事务内的多个操作要么全部执行生效，要么全部不生效。在多数据实例节点时候，我们对多个实例的数据源进行操作时候就没办法把多个操作放到一个大的事务内来管理了，因为多个实例操作的是不同的数据源，而数据库自带的事务是针对单个数据源来说的。
分布式事务就是一个业务操作，是由多个细分操作完成的，而这些细分操作又分布在不同的服务器上，事务，就是这些操作要么全部成功执行，要么全部不执行。分布式事务用于在分布式系统中保证不同节点之间的数据一致性。
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。
事务在一般情况下都是指代数据库事务，它是由系统对数据进行访问和更新的操作所组成的一个逻辑单元，具备原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）、持久性（ Durability ）四大特征，用来确保无论发生什么情况数据都处在一个合理的状态，在日常开发过程中能够不需要考虑网络波动、服务器宕机等问题。所以从某种角度来看，事务是用来服务应用层的。
pdo连接数据库的有点是能实现不同数据库之间的转换，而且有事务功能的回滚，更有pdo::prepare();pdo:::execute()函数的预处理查询,所以我个人认为pdo的功能还是比较强大的，所有这篇日志只为我自己而写，希望看到这篇日志的兄弟们能对你们有所帮助。
在开发中，为了降低单点压力，通常会根据业务情况进行分表分库，将表分布在不同的库中（库可能分布在不同的机器上）。在这种场景下，事务的提交会变得相对复杂，因为多个节点（库）的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个不同的数据库实例中保证。比如更新db1库的A表时，必须同步更新db2库的B表，两个更新形成一个事务，要么都成功，要么都失败。 那么我们如何利用MySQL实现分布式数据库的事务呢？
在写一篇之前说一下TCC模型，即try confirm cancel（尝试---->提交---->回滚）,tcc模型是一个非常典型的2pc（二阶段）提交，所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。
insert into account values (null,'jack',10000);
基于驱动： 1、安装扩展 php_pdo.dll 2、安装驱动 php_pdo_mysql.dll
总所周知 ， innodb 的日志是二阶段提交的，redolog 先在 prepare 阶段写入， binlog 再写入，最后 redolog commit
MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。它采用了 NDB Cluster 存储引擎，允许在 1 个群集中运行多个 MySQL 服务器。初步掌握MySQL集群原理是我们学习MySQL集群要迈出的第一步。
PDO::rollBack — 回滚一个事务(PHP 5 = 5.1.0, PECL pdo = 0.1.0)
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
