双活无共享数据库架构( 五 ) _数据库架构

无状态与有状态应用Jane解释说，设计的关键是一个问题：应用程序是无状态的还是有状态的？
通常，应用程序在单个执行线程中与数据存储进行多次交互。它需要数据库来维护应用程序的状态，还是应用程序需要对其进行跟踪？或者，应用程序是否假定每个数据库调用都独立于另一个？如果是后者，则称为无状态应用程序。使用Active-Active Shared-Nothing数据层更容易实现无状态应用程序。
简解释了这些模式：
模式1：许多主节点，但只有一个活跃

文章插图

数据存储区都是主数据库，即复制在它们之间双向进行。但是，Jane警告说，只有一个数据存储被标记为"活动" 。如果失败，则可以使另一个主机处于活动状态；但在给定的时间点上只有一个处于活动状态。通过确保所有人都是主节点，我们可以改善掉电时间。通过让一位主节点成为主动，我们消除了冲突的可能性和相关的风险。
"您说过，我们改善了掉电时间，"黛比说，"并没有消除它们。为什么？"
简解释说："那是因为复制是异步的，从而使另一个主复制可能滞后，甚至少或甚至为零。"
模式2：一位主节点和许多待命者（读者）

文章插图

我们仅创建一个主节点，但创建多个副本以用于只读访问（因此不会在其中进行任何更新）。有些应用程序是纯只读的，可能会与任何读者相抵触。灾难发生后，我们可以将其中一位读者转变为一位读者，并将交易指向该位读者。由于没有主动-主动数据库，因此我们消除了冲突的可能性。但是，简警告说，激活读者需要一些时间。因此掉电时间比以前的模式要长一些。
模式3：一个写入和许多读出

文章插图

这是上面显示的两种方法的组合，但有所不同。所有数据存储都是主数据，并且是主动-主动模式；但其中一个（数据库F）是一个超级主数据库，称为"进纸器"数据库。所有应用程序都连接到所有数据库并进行更新。为了保持一致性，为Feeder数据库分配了很高的权重，这使它自己的更新更多，并传播到其他主数据库。其他主节点也可以更新，但不那么频繁。简警告说，发生冲突的机会很小，但并未完全消除。如果存在冲突，则Feeder数据存储区中的更新将覆盖本地更改。
模式4：许多主节点，但根据应用程序进行了更新

文章插图

Jane opines，这可能是AASN的最实际用法。这里所有的数据库都是主数据库，但是我们没有使用数据库复制策略，而是使用应用程序直接更新它们。
Jane提请听众注意数据库D1和D2之间没有复制的事实。该应用程序独立更新两个数据库。由于没有数据库级别的复制，因此没有冲突的可能性，因此也没有随之而来的风险。就数据库技术而言，每个数据库都是单一的，即没有其他分区。因此CAP定理不适用。
模式5：多个主缓冲写入

文章插图

Jane指出，模式4提出了一个不同的问题，因为数据库写入的次数很多。在获得所有数据库的确认之前，该应用程序无法继续。这可能会增加延迟问题，尤其是在应用程序是数据库聊天的情况下。为了解决这个问题，在模式5中，我们在两者之间使用了一个消息传递层。应用程序流传输到消息传递层而不是数据库。一个单独的过程从消息传递层中将其提取并写入多个主数据库。当对消息传递层的写操作完成时，应用程序将获得确认，因此它非常快。
黛比显然对这种模式感到兴奋。但是Jane警告说，虽然听起来比较简单，但是却增加了两个风险：
· 总体数据可用性有更多的延迟。当应用程序提交时，数据不会写入数据库。它是在其他进程将其拾取并写入数据库时写入的。
· 不能保证写入数据的顺序；因此可能存在数据一致性问题。
由于这些限制，Jane解释说，此模式最适合静态或不常更改的内容（缓存和参考系统），而不适合记录系统。
休会综上所述，Jane得出结论，"主动-主动-共享-无"数据库层体系结构的成功取决于数据库的类型，其使用情况以及应用程序处理数据更新冲突的能力和意愿。在数据库级别开启双向复制绝不是一个简单的情况，并且期望应用程序对此一无所知。通常，"记录系统"数据存储区最难实现，而"会话状态"数据存储区最容易。因此，Acme可以在许多系统上在数据库层上实现AASN，而无需更改应用程序，对于有些应用程序需要更改，而对于某些应用程序则完全不需要。对于某些类型的系统，在数据层中也不需要AASN，同时可以实现高可用性。