在新的数字环境中，各个国家和全球品牌必须推广始终在线且几乎实时执行的应用程序。这导致应用程序以及为这些应用程序提供服务的数据库采用了分布式技术。为了最好地服务于广泛的地理区域并获得更高级别的可用性，各种组织已在地理区域之间（无论是自己的数据中心还是公共云供应商代表的分区，或两者兼而有之）分布了数字化业务。为了应对在此分布式领域中维护发生的业务交易的全球视图的挑战，Aerospike 支持两种不同的主动-主动部署模型，即多站点集群和跨数据中心复制 (XDR)：
- 多站点集群使用同步复制，通过在多个地理分布站点之间跨越单个 Aerospike 集群来提供全球分布的交易功能。
- 跨数据中心复制 (XDR) 使用异步复制来连接位于多个地理分布站点上的两个或更多 Aerospike 集群。
上面的两个模型都是主动-主动模式，使 Aerospike 可以用于各种交易用例。
多站点集群
在多站点集群配置中，组成单个 Aerospike 集群的节点分布在站点之间。站点可以是数据中心的物理机架、整个数据中心、云区域的可用分区、或云区域。这里有一些示例：
- 具有两个机架的单个集群，第一个机架位于美国西部区域的亚马逊的一个可用分区，第二个机架位于西部区域的亚马逊的另一个可用分区。
- 具有三个机架的单个集群，第一个机架位于美国西部区域的亚马逊，第二个机架位于中部区域的亚马逊，第三个机架位于东部区域的亚马逊。
- 具有两个机架的单个集群，第一个机架位于意大利罗马的一个数据中心，另一个机架位于一个数据中心附近（距离八公里），也位于罗马。
- 具有三个机架的单个集群，第一个机架位于旧金山的一个数据中心，第二个机架位于纽约的一个数据中心，第三个机架位于达拉斯的一个数据中心。
在所有四个示例中，假定每个机架具有相同数量的同类节点，因此每个机架的系统容量相同。一种常见的做法是确保复制因子被设置为与机架数量相等。多站点集群依赖于 Aerospike 本身固有的分布式聚类算法，而与站点之间的距离无关。
通过将 Aerospike 集群配置为强一致性 (SC)，多站点集群可确保所有写入将在站点之间复制而不会丢失数据。写入逻辑如图1所示。所有应用程序写入都发送到包含分区原版副本的节点，然后在系统将成功返回给客户端之前，该节点与每个复制副本协调一个两阶段的写入过程。如果对其中一个复制副本的写入失败，则原版副本将确保已完成对集群（或子集群，如果系统受到威胁）中适当数量的复制副本的写入。另外，请注意，在大多数情况下，不会为复制因子 2 发送建议复制消息（代理原版副本不是复制副本的情况除外）。
这样的系统可以在整个站点（机架）丢失后不丢失数据并继续运行。因此，这样的集群是一种主动/主动配置，在站点故障场景具有强一致性和可用性。
主要的权衡是处理低写入和读取延迟。
· 应用程序的写入可能会经历额外的延迟，这取决于两个站点之间的有效距离，无论是实际的物理距离还是网络配置导致的延迟。例如，地面上相隔几英里的站点的额外延迟可能只有几毫秒，而通过卫星链接相隔数千英里的站点的延迟可能会增加。
· 可以将在给定站点上运行的应用程序配置为以低延迟从位于同一站点的机架读取数据，因为在本地机架的节点中可以使用集群数据的整个副本。
图2所示的集群由三个站点中的三个机架组成，其复制因子为3。因此，在这种情况下，每个站点都有数据的完整副本。每个站点都对读取进行了本地化，以保持低读取延迟，而写入延迟则可能在几毫秒到几百毫秒之间不等，这取决于站点的地理位置及其之间的距离。
诸如此类的集群将保持强一致性，避免数据丢失，并在单个站点故障时保留可用性。在图3中，机架3与集群断开连接，形成脑裂，其中机架1和2形成多数子集群，而机架3形成少数子集群。系统使用在原始集群的所有节点之间共享的名册中的信息，使用 Aerospike 的强一致性算法来确保没有写入丢失，并且没有操作员干预。包含机架1和2的多数子集群在创建在脑裂事件期间正在写入的数据项的临时第三副本的同时，继续进行读取和写入。少数子集群仍然可用，但不可用于应用程序读取和写入。一旦网络分裂被修复，机架3的节点与其他节点连接，形成由机架1、2和3组成的完整集群。此时，在脑裂事件中更新的项目的第三副本已正确传输到机架3中的适当节点，以便系统可以恢复到稳定状态。所有这些操作都在没有操作员干预的情况下发生，在发生脑裂事件期间，保持了强一致性，没有数据丢失，并且完全可用。有许多此类故障会自动处理，以确保自动处理大多数站点故障事件。
借助多站点集群，Aerospike 数据库 5 提供强一致性、地理数据分布、灵活性和性能，使其成为需要大规模地理分布的交易系统的任何企业的最佳选择。Aerospike 多站点集群建立在实时、始终在线、主动-主动架构的基础上，为全球企业提供了新的用例类别，其中对强一致性、弹性伸缩、高性能和复原能力的要求是不可协商的。
多站点集群将强一致性与对大规模、全球分布的交易应用程序的支持独特地结合在一起，这些应用程序可以放宽写入延迟，该延迟根据集群站点之间的距离而变化，同时仍以高吞吐量提供亚毫秒级的读取延迟。如前所述，Aerospike 多站点集群可以进行架构设计，以在没有操作员干预的情况下幸免于站点故障，同时通过避免冲突来提供强一致性和零数据丢失。这消除了对应用程序复杂性和/或解决冲突时的人工介入的需求。
跨数据中心复制 (XDR)
Aerospike 数据库 5 提供了一种新的基于主动-主动架构的 XDR （跨数据中心复制）实施方案，并且在位于不同地理分布站点的集群之间进行了异步复制。站点可以是数据中心的物理机架、整个数据中心、云区域的可用分区、或云区域。这里有一些示例：
| 示例配置 | 说明和拓扑类型 |
|---|---|
| 1. 美国西部区域的亚马逊的一个可用分区中的一个集群，被配置为将其所有数据更新传送到西部区域的亚马逊的另一个可用分区中的第二集群。 | 在集群之间配置单向传送。这是典型的主动-被动设置，其中第二集群有时被称为“热备用”。 |
| 2. 一个两集群系统，其中每个集群都配置为将其所有数据更新传送到另一个集群，第一集群位于美国西部区域的亚马逊，第二集群位于东部区域的亚马逊。在这种情况下，可以将应用程序配置为使用任何一个集群进行读取/更新。 | 双向传送配置。 该配置可以表示为主动-主动。 |
| 3. 一个三集群跨云主动/主动系统，第一集群位于美国西部区域的 Azure 数据中心，第二集群位于美国中部区域的亚马逊，第三集群位于美国东部区域的谷歌云。 | 三向传送配置。 该配置可以表示为主动-主动。 |
XDR （主动/主动或主动/被动）可以通过控制、灵活性、易管理、更快的写入和区域自治将数据基础架构扩展到任意数量的集群。
新的 XDR 传送算法基于记录的上次更新时间 (LUT)，与早期 XDR 版本中使用的日志记录机制相比，更简单、更有效地管理元数据。基于 LUT 的传送允许从过去的特定时间点开始轻松地重新同步数据中心。此外，新的 XDR 支持任何一对源站点和目标站点之间的动态配置和独立传送。
通常在地理或其他基础上自然分离数据集。在这些情况下，一个区域中需要复制到另一区域的写入与另一站点中的准同步写入发生冲突的可能性非常低。对于可以在弱一致性级别上运行的用例，最好通过处理由应用程序代码内的写入冲突引起的潜在不一致来优化大部分交易的写入时间和读取时间。对于这些用例以及其他用例，XDR 可以支持亚毫秒级的读取和写入延迟。
处理冲突更新
即使在主动-被动设置中，源集群配置为强一致性，仍需要进行元数据交换方面的工作，以确保源（主动）集群中的数据与目标（被动）集群中的数据完全同步。
在主动/主动设置中（上面的示例配置2和3），如果同时对多个站点中的同一数据记录进行并发更新，则复制机制的异步性质可能会导致一致性问题，也称为冲突写入。
假设每次写入都传送了整个记录，则可能会发生不一致。一个站点上的更改记录可以通过 XDR 传输到另一个站点，而另一个站点上的更改记录则由 XDR 同时传送到第一个站点。结果是记录最终在两个集群上具有不同的值，或者两个更新之一丢失（假设某种基于时间戳的冲突解决方案）。
有一些方法可以减轻这种情况。例如，XDR 传送机制可能在 bin 级别工作，除了记录更新时间外，还跟踪 bin 更新时间。这项称为bin 投影的技术将确保同一记录的不同 bin 可以在不同站点上同时更改，而不会破坏数据一致性。应该可以使用 bin 级别更新时间在两个站点上正确合并记录。
即使更改了传送 bin 级别，在多个站点中对同一 bin 进行并发更改也会导致与上述记录级别类似的不一致。我们要么对两个站点的 bin 使用两个不同的值，要么其中一个值将丢失。
通常建议的替代方法是无冲突的复制数据类型 (CRDT)。但是，诸如 CRDT 之类的一致性方法仅适用于一小部分数据类型，通常是计数器和集合，而对大多数其他数据类型没有帮助。网络中断随着距离的增加而放大，并且节点、分区或区域中断，所有这些都会确保发生数据不一致，并且写入将丢失。
在大多数情况下，保证主动/主动 XDR 部署的一致性的一种可能方法是，通过完全避免与特定数据项（记录或 bin）发生冲突的方式设计应用程序的数据访问。
但是，如果允许写入冲突，则应用程序需要容忍某种程度的一致性违规。传送算法的异步特性意味着，当发生站点故障时，其他站点将无法使用发生故障的站点的最新更新。这意味着需要设计和准备应用程序以处理可能的数据丢失。
要进行深入讨论，请观看 Aerospike 工程副总裁 Andrew Gooding 的视频《数据库中的强一致性，它实际上保证了什么？》。
Aerospike 的 XDR 使企业能够创建一个全球数据中心（图4），该中心可自动将数据中心中任何地方捕获的数据路由和扩展到需要的任何地方-无论是在 Aerospike 集群中还是在任何其他数据存储库中。通常，法规遵从性是高度区域性的，新的 XDR 提供了在区域范围内管理法规要求（如GDPR和CCPA）的能力。
总结
Aerospike 可以通过多站点集群或 XDR 在主动/主动配置中运行。
- 运行主动/主动多站点集群可在不丢失数据的情况下保持强一致性，并在站点发生故障时提供 100% 的可用性。但是，根据站点之间的距离，此方案会导致额外的写入延迟，该延迟可能在 2 毫秒到 100 毫秒之间。
- 使用 XDR 运行主动/主动系统可为应用程序提供低延迟的读取和写入，但是在站点故障期间，应用程序可能需要在一致性保证方面做出妥协。此外，需要仔细设计应用程序的数据访问模式，以确保并发写入冲突不会导致应用程序级不一致。
无论数据存储在私有云、公共云还是两者的任何组合中，多站点集群和新 XDR 都可以工作。利用这些功能，客户现在可以根据其业务需求以最有弹性的方式轻松地部署功能强大的关键任务系统。主动/主动拓扑的这种选择为 Aerospike 用户提供了其关键任务应用程序所需的灵活性。