事务, transaction

事务, transaction

TRANSACTION（事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。

数据库事务通常包含了一个序列的对数据库的读/写操作。包含有以下两个目的：

为数据库操作序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即使在异常状态下仍能保持一致性的方法。 当多个应用程序在并发访问数据库时，可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。

事务的属性: 原子性, 一致性, 隔离性, 持久性, ACID

• 原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
• 一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。
• 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
• 持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。

事务

事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务应该具有 4 个属性: 原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

一致性 Consistency

其实只有两类数据一致性，强一致性与弱一致性。强一致性也叫做线性一致性，除此以外，所有其他的一致性都是弱一致性的特殊情况。所谓强一致性，即复制是同步的，弱一致性，即复制是异步的。

强一致性

任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。

弱一致性

数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

最终一致性

不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态 事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。
最终一致性要求系统中数据副本最终能够一致，而不需要实时保证数据副本一致。例如，银行系统中的非实时转账操作，允许 24 小时内用户账户的状态在转账前后是不一致的，但 24 小时后账户数据必须正确。
最终一致性是 BASE 原理的核心，也是 NoSQL 数据库的主要特点，通过弱化一致性，提高系统的可伸缩性、可靠性和可用性。而且对于大多数 Web 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是多数分布式数据库产品的方向。

重试

重试机制可以使分布式不一致数据自动恢复，前提是重试接口要提供幂等保证。重试机制是达成分布式最终一致性的重要手段。例如，超时重传是TCP协议保证数据可靠性的一个重要机制，核心思想其实就是重试。

同步重试 : 在上次请求失败或超时，程序再次发起同步调用请求。后端程序不推荐同步重试，其一因为同步等待占用系统线程资源，其二因为重试引起的流量放大，可能导致系统雪崩。

异步重试 : 通过异步系统(消息队列或调度中间件)对失败或超时请求再次发起调用。推荐这种方式的重试，重试的时间间隔可以设置为根据重试次数指数增长，超过重试阈值仍未成功，可以报警通知并由人工订正。

重试也是提高系统可用性的一种有效手段。如果一个服务的可用性为98%(有1个9)，1次重试之后其可用性可达到99.96%(3个9)，2次重试可以达到99.9992%(5个9)。

幂等

幂等的数学定义为

f(f(x)) = f(x) 用通俗的话来说就是 : 相同的操作执行多次 和 执行一次产生的效果是一样的。有的操作是天然幂等的，如查询、删除操作。有的操作是人为使其幂等，例如TCP的超时重传操作就是幂等的，无论客户端将一个seq字节传送多少次，服务端窗口只会用一次该字节。

状态机

恢复日志

恢复日志是程序现场的记录，也是业务数据恢复的重要依据。恢复日志log要求全局唯一的requestId来标示请求(实际的业务场景可采用不会重复有含义的业务id)，出现异常，可以根据requestId维度redo和undo业务操作 状态机是表示实体的状态根据条件转移的数学模型。通过状态机模型，系统可以判断当前不一致状态，以及如何校正不一致状态到一致状态。

异步校验

彻底解决分布式一致性问题，有著名的Paxos算法，通过该算法分布式系统自发达成一致性。而在具体的业务场景，完全不需要系统自发的达成共识，我们只要在业务系统外部加上严格的业务约束，用来仲裁业务系统的状态。通过异步校验，可以发现分布式系统中的异常状态，并通过恢复日志进行脚本批量恢复或者人工处理恢复，根据校验的粒度有 :

根据业务实体id校验，使用消息队列，将需要校验业务id投递给校验系统，进行异步校验。

根据时间维度批量校验，使用异步调度框架，根据时间粒度批量获取进行异步校验。

此外，并不是所有系统都有可靠消息队列和调度服务支撑，业务系统可以增加一个本地业务id校验回执字段，校验系统根据校验步骤回调设置校验回执字段，并对校验未通过的数据进行重校验或者订正。

读写一致性

手机刷虎扑的时候经常遇到，回复某人的帖子然后想马上查看，但我刚提交的回复可能尚未到达从库，看起来好像是刚提交的数据丢失了，很不爽。

在这种情况下，我们需要读写一致性，也称为读己之写一致性。它可以保证，如果用户刷新页面，他们总会看到自己刚提交的任何更新。它不会对其他用户的写入做出承诺，其他用户的更新可能稍等才会看到，但它保证用户自己提交的数据能马上被自己看到。

单调读

用户从某从库查询到了一条记录，再次刷新后发现此记录不见了，就像遇到时光倒流。如果用户从不同从库进行多次读取，就可能发生这种情况。

单调读可以保证这种异常不会发生。单调读意味着如果一个用户进行多次读取时，绝对不会遇到时光倒流，即如果先前读取到较新的数据，后续读取不会得到更旧的数据。单调读比强一致性更弱，比最终一致性更强。

实现单调读取的一种方式是确保每个用户总是从同一个节点进行读取 (不同的用户可以从不同的节点读取) ，比如可以基于用户ID的哈希值来选择节点，而不是随机选择节点。

ACID，指数据库事务正确执行的四个基本要素的缩写 ACID特性 (原子性、一致性、隔离性、持久性)

原子性 (Atomicity)

整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚 (Rollback) 到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性 (Consistency)

在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

隔离性 (Isolation)

隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。

持久性 (Durability)

在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

由于一项操作通常会包含许多子操作，而这些子操作可能会因为硬件的损坏或其他因素产生问题，要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕，但实际上并不可行。

目前主要有两种方式实现ACID: 第一种是Write ahead logging，也就是日志式的方式。第二种是Shadow paging。

一个支持事务 (Transaction) 的，必需要具有这四种特性，否则在事务过程 (Transaction processing) 当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

https://xiaomi-info.github.io/2020/01/02/distributed-transaction/
http://c.biancheng.net/view/6495.html
https://toutiao.io/posts/u97o5l/preview