ディレクトリ
免責事項：この記事はCC 4.0 BY-SAの著作権契約書に従って、Heriamブロガーオリジナル記事です、複製、元のソースのリンクと、この文を添付してください。
オリジナルリンク：https://jiang-hao.com/articles/2019/backend-transactions-acid.html
取引の概要
物事の定義
トランザクション（トランザクション）は、プログラム・オペレーティング・システムによってアクセスまたは実行ロジック（ユニット）からなる一連のデータを更新します。コンピュータ用語では、トランザクションは、通常、データベーストランザクションを指しています。
データベース管理システム（DBMS）において、トランザクションは、基本単位のデータベースの回復と並行性制御です。それは仕事の不可分単位であり、これらの操作はいずれかの実行か実行され、一連の動作です。
たとえば、銀行振込の作業：ソースとターゲットの口座引き落とし口座の助成金から、これら2つの操作がいずれかのすべての実行中または実行されていない、理由もなく量が消滅したことがそうでない状況、または表示されますする必要があります。したがって、我々は、ビジネスとしてそれらが表示されるはずです。
現代のデータベースでは、トランザクションは、例えば、確認してくださいあなたはアクセスできない他の誰かがデータの半分を書いたことを、他のことを達成することができます。しかし、基本的な考え方は同じである-トランザクションを確実にするために使用される何が起こるかに関係なく、あなたのデータが使用されます合理的な状態にあります：
トランザクションは、何が起こるかに関係なく、あなたと仕事のデータが賢明な状態になることを、確認するためにあります。
これは、1つの口座から送金を控除した後の状況を保証しますが、別のアカウントに保存していない場合には表示されません。
取引の目的
データベースのトランザクションは、一般的に、データベースの読み取り/書き込み操作の配列を含みます。それは、次の2つの目的があります。
- データベースの操作の正常配列に故障状態から回復する方法を提供し、データベースはまたさえ依然として異常な状態の場合、コヒーレンシを維持するための方法を提供します。
- ときに、データベースへの同時アクセスのための複数のアプリケーションは、互いの動作との干渉を防止するために、これらのアプリケーション間で分離する方法を提供することができます。
トランザクションがDBMSに送信されると、DBMSは、トランザクションのすべての操作が正常に完了していると、トランザクションがすべての操作で正常に完了しない場合の結果は、データベースに永続的に保存され、トランザクション内のすべての操作をロールバックする必要があることを確認する必要がありますトランザクション実行前の状態に戻り、同時に、トランザクションの実装では、データベースまたは他のトランザクションに影響を及ぼさない、すべてのトランザクションは、別の操作であるかのようです。
彼の「設計データ集約型アプリケーション」でマーティンKleppmannは、本が言及されています。
トランザクションは、自然の法則ではありません。彼らはつまり、データベースにアクセスするアプリケーションのためのプログラミングモデルを簡素化するために、目的で作成されました。データベースは、（我々はこれらの安全の保証を呼び出す）の代わりにそれらの世話をするためのトランザクションを使用することにより、アプリケーションは、特定の潜在的なエラーのシナリオと同時実行の問題を無視して自由です。
実際には、失敗のリスクが高いです。データベース内のトランザクションの実行中に、このようなエラーとして失敗したトランザクション、データベース・システムまたはオペレーティングシステムのエラー、さらには記憶媒体に遭遇することが可能です。上記マーティンの言葉は、事務の存在を理解するために、私たちのプログラミングモデルを簡素化することができるようにすることです、我々は潜在的なエラーと同時実行の問題の多様性を考慮する必要はありません。私たちは実際の取引、データベースを検討する必要がダウンしていない、ネットワークの異常、同時変更やその他の問題を使用すると、トランザクション全体がいずれかの非常に便利な、背中をコミットまたはロールバックされます。だから、本質的に、それはむしろ、データベースシステム自体を要求するのではなく、アプリケーションレベルのサービスの取引に登場しました。
向背
、アクティブなコミットと失敗、業務や実行にステータス、または他の成功か失敗：トランザクションは原子性を持っているので、外部からそれを見て、事務の状態が密接に全体としてリンクされているため、トランザクションはまた、3つしかあり。
さらに拡大し、いくつかの内部のものが見える外ではない、この中間状態を、提出があります。
だから、具体的には、トランザクションは次の可能な状態があります。
- アクティブ：事務の初期状態は、トランザクションが実行されていることを意味します。
- 部分的にコミット：最後の文の実行後、
- 失敗しました：トランザクションの後、通常の検出を実行することはできません。
- 中止された：トランザクションはロールバックされ、データベースは後にその前のトランザクションの状態に復元されます。
- コミット：トランザクション全体の実装を成功。
また、実行後エンドとしてのみコミットまたは中止の状態にそのトランザクションを見ることができます。
トランザクションのACID特性
ACIDはじめに
トランザクションの前と後のデータベースの整合性を維持するために、みんなのACID特性に精通している、特定のプロパティに従います。
- アトミック（原子性）：すなわち不可分、いずれかのトランザクション内のすべての操作が行う、または全部を行いません
- 一貫性（一貫性）：トランザクションの実行前と後に、データベースを満たすために正しい状態になければならない整合性制約を
- 絶縁（アイソレーション）：複数のトランザクションの同時実行、トランザクションを実行するには、他のトランザクションの実行に影響を与えるべきではありません
- 永続性（耐久性）：トランザクションが完了した後に、データの変更はシステム障害が失われることはありません場合でも、永久的です
并非任意的对数据库的操作序列都是数据库事务。ACID属性是一系列操作组成事务的必要条件。总体而言，ACID属性提供了一种机制，使每个事务都”作为一个单元，完成一组操作，产生一致结果，事务彼此隔离，更新永久生效“，从而来确保数据库的正确性和一致性。
原子性（Atomicity）
原子性也被称为“全有或全无规则”。它非常好理解，即整个事务要么完整发生，要么根本不发生，不会部分发生。它涉及以下两个操作：
- 中止：如果事务中止，则看不到对数据库所做的更改。
- 提交：如果事务提交，则所做的更改可见。
拿之前转账的例子来说，用户A给用户B转账，至少要包含两个操作，用户A钱数减少，用户B钱数增加，增加和减少的操作要么全部成功，要么全部失败，是一个原子操作。如下图，如果事务在T1 完成之后但在T2完成之前失败，将导致数据库状态不正确。
一致性（Consistency）
一致性是指，一个事务必须使数据库从一个一致性状态变换到另一个一致性状态（执行成功），或回滚到原始的一致性状态（执行失败）。这意味着必须维护完整性约束，以使在事务之前和之后数据库保持一致性和正确性。
参考上面的示例，假设用户A和用户B两者的钱加起来一共是700，那么不管A和B之间如何转账，转几次账，这一约束都得成立，即事务结束后两个用户的钱相加起来还得是700，这就是事务的一致性。
如果转账过程中，仅完成A扣款或B增款两个操作中的一个，即未保证原子性，那么结果数据如上述完整性约束也就无法得到维护，一致性也就被打破。可以看出，事务的一致性和原子性是密切相关的，原子性的破坏可能导致数据库的不一致。
但数据的一致性问题并不都和原子性有关。比如转账的过程中，用户A扣款了100，而用户B只收款了50，那么该过程可以符合原子性，但是数据的一致性就出现了问题。
一致性既是事务的属性，也是事务的目的。也正如本文开篇所提到的，“事务是用来确保无论发生什么情况，你使用的数据都将处于一个合理的状态“，这里所说的合理/正确，也就是指满足完整性约束。
总的来说，一致性是事务ACID四大特性中最重要的属性，而原子性、隔离性和持久性，都是作为保障一致性的手段。事务作为这些性质的载体，实现了这种由ACID保障C的机制。
ACID和CAP中C（一致性）的区别
请注意，我们一直在讨论的一致性，即ACID中的C，是指单一实体内部的正确状态在时间维度上的一致性，进一步说，是通过维护数据的完整性约束，来保持数据库在时间上（比如事务前后）保持一致的正确状态。因为是描述单一实体的内部状态，故又称“内部一致性”。
而CAP原则中的一致性是指在分布式系统中，空间维度上，某一特定时刻，多个实体中不同数据备份之间值的一致性，又称“外部一致性”。具体我们会在另文CAP原则相关内容中做详细介绍。
隔离性（Isolation）
隔离性是指，并发执行的各个事务之间不能互相干扰，即一个事务内部的操作及使用的数据，对并发的其他事务是隔离的。此属性确保并发执行一系列事务的效果等同于以某种顺序串行地执行它们，也就是要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。这要求两件事:
- 在一个事务执行过程中，数据的中间的（可能不一致）状态不应该被暴露给所有的其他事务。
- 两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
还是拿转账来说，在A向B转账的整个过程中，只要事务还没有提交（commit），查询A账户和B账户的时候，两个账户里面的钱的数量都不会有变化。如果在A给B转账的同时，有另外一个事务执行了C给B转账的操作，那么当两个事务都结束的时候，B账户里面的钱必定是A转给B的钱加上C转给B的钱再加上自己原有的钱。
如此，隔离性防止了多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）。以上4个级别的隔离性依次增强，分别解决不同的问题。事务隔离级别越高，就越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。
持久性（Durability）
事务的持久性又称为永久性（Permanency），是指一个事务一旦提交，对数据库中对应数据的状态变更就应该是永久性的。即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够根据事务日志对未持久化的数据重新进行操作，将其恢复到事务成功结束的状态。持久性意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会因为系统故障而被回滚。（完成的事务是系统永久的部分，对系统的影响是永久性的）
许多数据库通过引入预写式日志（Write-ahead logging，缩写 WAL）机制，来保证事务持久性和数据完整性，同时又很大程度上避免了基于事务直接刷新数据的频繁IO对性能的影响。
在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中。假设一个程序在执行某些操作的过程中机器掉电了。在重新启动时，程序可能需要知道当时执行的操作是成功了还是部分成功或者是失败了。如果使用了WAL，程序就可以检查log文件，并对突然掉电时计划执行的操作内容跟实际上执行的操作内容进行比较。在这个比较的基础上，程序就可以决定是撤销已做的操作还是继续完成已做的操作，或者是保持原样。
总结
事务（Transaction）是由一系列对系统中数据进行访问或更新的操作所组成的一个程序执行逻辑单元（Unit）。在事务的ACID特性中，C即一致性是事务的根本追求，而对数据一致性的破坏主要来自两个方面：
- 事务的并发执行
- 事务故障或系统故障
数据库系统是通过并发控制技术和日志恢复技术来避免这种情况发生的。
并发控制技术保证了事务的隔离性，使数据库的一致性状态不会因为并发执行的操作被破坏。
日志恢复技术保证了事务的原子性，使一致性状态不会因事务或系统故障被破坏。同时使已提交的对数据库的修改不会因系统崩溃而丢失，保证了事务的持久性。
我们将另文对以上两种技术进行详细介绍。
参考文献
What is a database transaction? (2019). Retrieved November 5, 2019, from Stack Overflow website: https://stackoverflow.com/questions/974596/what-is-a-database-transaction
Communcations and Information Processing: First International Conference, ICCIP 2012, Aveiro, Portugal, March 7-11, 2012, Proceedings, 第 2 部分
設計データ集約型アプリケーション：、信頼性の高いスケーラブルな背後にビッグアイディア、および保守性システム、第25节
DBMSでのACIDプロパティ- GeeksforGeeks。（2016年、8月7日）。GeeksforGeeksのウェブサイトから取得した2019年11月5日、：https://www.geeksforgeeks.org/acid-properties-in-dbms/
ウィキペディア（2011年、7月25日）を参照してくださいからの先行書き込みログ11月5日のRetrieved、2019、よりWikipedia.orgウェブサイトで：... Https://zh.wikipedia.org/wiki/%E9%A2%84%E5%86% 99％E5％以下のBC％8F％ E6％97％A5％E5％BF％97
...データベーストランザクションとその実装の原則の概念- takumiCX -ブログパーク（2018）Cnblogs.comウェブサイトから取得した2019年11月5日、：https://www.cnblogs.com/takumicx/p/9998844.html
MySQLの（2017年、8月20日）のRetrieved 11月のトランザクションの実装の深さが浅いから5、2019、 信念指向プログラミングのウェブサイト.. Https://draveness.me/mysql-transaction