后台开发必备知识——容灾

关于容灾

后台开发的目标是要提供高可用的后台服务,其中很重要的一点是保证业务连续性(服务不中断,或中断时间在允许范围内)。

要保证业务连续性,系统需要具备容灾能力。

所谓容灾,就是对灾难(disater)的容忍能力,即在灾难袭来时,能够保证信息系统正常运行而采取的措施,以实现业务连续性为目标。

容灾的实现通常都涉及到冗余,比如做最简单的主备。、

容灾的不同层级

根据冗余对象,容灾大致可以分为以下几种层级

容灾的不同层级
  • 数据级容灾: 数据备份,如建立异地容灾中心做数据远程备份(只备份数据,没有备用系统可切换)
  • 应用级容灾: 在数据容灾基础上构建一套功能相同的系统,可做系统切换。
  • 业务级容灾:在应用容灾基础上,增加了IT系统以外的容灾。如备用办公地点,系统相关文档等。

一般系统设计

容灾的评价指标

容灾系统有三个重要的评价指标

  • 灾难检测: 具备容灾能力的系统需要能够检测出是哪个子系统、组件发生了灾难,以便决策解决方案(灾难恢复)
  • 容灾切换: 系统检测到某个子系统、组件故障后,要具备把流量切换到其它具备相同能力的子系统上去。
  • 数据一致性: 同功能的不同子系统(主备)之间的数据要保持一致。灾难恢复后的业务应该不受影响。理论上用户对灾难是无感知的。
容灾评价指标

容灾的解决方案

双活

双活是指在两个生产中心部署相同的两个能力相同的业务系统。两个系统同时工作,地位对等、不分主从。具备在对方系统灾难发生时,接管对方业务的能力。

双活通常需要负载均能技术的支持。

多活与双活区别在生产中心的数量上。

双活有同城双活异地双活, 主要是地理位置上的区别。

灾备

这里灾备是指具有主从之分的灾备系统。(双活是不分主从的灾备)。

通常是建立一个主业务系统和一个从属(备用)的业务系统(可能只有数据中心),正常情况下仅有主业务系统在工作。在主业务系统故障时,在启用备用系统。

灾备有热备、冷备等方式

  • 热备: 备用数据中心对主数据中心的数据实时备份。在容灾切换时,业务不会中断。
  • 冷备: 备用数据中心只是对主数据中心的数据进行定期备份(或者异步备份)。在容灾切换时,业务可能会中断。

热备和冷备的成本要考虑是仅做数据中心备份,还是有业务系统的备份。如果仅仅是数据的备份,那么其成本主要是存储设备的成本(硬盘);如果做了业务系统的备份,则成本与双活差不多,而且由于备用系统长期不工作,会造成资源浪费。

两地三中心

两地三中心是指在同城和异地同时建立灾备中心。

同城灾备中心通常采用热备的方式,并一般会提供业务服务。异步灾备中心知识做数据的备份,且数据的复制是异步的。异步灾备中心平时不提供业务服务。

两地三中心

容灾系统的设计

容灾系统的设计不是一成不变的,不同的应用场景通常会有一些定制化的设计。因为容灾是经常是基于服务冗余实现的,大而全的容灾系统具有较大的成本。

但是容灾有一些比较通用的设计模型。

常见的四层容灾设计

四层容灾设计
  • 接入层:负责流量的接入和路由。
  • 控制层:负载均衡、节点管理等
  • 业务层:处理请求,负责具体的业务逻辑,可能设计数据的读写。
  • 落地层:数据的落地存储

灾难检测可以在控制层或业务层。

本文所介绍的容灾主要是业务层以下的容灾

容灾的实现细节

容灾的内部实现是多种多样的,不同的公司可能都有自己的实现技术。下面知识介绍一些案例、或常用的实现。主要是为了阐述可能的实现原理,不一定适用所遇场景。

灾难检测

容灾系统通常是一个集群,集群中有多个节点,通常是一个主节点(Master)和一个以上的从节点(Slave)。

灾难探测可以通过心跳包实现。

主节点和从节点分别向控制层上报心跳,如果控制层收不到某个节点的心跳,则认为其不可用,对主节点降级,并把流量切到从节点。

