什么是事务数据库？

这是我参与8月更文挑战的第10天，活动详情查看：8月更文挑战

正如这篇文章的标题所问，什么是事务数据库？简短的回答是，它是一个支持全有或全无数据操作的存储系统，通常称为事务。这意味着，如果要执行的某些可能很长的数据操作列表（例如，创建、更新或删除信息）的任何子集因任何原因失败，则所有操作都将被放弃，并且数据库将恢复到任何操作之前的状态。的行动开始了。

此功能提供了可靠的信息存储和处理，因为它可以防止错误的数据操作，从而确保数据库始终处于正确状态。事务数据库为数据完整性提供保证，即使在系统故障的情况下也是如此，这对于许多用例来说可能是关键任务。

考虑一个银行客户使用移动设备上的应用程序将资金从一个帐户转移到另一个帐户的快速而常见的示例。完整且正确的交易需要借记来源帐户和贷记目的地帐户。

但是，如果断电，数据库服务器后原点帐户尚未扣除之前的目标账户贷记？一个真正的事务数据库确保在这种情况下整个事务的第一部分被取消（或“回滚”），因为第二部分没有通过，尽管发生故障，数据库仍保持正确和一致的状态。

在本文中，我们将更详细地研究数据库事务及其重要性，解释“ACID 合规性”的四个要素及其重要性，讨论当数据和事务分布在现代系统中时维护这些要素所涉及的常见困难，并提供一些关于选择满足您需求的事务性数据库系统的具体建议。

什么是数据库事务？

简而言之，数据库事务是由数据库管理系统 (DBMS) 针对给定数据库执行的工作单元，执行数据操作并更新各种存储介质上的底层文件。事务数据库将确保此类工作单元是全有或全无的，因为任何操作中的任何失败都将导致所有操作暂停和回滚，使数据库处于事务开始之前的状态。

使用事务数据库有两个主要原因，第一个是它使工作单元在所有情况下都可靠。回顾一下我们的银行业务示例，客户可以放心，当他们的钱从原始账户中扣除时，将记入目的地账户。如果在此过程中出现任何问题（例如，网络故障、服务器故障等），客户希望他们的帐户保持不变，而不是简单地因偶然事件而赔钱。

第二个原因是我们所描述的事务数据库始终处于正确且一致的状态，而不管所涉及的所有技术可能发生何种故障。没有人愿意将信息存储在一个系统中，该系统的数据可能会因为允许无效操作而变得不连贯，或者在服务器宕机时可能会丢失信息。当然，并非每个用例都是关键任务，但很多都是，在这些情况下，事务数据库可以提供巨大的业务价值。

当然，并不是每个数据库系统本质上都是事务性的。一些系统只专注于记录丢失的信息或不需要支持事务功能的信息。在考虑您的用例时，重要的是密切关注您需要这些功能的程度，并将您的期望与潜在数据库系统遵守事务数据库原则的程度相匹配。

ACID 合规性的重要性

ACID 是“Atomicity、Consistency、Isolation 和 Durability”的首字母缩写，它是一组确保数据库事务可靠、正确处理的原则。下表解释了这四个不同元素所涉及的内容。

元素	意义
原子性	事务中的所有数据操作以全有或全无的方式完成或回滚。
一致性	数据库中的信息在所有情况下都必须在语义上有意义（例如，在没有有效父级的情况下不插入子数据，必填字段没有空值等）
隔离	每个事务必须独立于同时进行的任何其他事务运行；即，不能允许信息从一项交易“泄漏”到另一项交易。
耐用性	任何成功完成的交易都会以不可磨灭的方式记录下来，这意味着它的数据不会在软件甚至硬件故障的情况下丢失。

让我们考虑一个更复杂的例子来说明为什么 ACID 保证很重要。想象另一种常见的情况，其中两个人 A 和 B 正在为电影院的同一场演出预订同一排的座位。A 只预订了一个座位，而 B 则试图为家庭出游预订整排。

如果A先预订了座位，那么B的交易就会失败，因为网上购物车中的一个座位已经被预订了，不能重复预订。这说明了原子性，因为 B 人的数据操作之一失败了，他们都做了，以及一致性，因为系统不会允许无意义的数据，例如两个人保留相同的座位。

