请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

   思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 462|回复: 0

【小目标,一个“译”】+ 双活应用架构与MongoDB的实现(1)

[复制链接]
发表于 2019-3-18 17:39:19 | 显示全部楼层 |阅读模式
引言:本文先分析了在现代多数据中心中应用对于数据库架构的需求。随后探讨了数据库架构的种类及其优缺点,最后给出了使用MongoDB的双活的应用架构
介绍
如今,在跨多个数据中心的应用部署最佳实践中,数据库通常负责处理多个地理区域的读取和写入,对数据变更的复制,并提供尽可能高的可用性、一致性和持久性。但是,并非所有的技术在选择上都是平等的。例如,一种数据库技术可以提供更高的可用性保证,却同时只能提供比另一种技术更低的数据一致性和持久性保证。
本文先分析了在现代多数据中心中应用对于数据库架构的需求。随后探讨了数据库架构的种类及其优缺点,最后专门研究MongoDB如何适用于这些类别,并最终实现双活的应用架构的。
双活的需求
当组织考虑在多个跨数据中心(或区域云)部署应用时,他们通常会希望使用“双活”的架构,即所有数据中心的应用服务器同时处理所有的请求(如图1所示)。该架构旨在可以实现如下目标:
·        通过提供本地处理(延迟会比较低),为来自全球的请求提供服务。
·        即使出现整个区域性的宕机,也能始终保持高可用性。
·        通过对多个数据中心里服务器资源的并行使用,来处理各类应用请求,并达到最佳的平台资源利用率。
“双活”架构的替代方案是由一个主数据中心(区域)和多个灾备(DR)区域所组成的主-DR(也称为主-被)架构。在正常运行条件下,主数据中心处理请求,而DR站点处于空闲状态。如果主数据中心发生故障,DR站点立即开始处理请求(同时变为活动状态)。一般情况下,数据会从主数据中心复制到DR站点,以便在主数据中心出现故障时,能够迅速实施接管。
如今,对于双活架构的定义尚未得到业界的普遍认同。上述主-DR的应用架构有时也被算作“双活”,区别在于从主站到DR站点的故障转移速度是否够快(通常为几秒),并且是否能够自动化(无需人为干预)。在这样的解释中,双活体系架构意味着应用停机时间接近于零。
有一种常见的误解,认为双活的应用架构需要有多主数据库。这样理解是错误的,因为它曲解了多个主数据库对于数据一致性和持久性的把握。一致性确保了能读取到先前写入的结果;而数据持久性则确保了提交的写入数据能够被永久保存,不会产生冲突写入,或是由于节点故障所产生的数据丢失。
双活应用的数据库需求
在设计双活的应用架构时,数据库层必须满足如下四个方面的架构需求(当然,也要具备标准数据库的功能,如具有:丰富的二级索引能力的查询语言,低延迟地访问数据,本地驱动程序,全面的操作工具等):
·        性能 - 低延迟读取和写入操作。这通常意味着:能在本地数据中心应用的节点上,处理读取和写入操作。
·        数据持久性 - 通过向多个节点的复制写入来实现,以便在发生系统故障时,数据能保持不变。
·        一致性 - 确保能读取之前写入的结果,而且在不同地区和不同节点所读到的结果应该相同。
·        可用性 - 当某个节点、数据中心或网络连接中断时,数据库必须能继续运行。另外,从此类故障中恢复的时间应尽可能短,一般要求是几秒钟。
分布式数据库架构
针对双活的应用架构,一般有三种类型的数据库结构:
·        使用两步式提交的分布式事务
·        多主数据库模式,有时也被称为“无主库模式”
·        分割(分片)数据库具有多个主分片,每个主分片负责数据的某个唯一片区
让我们来看看每一种结构的优缺点。
两步式提交的分布式事务
分布式事务方法是在单次事务中更新所有包含某个记录的节点,而不是写完一个节点后,再(异步)复制到其他节点。该事务保证了所有节点都会接收到更新,否则如果某个事务失败,则所有节点都恢复到之前的状态。
虽然两步式提交协议可以确保持久性和多节点的一致性,但是它牺牲了性能。两步式提交协议要求在事务中所有参与的节点之间都要进行两步式的通信。即在操作的每个阶段,都要发送请求和确认,以确保每个节点同时完成了相同的写入。当数据库节点分布在多个数据中心时,这往往会将查询的延迟从毫秒级别延长到数秒级别。而在大多数应用,尤其是那些客户端是用户设备(移动设备、Web浏览器、客户端应用等)的应用中,这种响应级别是不可接受的。
多主数据库
多主数据库是一种分布式的数据库,它允许某条记录只在多个群集节点中一个之上被更新。而写操作通常会复制该记录到多个数据中心的多个节点上。从表面上看,多主数据库应该是实现双活架构的理想方案。它使得每个应用服务器都能不受限地读取和写入本地数据的副本。但是,它在数据一致性上却有着严重的局限性。
由于同一记录的两个(或更多)副本可能在不同地点被不同的会话所同时更新。这就会导致相同的记录会出现两个不同的版本,因此数据库(有时是应用本身)必须通过解决冲突来解决该不一致的问题。常用的冲突解决策略是:最近的更新“获胜”,或是具有更多修改次数的记录“获胜”。因为如果使用其他更为复杂的解决策略,则性能上将受到显著的影响。这也意味着,从进行写入到完成冲突解决机制的这段时间段内,不同的数据中心会读取到某个相同记录的不同值和冲突值。

相关阅读:
【小目标,一个“译”】+ 双活应用架构与MongoDB的实现(2)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2019-6-24 20:30 , Processed in 0.092973 second(s), 34 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表