Redis 8 来了，它是开源的
了解更多
ACID 事务 是指一组旨在确保数据库事务可靠性和一致性的属性。术语“ACID”代表 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）和 Durability（持久性），它们是 ACID 事务的四个关键属性。本质上，ACID 事务保证数据库操作正确执行，并且如果发生任何类型的故障，数据库可以恢复到以前的状态，而不会丢失任何数据或影响数据的一致性。换句话说，ACID 事务提供了高度保证，确保数据库事务得到可靠处理，并且数据得到准确且一致的存储。
ACID 事务是一组属性，用于确保数据库事务的可靠性和一致性。事务是一系列操作，作为一个工作单元完成，使用读写操作访问数据。大多数数据库为仅影响一条记录的操作提供事务性保证。本节将解释 ACID 事务中涉及的特性基本定义。
ACID 事务中的原子性保证将事务视为一个单一的、不可分割的工作单元。如果事务的任何部分失败，整个事务必须回滚，这意味着在事务期间所做的任何更改都将被撤消。这确保数据库保持一致状态，无论事务期间可能发生任何故障。
一致性确保数据库在事务之前和之后保持有效状态。换句话说，数据库模式必须满足所有约束和规则，任何违反这些约束的事务必须回滚以维护数据库的一致性。这确保数据库保持其完整性，并且数据保持准确和可靠。
此属性确保每个事务独立于其他事务操作，这意味着事务的效果仅在提交后才对其他事务可见。此属性防止并发事务之间的干扰和冲突，并有助于维护数据库的完整性和一致性。需要注意的是，可以根据应用程序和所使用的数据库系统的具体要求，为事务配置不同的隔离级别。
此特性确保即使在系统发生故障时，事务期间对数据库所做的更改也是不可逆转的。事务提交后所做的任何更改都必须持久化，即使系统被破坏或断电。
ACID 事务通过遵循一系列步骤来维护数据完整性。所描述的步骤是数据库实现 ACID 事务的常用方法，但具体实现可能因所使用的数据库系统而异。
考虑一个银行应用，用户希望将资金从一个账户转移到另一个账户，该操作的事务可能如下所示
如果任何操作失败，例如源账户资金不足，事务将回滚，数据库将恢复到其初始状态。
ACID 事务适用于许多用例。以下是一些示例
银行使用 ACID 事务来确保支付和其他金融交易得到准确、安全地处理。例如，当客户从 ATM 取款时，会执行一个 ACID 事务来更新其账户余额并记录交易。该事务是原子的，这意味着它要么成功要么失败，账户余额保持不变。
要了解处理事务的正确 Redis 工具概述，并学习 Redis Enterprise 如何帮助您扩展客户体验，请查阅我们的白皮书《使用 Redis 确保客户满意度》
医疗保健系统使用 ACID 事务来帮助保证患者记录得到准确更新，并保护私人医疗数据。电子健康记录 (EHRs) 包含患者的个人信息，必须准确和一致。例如，当医生在 EHR 中更新患者用药信息时，就会发生一个 ACID 事务，以确保数据原子地、一致地和持久地更新。
电子商务应用使用 ACID 事务来确保客户订单得到正确处理，并且库存水平得到正确更新。例如，当客户购买商品时，会执行一个 ACID 事务来更新库存记录，并保证该事务是原子的、一致的、隔离的和持久的。
让我们比较一下 ACID 事务的优点和缺点并确定其潜力。 值得注意的是，列出的缺点并非总是 ACID 事务固有的缺点。它们可能因具体实现和应用程序的需求而异。例如，虽然开销和可伸缩性在某些场景下可能是一个问题，但在其他场景下可能不是重要问题。同样，虽然死锁在某些情况下可能是一个问题，但事务的正确设计和管理通常可以减轻或防止它们。
| 优点 | 缺点 |
| 数据完整性– 即使事务失败，ACID 事务也能保证数据库保持一致状态。这有助于数据的可靠性和完整性。 | 开销– 数据库的性能受 ACID 事务所需的额外处理开销的影响。 |
| 一致性– ACID 事务确保数据库在事务之前和之后都有效。这有助于数据库的一致性。 | 死锁– 多个事务相互等待释放资源可能导致死锁。死锁难以解决，并影响数据库的读写和检索性能。 |
| 隔离性– ACID 事务确保每个事务独立于其他事务。它还通过防止并发事务之间的干扰来帮助维护数据完整性。 | 可伸缩性– ACID 事务在需要高性能和可伸缩性的大规模分布式系统中难以实现。 |
| 持久性– ACID 事务确保即使在系统发生故障时，事务期间对数据库所做的更改也是不可逆转的。这有助于数据的可靠性。 | 相似数据更新- 当多个事务并发运行时，如果它们同时尝试修改相同的数据，可能会发生冲突。因此，一个事务可能需要等待另一个事务完成后才能继续进行，这会降低系统性能并增加延迟。 |
ACID 事务为确保数据可靠性、一致性、隔离性和持久性提供了多种益处。但是，它们可能并非适合所有应用程序。在这种情况下，可以考虑使用 ACID 之外的各种替代事务模型和定理。其中包括
BASE 不一定是 ACID 事务的替代品，而是一种处理无法保证即时一致性的分布式系统的替代模型。BASE 更强调可用性和分区容错性，而不是一致性。这种模型牺牲了短期一致性以换取长期稳定性。虽然它假设所有数据最终都会变得一致，但它无法保证这一点。这种方法适用于高流量分布式系统，因为它提供了更好的可伸缩性和可用性。它通常与 NoSQL 数据库一起使用，后者优先考虑可伸缩性和可用性，而不是严格的一致性要求。
CAP 定理指出，在分布式系统中，不可能同时保证一致性 (Consistency)、可用性 (Availability) 和分区容错性 (Partition tolerance) 三者。然而，它并不建议牺牲一致性来换取可用性和分区容错性。实际上，该定理是在一致性和分区容错性之间做出权衡。这意味着在发生网络分区时，您必须在一致性和分区容错性之间进行选择。CAP 定理并非真正意义上的替代事务模型，而是理解分布式系统局限性的理论框架。诸如 BASE 之类的事务模型可以与 CAP 原理结合使用来设计和实现分布式系统。
NoSQL 数据库不强制执行严格的一致性标准，并将性能和可伸缩性优先于即时一致性。它们通常用于需要高吞吐量且数据一致性不关键的应用程序。虽然关系型数据库确保理想的 ACID 属性，但 NoSQL 数据库更有效地处理大型和复杂的数据集。此外，BASE 属性在许多应用程序中可以表现得更好，尽管在这种情况下不总是保证 ACID。
分布式系统由许多相互交互以提供单一服务的计算机组成。在分布式系统中实现 ACID 事务可能很困难，因为它们由地理上分散并通过网络通信的多个节点组成。
分布式系统由多台计算机协作提供单一服务。在分布式系统中实现 ACID 事务可能具有挑战性，因为它们包含地理位置分散并通过网络通信的多个节点。
在分布式系统中实现 ACID 事务的挑战包括
网络延迟: 在分布式系统中，网络延迟可能影响 ACID 事务的性能。网络通信延迟可能导致事务时间更长和开销更高。
一致性: 在分布式系统中维护所有节点的一致性可能具有挑战性。分布式系统的节点可能存储同一数据的不同版本，这可能导致差异。
可用性: 保持分布式系统可用可能很困难。节点可能发生故障，并且可能难以保持系统的响应能力。
可伸缩性: 随着分布式系统中节点数量的增加，维持一致性和可用性变得更加困难。
由于网络延迟、一致性、可用性和可伸缩性等因素，在分布式系统中难以维护 ACID 事务。为了应对这些挑战，已经开发了几种解决方案，包括
ACID 事务是数据库管理中的一个基本概念，提供数据完整性、一致性、隔离性和持久性等优势。它们确保数据库即使在服务器发生故障时也能保持一致状态。然而，它们确实存在一些限制和挑战，例如开销、死锁以及在分布式系统中的可伸缩性问题。
尽管 ACID 事务提供了强大的¹一致性和可靠性，但它们并非始终是所有用例的最佳选择。组织必须仔细评估其独特的需求和要求，以确定 ACID 事务或替代事务模型（例如 BASE 或 CAP）是否更适合其系统。