只有当 A 的预订成功完成并写入数据库时​​，B 的交易才会被取消。然而，在这种情况发生之前，隔离的特性是允许两个人同时尝试对同一个席位进行交易，确保双方都将有争议的席位视为可用，直到它被实际保留。

最后，即使在 A 成功预订座位后整个预订系统崩溃，持久性确保在重新启动时正确的数据仍然存在。这使得 A 可以根据需要打印票并享受演出，无论在交易正确完成后发生什么系统故障。

分布式事务如何工作？

现代应用程序在本质上越来越分散，通常在全球范围内可用，这使得事务数据库的问题变得更加困难。原因是 ACID 保证对于分布式系统与在单个服务器上运行的单个数据库软件一样重要，但是涉及多个服务器或节点会使问题显着复杂化。

想想看。当单个数据库软件可以“决定”在第一个事务失败后立即取消事务中的所有其他数据操作时，这很简单。当数据库软件在分散在世界各地的数十个（甚至数百个）节点上运行时，这完全是另一回事。任何这些服务器上任何数据操作的任何元素的任何故障都要求必须取消整个事务并在任何地方安全回滚。类似地，即使事务成功，整个系统也必须确保所有操作都是正确且持久的，无论哪个或哪些服务器执行它们。

实际上，分布式事务数据库很难正确实现，但幸运的是一些供应商做到了。例如，由于其架构和数据存储算法，Fauna能够提供严格可序列化、外部一致的事务。

与其他系统不同的是，Fauna 不需要所有服务器之间严格的物理时钟同步来提供一致性，这避免了副本服务器之间通常的距离限制，因此对于以典型的全球 Internet 延迟在世界各地进行部署是实用的。当系统时钟或网络流量相差几毫秒时，确实需要同步的方法可能会导致故障，而 Fauna 更宽松的要求则不会遇到此类问题。

这是可能的，因为 Fauna 提供了受 Calvin 启发的事务引擎，这是一种跨分区数据库系统实现快速分布式事务的方法。Fauna 事务引擎可以通过其分布式事务协议实现“没有时钟的一致性” 。实际上，在任何数据库写入之前，Fauna 会预先决定事务应以何种顺序执行。然后，Fauna 执行引擎以这样一种方式处理它们，即最终结果与按照该顺序一次处理一个相同。

实际上，您可以获得在多台服务器上并行执行的分布式事务的所有速度和功能，同时享受事务数据库的所有数据优势，就好像它们在单个服务器上串行执行一样。

呼吁采取行动

Fauna 以完全分布式的方式将非事务性数据库的所有灵活性和性能与事务性数据库的关系查询和功能以及 ACID 保证相结合。事实上，由于 Fauna 处理其分布式事务的方式，用户可以避免其他系统可能发生的那种数据异常。通过不限制键、文档或分区数量的严格可序列化的多区域事务，可以防止不朽写入、陈旧读取、因果反转和其他此类问题。

还值得注意的是，Fauna不是通常托管的“数据库即服务”(DBaaS)，甚至不是一些集群云产品，两者都需要管理。相反，Fauna 是一个真正的“数据 API”，这意味着开发人员可以根据需要简单地进行调用，而无需花时间担心配置或扩展，具有事务数据库和 ACID 合规性的所有好处。

因为它是一个真正的数据 API，所以 Fauna 没有所有常见的配置和配置问题，并且可以立即作为无服务器实用程序使用。开发人员只需要一个帐户即可开始使用，无需支付任何费用并提供丰厚的起步津贴。没有常见的头痛问题：没有配置实例，没有广泛的配置等。

在本文中，我们检查了事务数据库，解释了它们提供的 ACID 保证，说明了它们在关键任务用例中的价值，讨论了现代对分布式事务的需求如何使情况复杂化，并提供了一些具体的建议，以轻松获得 ACID合规的数据优势。

最后，Fauna 通过轻松分布式数据库事务、自动配置和轻松扩展来提供所有价值。它可以免费注册，易于上手，并提供清晰简单的定价——只需为您实际使用的内容付费。如果您认为 Fauna 可以管理您的数据需求，为什么不立即尝试一下呢？