数据库事务使用方法？

一个大型、稳健、成熟的分布式系统的背后，往往会涉及众多的支撑系统，我们将这些支撑系统称为分布式系统的基础设施。除了前面所介绍的分布式协作及配置管理系统ZooKeeper,我们进行系统架构设计所依赖的基础设施，还包括分布式缓存系统、持久化存储、分布式消息系统、搜索引擎，以及CDN系统、负载均衡系统、运维自动化系统等，还有后面章节所要介绍的实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。

分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显著提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID *** 作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等 *** 作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。

当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。

事务是一系列的数据库 *** 作，是数据库应用程序的基本逻辑单元，也是恢复和并发控制的基本单位。事务处理技术主要包括数据库恢复技术和并发控制技术。本篇博文主要总结下并发控制技术。

事务：是用户定义的一个数据库 *** 作序列，这些 *** 作要么全做，要么全不做，是一个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。一般来说，一个程序中包含多个事务。

ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：

A:原子性(Atomicity): 事务是一个或多个行为捆绑在一起组成一个单独的工作单元,事务中的动作要不都发生,要不都不发生。

C:一致性(Consistent): 即在事务开始之前和结束之后,数据库的完整性约束没有被破坏。

　数据库层面:在一个事务执行前和执行后,数据会符合你设置的约束(例如unique约束,foreign key约束,check约束等)和触发器设置.由数据库进行保证.

事务的使用场景是很广泛的，举个简单的例子

有个买东西的网站，你下单买了某个货品，那么数据库中的订单表会插入一条你下单的记录，同时货物表需要把你所购买货品的数量进行更新，候新增订单和更新货品数量必须是一致的，不应该出现有人下了单但是货品数量不变，也不应该货品数量减少了而订单却没有新增这种情况发生

那么插入订单信息和更新货品数量就是一个完整的事务，要么都执行成功，如果两个 *** 作中有任意一个 *** 作失败，则整个流程就应该是失败的，已经执行的 *** 作就应当回滚

在数据库中使用事务，可以保证多个数据库 *** 作的一致性

这就是一个简单的事务的使用场景

---