更为严谨的做法是,节点之间也互相上报心跳,这样可以做孤岛检测。

灾难检测

容灾切换

容灾切换主要是把流量从一个节点切到其他节点。可以通过负载均衡等系统实现。

数据一致性

数据一致性是要保证各个节点的数据一致,这样在主节点故障,切换到其他节点时才能保证业务不中断,不受影响。

在业务处理过程中,可能涉及到频繁的数据读写,有些业务请求需要等待写成功后才能返回给用户。要保证各个节点的数据在存储落地时一致,需要等到所有节点都写成功后在返回,这就涉及到**同步写**。

按上面的逻辑,为保证数据一致性,客户端、主节点和备用节点会发生以下交互。

数据一致性时序图

由于Master和Slave在地理位置上可能相隔较远,因而这种同步写的方式有可能造成一定的延迟,影响系统性能,增加了请求的响应时间。

为了减少延迟(减少容灾对系统性能产生的影响)可以对数据一致性的实现做一些改进。

下面介绍两种改进方式。

  1. 数据分级,允许不重要数据少量丢失。
  2. 优化设计,变同步为异步。

数据分级的方式,主要是减少需要同步写的对象,对不重要的数据,允许在一定程度内丢失。

然而在很多场景下,数据分级的方式并不适用。

第二种方式是现在常用的保证数据一致性,又降低对系统性能影响的方式。在这种设计下,增加了一个组件(注册中心)用于登记写事件。

Master在存储数据时,先到注册中心登记下,然后再进行写动作,同时通知Slave需要复制数据。Master在写动作完成后即可返回给client,不需要等到Slave写动作完成。也就是Slave是以异步的方式从Master那里复制数据。

那么这种设计如何保证数据一致性呢?

  1. Master在注册中心登记了写事件,Slave可以与注册中心校验与Master是否数据一致。
  2. 验证结果为数据一致,不需要额外处理。
  3. 验证结果为数据不一致,则尝试从Master复制未写的数据。 
  4. 尝试复制成功,则数据同步完成。
  5. 尝试复制失败,则通知注册中心回滚(做下标志),同时通知客户端上次写事件失败,需要重新发起请求。

时序图:

容灾一致性实现优化

注册中心的登记同样是同步动作,为何能降低性能? 

  1. 注册写事件涉及到的数据内容通常远小于业务数据。
  2. 在多节点时,写时间的注册比各节点的数据同步要快很多。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JAVA高级架构

电商平台备战促销季的运维秘诀——高可用服务层

1262
来自专栏服务端技术杂谈

动手撸一个规则引擎

最开始听说过规则引擎可能是一个类似于OA的系统中,通过规则配置,让一个审批流程得到配置化和规则化。

1914
来自专栏北京马哥教育

大型网站的灵魂——性能

Via: http://blog.jobbole.com/84433/ 前言 在前一篇随笔《大型网站系统架构的演化》中,介绍了大型网站的演化过程,期间穿插了一...

3436
来自专栏Linyb极客之路

理解分布式系统中的缓存架构(下)

承接上一篇《理解分布式系统中的缓存架构(上)》,介绍了大型分布式系统中缓存的相关理论,常见的缓存组件以及应用场景,本文主要介绍缓存架构设计常见问题以及解决方案,...

1111
来自专栏重庆的技术分享区

创建一个微服务?首先回答这10个问题

原文地址:https://articles.microservices.com/creating-a-microservice-answer-these-10-...

2942
来自专栏battcn

为什么要前后端分离?有什么优缺点?

前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型...

4262
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

1631
来自专栏ImportSource

微服务应具备的12个属性

该文翻译自Pivotal公司的 Matt Stine大牛的书籍《Migrating to Cloud Native Application Architectu...

2859
来自专栏叁金大数据

存储是怎样炼成的?

什么FAT,NTFS,NFS,DAS,SAN,NAS,OSD这些名词我一个都不认识。

1763
来自专栏后端技术探索

纯干货--秒杀系统架构分析与实战

(1)查询商品;(2)创建订单;(3)扣减库存;(4)更新订单;(5)付款;(6)卖家发货

3554

扫码关注云+社区

领取腾讯云代金券