为了应对地震、火灾等不可抗力导致本地备份数据丢失的情况，业界提出了异地灾备的技术理念。CPDR （Control Plane Disaster Recovery，控制平面灾备）是一种应用在vBRAS转发与控制分离组网中的异地 灾备技术。它通过在两个分属于不同DC（Data Center，数据中心）的CP之间进行双机备份来实现异地灾备， 从而达到当一个DC发生灾难时，由另一个DC快速接管用户业务的目的。
灾备： 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务7*24小时连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
企业业务敏感程度差异，对容灾指标RPO&RTO要求也不同。之前两篇文章主要介绍数据冷备，主要特点是数据备份存储非实时，备份系统存储数据通常昨天的数据，当灾难真正来临的时候，今天新产生的数据会丢失情况。对于企业核心业务来讲，业务恢复（RTO）可以接受小时级别，但是对于数据无法接受丢失，即RPO接近为“零”。结合腾讯云数据备份能力，本文重点介绍数据热备解决方案，旨在让客户上好云，用好云，管好云。
业务容灾是所有容灾中最复杂的一种场景，涉及到业务应用、中间件、数据库及底层的计算、存储、网络等资源。就云上业务容灾来讲整个容灾覆盖到IaaS、PaaS、SaaS层。在容灾方案确认并且实施落地之后，就需要进行容灾切换演练工作。下面主要介绍下容灾切换演练的流程及具体操作细节。
陈守志 腾讯公司平台运营开发组 一、关于容灾 关于容灾主题，这里罗列对比了几种常见的容灾案例： 相对接入层、应用层容灾而言，数据层的容灾相对比较复杂，实现起来难度大一些，下面主要针对公司
在当今快速发展的数字化时代，业务的连续性和稳定性已成为企业核心竞争力的重要组成部分。然而，由于各种原因，企业常常面临着数据丢失、系统瘫痪等潜在风险。因此，制定一套科学、高效的容灾方案至关重要。本文将围绕某全球领先的工业集团如何通过灵雀云企业级云原生平台ACP（以下简称ACP）实现高效的容灾方案展开深入探讨，旨在为您提供可借鉴的经验和启示。
业务数据备份采用热备方式，容灾指标RPO接近“零”；但是RTO指标还是依赖于业务部署测试自动化能力。业务会进一步需要，在数据热备技术架构下，在成本可控的情况下，是否能进一步提升RTO指标呢？ 本文结合云平台的能力，来进一步讨论这个话题。
越来越多的企业在数字化转型和上云进程中选择混合云的形态（云+自建 IDC 或云+其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下 IDC 资源。
在数字化转型的热潮中，业务数据无疑是企业的生命线。无论业务部署在IDC还是云平台，对数据备份都是有强烈诉求。随着共享经济的不断深化，越来越多企业将自身业务逐渐的搬迁到了云上。为了让企业能更好用好云平台的数据安全能力，本文重点云平台数据备份冷备能力，以腾讯云为例，主要从以下两个维度介绍：
今天跟大家分享的题目为《CKV+异地容灾探索和实践》。CKV+是一个兼容redis协议的内存数据库，现在大部分用户对内存数据库的要求越来越高，对一致性、异地容灾等方面也提出更高的要求。下面从过往经验教训、可用性&一致性、CKV+架构演进、CKV+单活多可用区和CKV+多活架构探索等方面跟分享一些关于容灾的实践和思考。
当下，随着数字化技术不断深入，愈来愈多企业将核心业务搬到线上。业务系统高可用、可扩展、容灾能力决定企业系统的连续性，中间件作为构建企业核心系统的重要组成部分，其高可用容灾能力也将决定应用系统的。本文结合腾讯云中间件各PaaS产品的容灾能力及实践，以一个行业头部客户业务容灾实践举例，来展开说明基于腾讯云中间件PaaS层相关产品的实践。
不论是自然灾难还是人为灾难，只要有数据传输、存储和交换的地方，就会产生数据失效、丢失、损坏等风险，一旦发生，就会给数据中心带来难以估计的损失；而灾备，是一种对业务数据安全的重要保护方式。
风险无处不在，包括自然灾害以及突发事件等，有时候我们无法预测到一些风险，比如天津港爆炸事件。IT领域也一样，总是有意想不到的事情，风险具有不可预测性，万全之策就是做好灾难应对的各种准备。
容灾体系能否第一时间恢复数据成为容灾体系是否合格的核心指标，对于业务连续性来说也至关重要。腾讯云数据库灾备解决方案的最佳复原时间目标（RTO）也降低到秒级，彻底解决单机房网络、光缆挖断等不可控故障给业务带来的长时间停服不可用。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类： 1、必须同步型。（比如数据库） 2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。 3、只能单活（对全局原
大数据时代，NoSQL数据库是企业构建数据能力的核心工具之一。近期，在2022腾讯全球数字生态大会NoSQL数据库专场上，腾讯云发布了多项NoSQL产品能力升级，并重点讲解了其背后的自研技术要点及实现细节，分享了腾讯云NoSQL为广大企业提供的高可靠、高效率、低成本的企业级特性及行业解决方案。 开场演讲中，腾讯云数据库高级产品经理佘春明分享了当前NoSQL在企业应用方面的趋势与挑战。近年来，Redis已成为全球最受欢迎的NoSQL数据库之一，而随着业务的不断运营、发展，兼容Redis协议的海量KV存储需求越
随着业务对持续性要求越来越高，云上不少企业对跨AZ或多地域的容灾建设有强烈的诉求。当企业内部经过评估选定容灾建设整体方向，即同城双活；需要对方案进行验证，包括组件容灾能力建设，数据同步以及切换验证等。通常对组件容灾能力建设和验证会花费大量时间，如果测试不符合预期，对之前调研、部署以及测试人力和时间成本带来较大耗费。因此借助云平台能力“一站式”提升系统容灾能力，助力企业降本增效。
下文以腾讯云数据库 MySQL为例，介绍如何充分利用腾讯云的优势，减轻DBA的负担，轻松来搭建数据库。
为了保障系统可用性， 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害， 发生的频率一次降低。
乐元素是国内休闲益智游戏领域领航企业。为了给用户提供更稳定可靠的使用体验，在2023年Q2开始，乐元素运维、业务团队联合腾讯云售后专家和技术专家，基于针对乐元素旗下休闲游戏产品《开心消消乐》展开同城双活改造项目，目的是了解并改善业务容灾部署状况，进一步强化云上业务系统的容灾能力。
采用高可用系统架构支持重要系统，为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
实现业务连续性的技术手段通常包括高可用性和灾备恢复两种，所以本文讲述的是在腾讯云上实现业务连续性的解决方案。
说起容灾，很多同学脑子冒出来熟悉字眼，”同城双活”，“两地三中心”，“单元化”，“set化”等等。其实这些名词背后均隐射一层含义，面对一些灾难时候，业务如何做冗余来快速恢复业务。
来源：https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理
随着企业对数据处理和存储需求的不断增长，Redis作为一款高性能的内存数据结构存储系统，已成为业界的首选。然而，在Redis中的使用中，会面对一些潜在的故障风险，其中主节点故障，发生主从切换最为常见。
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里
点击上方蓝色“程序猿DD”，选择“设为星标” 回复“资源”获取独家整理的学习资料！ 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存，比如MySQL数据库，redis等内存数据库。除了这两种类型的维护方式，还有jvm的内存的状态维持，但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个
同城异地灾备，主要是用来进行备份容灾的，从而当一个数据中心挂了，另外一个数据中心经过切换之后，能让服务迅速的恢复。
为帮助开发者更好的了解和运用数据库，腾讯云数据库团队特出品《深入浅出理解云数据库》系列文章，从数据库的基本概念到云数据库特性及应用，从数据库基础原理知识到腾讯云经典实战案例解读，带你走进云数据库的世界。关注“腾讯云数据库”微信公众号，开启2020年的DB修炼之旅。 第一回请点击：数据库的基本概念和云数据库特性 第二回请点击：云数据库的市场应用及基础原理知识 1 PartⅠ 腾讯云数据库产品总览 接下来的章节中我们以腾讯云数据库为例，来详细解读云数据库的功能和特性等。 首先来让我们用一张表来看清楚腾讯
业务应用层是整个系统流量枢纽，核心业务存在单点或者自愈能力弱，都会造成严重影响业务稳定性。例如，核心业务模块和非核心业务模块高度耦合，从资源成本上来考虑，实际上并不是所有业务均需要做容灾建设，需要加入人力成本对业务进行改造；如果对于延时敏感业务，无法接受跨区延时，需要投入更多人力来进行架构和业务上改造。综上所述，本文从云平台视角出发阐述应用层业务容灾建设，主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。
本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望，抛砖引玉，吸引更多优秀的想法。
墨菲定律，鸡蛋不能放在同一个篮子中。数据库是最重要的资产，出现单点故障确实不可避免，我们应提前做到数据库备份，出现故障时能够快速恢复。
其实，TencentDB已经和珍爱网“隐婚”数年了，请允许我正式向大家介绍我的“另一半”：
上面有说到，持久化的核心作用是为了故障恢复，既然redis可能故障，机器同样也会故障；就算是数据落到磁盘了，同样也可能因为磁盘故障，导致数据丢失；如上图！为了做好一个企业级的持久化方案，我们需要将持久化文件定期同步到云端或者远端的服务器，做好分布式存储，来防止因为机器故障带来的灾难性数据丢失。
本文章提供视频讲解，详细见地址：https://www.bilibili.com/video/BV1uC4y1h7nN
会控为整个会议最为核心的业务，由于海量请求的高性能要求，后台存储全部为 Redis。在业务飞速发展期，各模块边界不够清晰，大家对存储的使用处于失控状态，随着 PCU 的不断上涨，逐步暴露出存储和架构的诸多问题，同时也对系统容灾能力有了更高的要求。会控业务历史包袱重，存储改造伤筋动骨，要做到平滑迁移需要考虑的细节较多。有幸作为 owner 负责(2022.12-2023.08)了会控存储的优化改造，本文主要从业务、个人和企业数据分库、异地容灾和多活（下一步目标）层面总结了会控存储治理的成功实践，目的是形成一套方法论，沉淀下来一套可以复用的工具，以供大家后续工作中参考。
在日常开发中会经常遇到一些需要异步定时执行的业务诉求，典型的使用场景如：超时未支付订单关单、每隔 2h 更新好友排行榜、3.22 日 17 点《xx》剧上线等。目前业务侧多基于以下思路来快速搭建一个调度系统，mysql 或者 redis 队列存储待执行任务，通过 crontab 定时触发应用完成“捞取、计算、执行等操作”。不难看出存在几类亟待解决问题：
相对于过去单体或 SOA 架构，建设微服务架构所依赖的组件发生了改变，因此分析与设计高可用容灾架构方案的思路也随之改变，本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
本文将主要首先聊一聊数据库同步和迁移两个话题，之后将会围绕这 2 个话题介绍一下阿里云开源的基于 MongoDB 和 Redis 的数据同步&迁移工具 MongoShake 和 RedisShake，最后介绍一些用户的使用案例。
随着客户上云的加快，客户越来越希望直接采用云上的数据库系统支撑业务发展，作为服务商来讲，了解云上的数据库的应用场景及常见特性成为必然。否则，将出现与客户交流困难，影响项目成效的麻烦事。今天我们讲五种常见的云数据库，这些内容也是在与客户沟通交流中的常见问题。
腾讯云上有许多种数据库产品，本文简单介绍每种产品的介绍，特性，应用场景等，帮助各位根据业务需要选择最适合的数据库。
在CRM领域，有一个名字听起来特别“亲切”的品牌—— “销售易”， 它是连续三年入选Gartner SFA全球魔力象限，并且是首家且唯一一家入选该魔力象限的中国CRM企业。
9月10日下午，又一起规模化利用Redis未授权访问漏洞攻击数据库的事件发生，此次黑客以勒索钱财作为第一目的，猖狂至极，攻击者赤裸裸威胁，直接删除数据库数据。腾讯云安全系统在攻击开始不到30s就启动全网拦截。
互联网公司发展到一定的规模，系统的高可用就变得极其重要。为了应对那些随时可能发生的意外，“多活”在如今互联网公司好像变得是必备的手段了。甚至一些公司发生一些 P0 事故之后，多活也会出现在 case study 的列表之内。
通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。
在业务系统上云的过程中，业务部署的高可用和容灾是一个要考虑的关键因素。如今很多系统都采用分布式的架构，从架构层面避免单点故障。分布式系统中，任意一个节点故障，其他节点可以快速接管业务，避免整个业务系统宕机。 这就对IaaS层资源提出了要求，即单节点故障，不影响其他节点。 由于公有云是一个多租户的环境，一台物理机上会运行多个虚拟机，如果分布式系统的多个虚拟机落到了同一台物理机上，当物理机发生故障时，多个分布式节点同时故障，就有可能造成整个系统宕机。 那么在公有云的IaaS层，如何才能保证分布式系统部署的高可用呢？ 使用腾讯云的分散置放群组可以解决这个问题。
导语 | 缓存+存储的系统架构是目前常见的系统架构，缓存层负责加速访问，存储层负责存储数据。这样的架构需要业务层或者是中间件去实现缓存和存储的双写、冷热数据的交换，同时还面临着缓存失效、缓存刷脏、数据不一致等问题。本文是对腾讯云数据库高级产品经理邹鹏老师在「云加社区沙龙online」的分享整理，希望与大家一同交流~ 点击视频，查看完整直播回放 前言 在互联网和移动互联网两波浪潮的推动下，存储技术有了飞速发展。移动互联网用户在过去十年增长了10倍，用户的增长带动了数据量的指数级增长，因为激烈的市场竞争，企
在互联网和移动互联网两波浪潮的推动下，存储技术有了飞速发展。移动互联网用户在过去十年增长了10倍，用户的增长带动了数据量的指数级增长，因为激烈的市场竞争，企业和用户对应用程序的响应性能要求越来越高，在完美应对庞大的用户规模和海量数据集的同时保证优秀的产品体验，是数据库面临的挑战。
Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。
我们先直接看架构图，给同学推荐是使用CDN加速、WAF应用防火墙+DDOS防护、CLB负载均衡（多可用区属性）、多可用区云主机、数据库（多可用区主备+异地灾备）。具体架构如图：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
