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


观众敦促她扩大应用程序需要做的事情 。Jane继续:应用程序需要了解AASN数据库层的三个约束:
· 最终,不是立即,一致的数据存储 。
· 由于两个副本中同一记录中发生更改,因此可能存在冲突 。
· 由于一个更新在另一副本的更新发生冲突之后延迟更新,因此可能导致数据损坏 。
传统方法简继续讲述这些方法 。首先,她谈到了主动/被动无共享(APSN)架构,并强调了"被动"一词 。这是数据库层中传统上公认的APSN架构视图:

双活无共享数据库架构

文章插图
 
在此图中,A1和A2是分别在区域R1和R2中运行的同一应用程序的两个实例,并连接到数据库D1(主数据库)和D2(备用数据库) 。数据库D2是D1的热备用数据库,它通过某种类型的数据库复制技术不断更新 。当区域R1发生故障时,结果数据库D1发生故障 。数据库D2仅承担主要数据存储区的责任 。区域R1发生故障后,D2成为主要区域,应用程序负载平衡器将流量发送到该区域 。在任何时间点,主数据只有一个副本 。
双活无共享数据库架构

文章插图
 
掉电期但是,在负载平衡器可以将流量发送到应用程序A2之前,它必须确保备用数据库已完全适应对数据库D1所做的更改 。无论多么小,该时间段仍可被应用程序感知到,称为欠压期 。简解释说,电力不足的持续时间完全取决于对数据库D1所做的更改,在无活动或活动较少的时间段内可能为零 。
但是,观众想知道,是否可以消除掉电期?
简明确指出,可以消除数据库层的限电期 。但是为了确保同步不落后,复制必须是同步的 。虽然这听起来不错,但实际上它有两项惩罚,我们必须考虑:
· 由于必须使用非常低延迟的介质来传输数据,因此它通常非常昂贵,尤其是跨区域时 。
· 这会增加应用程序的性能开销,因为在将提交响应发送到应用程序之前,数据库必须从D1和D2都获得确认 。
因此,数据库复制通常是异步的,因此某种程度的掉电是不可避免的 。
热备这使期望快速回答的听众的情绪受到抑制 。简继续叙述 。区域R1恢复后,将开始反向复制 。
双活无共享数据库架构

文章插图
 
Jane提请观众注意以下事实:在这种体系结构中,只有一个"主"数据副本 。另一个副本始终只是备用副本 。这消除了数据存储之间发生冲突的任何可能性 。另一方面,Active-Active Shared-Nothing数据存储区假定两个数据存储区始终都是主存储区,并且复制双向进行,而应用程序负载平衡器向这两个方向发送流量 。这样,当区域R1出现故障时,负载均衡器仅停止向该负载均衡器发送流量,而D1中的所有更改都已在D2中可用,因此没有掉电期 。
双活无共享数据库架构

文章插图
 
"太棒了!"宣布激动的特德 。"为什么我们不能仅将数据存储从主动-被动共享-无转换为主动-主动共享-无?为什么我们需要更改应用程序?"
简解释道,这就是问题所在 。根据应用程序打算执行的操作,它可能根本无法运行,或者可能在无提示数据损坏的情况下运行 。这就是我们要提防的问题 。
这两个词像空中的剑一样悬在空中,"可能无法运行"和"无声的数据损坏" 。
"请解释,"特德对此很感兴趣 。
但是在进一步解释之前,Jane希望读者了解数据管理的一些基础知识 。
CAP定理Jane提出了一个供听众思考的问题:"当我们将相同数据的多个副本存储在两个数据存储中以解决单个副本的故障时,当一个副本发生故障时会发生什么?"其他副本是否处于可以立即承担故障操作的状态?它们可能会,也可能不会,取决于架构 。这就是CAP定理的规则-一致性,可用性和分区容限(https://en.wikipedia.org/wiki/CAP_theorem)—出现的地方 。
一致性:如果不同数据存储中有多个数据副本,那么它们是否在任何时间点都彼此100%同步?如果这样,他们需要一个高速,低延迟的网络 。但是由于现在从所有数据存储中获取提交确认的时间越来越长,因此会对应用程序的性能产生负面影响 。
可用性:如果一个数据存储不可用,则其他副本可以接管该应用程序以使其获得非错误响应的方式 。请记住,这仅仅是数据存储区对应用程序的响应 。那里可能没有最新的更新 。


推荐阅读