NoSQL 数据库中的 ACID 与 BASE 事务
尽管 ACID 事务长期以来都是在关系型数据库中确保数据完整性的黄金标准，NoSQL 数据库则常常更重视灵活性与可扩展性，而非严格的事务一致性。这种取舍促使在某些用例中采用 BASE 作为 ACID 的替代方案。
让我们了解 BASE、它与 ACID 的差异，以及各自适用的场景。
什么是 BASE？
BASE 是 Basically Available、Soft state、Eventual consistency 的首字母缩写。它为 NoSQL 数据库设计了一组属性，更侧重可用性与灵活性，而非严格一致性。
其原则定义如下：
- 基本可用（Basically available）： 系统保证可用性，即使部分组件宕机或不可达也会响应请求。
- 软状态（Soft state）： 由于异步更新，即便没有输入，系统状态也可能随时间变化。
- 最终一致（Eventual consistency）： 数据最终会达到一致，但在此之前可能存在短暂不一致。
ACID 与 BASE 的差异
ACID 与 BASE 的主要差异围绕一致性、可用性与性能之间的权衡：
一致性
ACID 确保事务后数据库始终一致，并通过严格规则维护数据完整性。相对地，BASE 为了可用性与性能牺牲严格一致性，使系统在最终达到一致前允许短暂不一致。
可用性
ACID 系统将一致性与持久性置于可用性之上，因此在某些故障期间可能不可用。BASE 系统则旨在实现高可用，确保在网络分区或故障期间系统仍具响应性。
可扩展性
ACID 系统在分布式环境的横向扩展中可能面临挑战，因为维持严格一致性会消耗大量资源。BASE 系统更具可扩展性，通常为了处理海量数据与流量而设计为横向扩展，对即时一致性的要求较低。
ACID 与 BASE 的适用场景
当数据一致性至关重要时，适合使用 ACID 事务，例如：
- 金融交易： 转账或处理支付时准确性与一致性至关重要。
- 库存系统： 确保库存水平被准确更新，避免超卖或差异。
- 订单处理： 在电商中，要让客户满意，订单需被正确且一致地处理。
当可扩展性、高可用与性能比严格一致性更重要时，适合选择 BASE 事务，例如：
- 社交媒体信息流： 对数据一致性的要求较低，只要系统保持响应，帖子或点赞出现短暂不一致是可接受的。
- 内容分发网络： 优先以最低延迟向用户提供内容，而非一致性。
ACID vs BASE：对比表
|
特性 |
ACID |
BASE |
|
全称 |
Atomicity, Consistency, Isolation, Durability |
Basically Available, Soft state, Eventually consistent |
|
核心原则 |
确保可靠、一致的事务 |
将可用性与性能置于严格一致性之上 |
|
一致性模型 |
严格一致性 |
最终一致性 |
|
数据完整性 |
高——始终保证数据完整性 |
较低——允许暂时不一致 |
|
事务处理 |
事务要么完全完成，要么完全不执行 |
尽力而为的事务——可能暂时不完整或不一致 |
|
可扩展性 |
受限——最适用于单体或传统关系型数据库 |
高——为分布式、可扩展系统而设计 |
|
延迟 |
较高——源于严格一致性的要求 |
较低——允许更快的响应时间 |
|
用例 |
金融交易、库存管理、订单处理 |
社交媒体平台、实时分析、内容分发网络 |
如果您想了解 BASE 原则如何应用于 NoSQL 数据库，请查看这门 NoSQL Concepts课程——是理解这些权衡的绝佳起点。
ACID 事务的常见挑战
实施 ACID 事务并非毫无挑战。这些挑战在高事务量环境、分布式系统以及管理并发事务时尤为明显。
本节我们将深入探讨使用 ACID 事务时面临的关键问题。
ACID 事务的性能成本
使用 ACID 事务的首要权衡之一是性能。保障原子性、一致性和持久性是有代价的——尤其在数据库处理高事务量时。
为维持这些属性所需的要求可能通过以下方式拖慢操作：
- 原子性要求事务内所有步骤作为单元执行，意味着若任一步骤失败，整个事务必须回滚。回滚过程可能消耗大量资源。
- 一致性要求事务总能将数据库带到有效状态，这通常涉及检查约束、触发器和业务规则。这些额外检查会增加每笔事务的处理时间。
- 持久性确保事务提交后变更被永久保存，往往需要写入多个位置，包括事务日志与磁盘存储。这些持久化过程会降低系统总体吞吐。
随着事务量增加，这些过程可能导致瓶颈，限制系统的可扩展性与响应性。
在分布式系统中扩展符合 ACID 的数据库的难度
ACID 原则传统上面向单节点或集中式系统设计，在这些系统中更易保障数据完整性与事务一致性。然而，随着数据库规模增长——尤其跨地理分布的集群——维持 ACID 属性会更加复杂。
- 分布式事务： 在分布式环境中，一笔事务可能跨多个节点或地点。确保所有参与节点就事务结果达成一致并不容易，尤其在高延迟或网络分区情况下。通常使用两阶段提交等技术，但会增加开销与复杂度。
- 数据复制： 符合 ACID 的数据库往往在多台服务器间复制数据以确保持久性。然而，同步这些数据并确保所有副本一致可能既缓慢又耗费资源。网络延迟与服务器故障会进一步加剧副本数据一致性的复杂度。
扩展符合 ACID 的数据库需要在所有节点上仔细管理一致性与持久性，这在高度动态或全球分布式系统中尤为棘手。
在保持隔离性的同时管理并发事务
在多用户环境中，并发事务给符合 ACID 的数据库带来另一重挑战。隔离性确保并发事务彼此不干扰，而要实现这一点需要使用管理与控制数据访问的机制。
管理并发最常见的方法是加锁机制，但这也伴随一系列挑战：
- 加锁： 数据库采用锁（如行级锁、表级锁）来防止冲突事务同时访问相同数据。加锁能保证隔离性，但可能引发死锁，即两个或多个事务相互等待对方释放锁。
- 锁竞争： 高并发会导致锁竞争频繁，事务互相阻塞，从而降低系统整体速度。随着事务数量增多，锁管理变得更复杂，并可能对性能造成负面影响。
- 事务回滚： 若发生死锁或检测到冲突，可能需要回滚其中一笔事务，导致资源浪费与吞吐下降。
使用 ACID 事务的最佳实践
在高负载或复杂环境中，应用最佳实践可显著提升系统长期稳定性。
以下是高效使用 ACID 事务的一些关键做法。
实施合理的事务管理
最重要的最佳实践之一是只在必要时使用事务。没错，对于需要数据完整性的操作，ACID 属性至关重要，但若将每个数据库操作都包裹在事务中，会带来不必要的开销与性能瓶颈。
- 最小化事务范围： 将每笔事务限定在绝对需要原子性与一致性的关键操作上。避免将不必要的只读操作包裹其中。
- 使用更小的事务： 尽可能将大型、复杂操作拆分为更小的事务，这能减少每笔事务的工作量。
- 尽快提交或回滚： 始终确保尽快提交或回滚事务，以释放资源并避免长时间持有锁。
归根结底，关键在于聚焦关键操作。这样既能保障数据库完整性，又不会引入过多开销。
为并发进行优化
优化数据库配置并应用并发控制，对在保障隔离性的同时维持性能至关重要，使多笔事务能同时运行而不相互影响。
- 事务隔离级别： 根据应用需求选择合适的隔离级别。例如，
READ COMMITTED适用于许多应用，但在需要严格隔离的场景可能需要SERIALIZABLE。注意更高的隔离级别会增加竞争、降低吞吐。 - 加锁机制： 合理配置锁以在保障数据完整性的同时允许高并发。例如使用行级锁（而非表级锁）可在多事务访问相同数据时减少瓶颈。
- 乐观并发控制： 在某些情况下，您可以采用乐观并发控制以避免加锁。该方法假设冲突较少，只在提交时校验数据，这比在事务期间锁定记录更高效。
优化并发能保护系统并保持其响应性（即便在处理并发事务时）。
监控与记录事务
必须进行监控与日志记录，以便您随时掌握数据库系统的健康状况与效率。
- 监控事务性能： 使用工具实时跟踪事务性能。关注慢查询、过多的锁或频繁回滚，这些都可能表明事务管理或数据库配置存在问题。
- 记录错误与异常： 确保记录所有事务失败、回滚与冲突，以便后续分析。这有助于识别反复出现的问题、排查并改进。
- 分析事务吞吐： 跟踪处理的事务数量，评估系统是否有效承载负载。若事务数量超出系统承载能力，您可能需要优化配置或更均衡地分配负载。
有效的监控与日志记录可使您主动管理数据库。对系统了解得越多，就越能及时调整，确保其持续满足应用需求。
结论
本文探讨了 ACID 事务的关键原则。我们讨论了这些属性在金融交易、电商订单与库存系统等场景中的重要性，并强调了它们在主流 SQL 数据库中的实现方式。
此外，我们还比较了 ACID 与 BASE 事务的差异，分析了扩展符合 ACID 的系统所面临的挑战，并给出了高效管理事务的最佳实践。
若您想更深入了解 ACID 事务在 PostgreSQL 中如何工作，我强烈推荐这门 Transactions and Error Handling in PostgreSQL课程。
FAQs
ACID 事务在分布式数据库中如何工作？
在分布式数据库中，由于网络延迟与分区问题，实现严格的 ACID 合规存在挑战。两阶段提交（2PC）与三阶段提交（3PC）等技术可在多节点间协调事务，确保一致性。然而，它们会引入延迟与潜在瓶颈，因此一些分布式数据库更倾向于 BASE。更新的方法如 Google 的 Spanner 与 CockroachDB 使用 Paxos 或 Raft 等分布式一致性协议，在全球扩展的同时保持强一致性。
ACID 事务可以优化性能吗？
是的，ACID 事务的性能优化包括：
- 批量操作：将多次写入合并为单个事务以减少开销。
- 高效使用索引：通过合理建索引优化查询，缩短事务持续时间。
- 乐观并发控制：假设事务不会冲突，在提交时校验以减少锁竞争。
- 调整隔离级别：较低的隔离级别（例如用 Read Committed 替代 Serializable）可在权衡一致性的同时提升性能。
ACID 事务与幂等操作有什么区别？
ACID 事务确保每笔事务只执行一次并完整完成（或被完全回滚）。相比之下，幂等操作保证重复执行会产生相同结果且无意外副作用。例如，更新记录（UPDATE users SET balance = 100 WHERE id = 1）是幂等的，但增加余额（UPDATE users SET balance = balance + 100 WHERE id = 1）并非幂等，除非用 ACID 事务包裹以防止竞态条件。
现代数据库如何平衡 ACID 与 BASE 原则？
许多现代数据库采用混合方式：在需要时提供强一致性，在重视可扩展性时采用最终一致性。
- NewSQL 数据库（如 Google Spanner、CockroachDB、YugabyteDB）采用分布式架构同时保持 ACID 合规。
- MongoDB 与 Cassandra 主要遵循 BASE，但为多文档操作提供事务支持。
- PostgreSQL 等数据库支持逻辑复制与多主架构，以在不完全牺牲 ACID 保证的情况下实现高可用。
ACID 事务与事件驱动架构之间的权衡是什么？
在事件驱动架构中，微服务通常通过事件日志（如 Kafka）而非严格的 ACID 事务进行通信。其权衡包括：
- 可扩展性：事件驱动系统可横向扩展，而 ACID 事务会引入竞争与加锁。
- 一致性：ACID 保证强一致性，而事件驱动系统更偏向最终一致性。
- 复杂度：事件驱动架构需要幂等性、消息去重与“恰好一次”处理，以防止 ACID 事务天然处理的问题。
- 韧性：ACID 通过事务日志保障持久性，而事件驱动系统通过事件溯源与 Saga 等模式来维持可靠性。
想象一下，客户打来电话一头雾水：账户里的钱被扣了却没有转到收款人名下，或订单已提交但库存却没更新。这些问题往往出在没有强制保障数据完整性上。这正是 ACID 原则发挥作用的地方。
ACID 原则用于确保每笔事务都被可靠处理，从而保障数据安全、系统平稳运行。理解这些原则是构建可靠且容错系统的关键。
在本指南中，您将了解：
我们开始吧！
什么是 ACID 事务？
ACID 事务指的是保障数据库事务可靠处理的四个属性。这四项原则是：
这些原则保证事务要么全部执行完成，要么完全不发生，即便系统发生故障也不会出现部分更新或数据损坏。在数据完整性至关重要的场景中，ACID 事务不可或缺。
在银行交易中，ACID 保证资金要么完成全额转账，要么不转，避免出现部分转账或重复扣款等问题。在电商中，ACID 原则确保客户订单被正确处理、支付完成，库存更新能反映实时库存水平。同样，在库存管理系统中，ACID 通过防止并发事务导致的库存不一致来维持一致性。
拆解 ACID 属性
构成 ACID 原则的四个属性分别解决事务管理中的特定方面。
让我们逐一了解这些属性如何助力构建健壮的数据库系统。
原子性
原子性保证一笔事务被视为单一、不可分割的单元。也就是说，事务中的所有操作要么全部完成，要么完全不执行。若事务的任何部分失败，系统会回滚整个事务，确保不会发生部分更新。
示例：在银行交易中，当从一个账户借记并向另一个账户贷记时，原子性确保两项操作都成功完成。若借记或贷记任一失败，事务将被完全撤销。
一致性
一致性确保事务会将数据库从一个有效状态带到另一个有效状态，并遵循预定义的规则或约束。事务完成后，数据必须满足数据库的所有完整性规则。
示例：在银行中，一致性确保转账后所有账户的总余额不变。例如在账户之间转移 100 美元时，两者余额之和保持不变，以遵循会计规则。
隔离性
隔离性防止事务相互干扰。当多笔事务同时执行时，隔离性确保它们不会影响彼此的结果。每个事务都必须被隔离以避免冲突——这在高并发环境中尤为重要。
示例：如果两位客户同时尝试购买仅剩的一件商品，隔离性确保只有一笔交易会成功，且库存将被正确更新以反映变更。
持久性
持久性保证一旦事务完成，其变更将被永久存储在数据库中（即使系统随后立即崩溃）。这确保在故障后数据依然完整可用。
示例：在电商系统中，持久性确保顾客完成购买后，订单数据已保存到数据库。即使服务器随后几秒内崩溃，购买记录也依然完整，并可在系统恢复后检索。
ACID 属性。图片来源：作者
关系型数据库中的 ACID 事务
大多数关系型数据库在设计之初就以 ACID 原则为核心。这意味着它们旨在保持数据的准确性与可靠性。
本节我们来看看数据库如何实现 ACID 属性。
如果您刚接触关系型数据库，这门 Introduction to Relational Databases in SQL课程非常适合打好基础。
SQL 数据库如何实现 ACID
传统 SQL 数据库通过事务控制机制来强制 ACID 属性，例如使用SQL commands 如
BEGIN、COMMIT和ROLLBACK。这些命令用于管理事务，而事务日志与锁则确保数据完整性。例如：
ROLLBACK，防止部分更新。不同数据库系统的 ACID 合规性
大多数 SQL 数据库都具备内置的 ACID 合规能力以维护事务完整性。诸如 MySQL、PostgreSQL、Oracle 和 Microsoft SQL Server 等系统使用事务日志（如 PostgreSQL 的预写式日志 WAL）和加锁协议（如两阶段锁定）来强制执行 ACID 属性。这些机制有助于在每笔事务中保护数据完整性。
更具体地说：
在使用 SQL Server？这门 Transactions and Error Handling in SQL Server课程是掌握事务控制、确保数据完整性的好方式。
符合 ACID 的 SQL 事务示例
以下是一个遵循 ACID 原则的 PostgreSQL 事务的简单 SQL 示例。
该示例演示在两个账户之间转账，确保事务要么完全成功，要么在失败时完全回滚：
在该事务中：
刚开始学习 SQL？这门 Introduction to SQL课程能帮助您掌握基础，自信编写查询。