物理距离必然导致数据不一致,这就得从“数据”特性来解决,如果是强一致性要求的数据(如存款余额),就无法做异地多活。 保证核心业务的异地多活 思维误区:要保证所有业务都能异地多活。 解决的方法就是:优先实现核心业务的异地多活。 只保证绝大部分用户的异地多活 思维误区:要保证业务 100% 可用。 物理规律决定了异地多活无法保证100%的业务可用。 所以,无法做到实时转账的异地多活,需要通过特殊业务受到实现。
1 简介 在软件开发领域,异地多活是分布式系统架构设计的一座高峰,很多人经常听到过他,但很少人理解其中的原理; 异地多活到底是什么?为什么需要异地多活?它到底解决了什么问题? 这些疑问,想必是每个程序看到异地多活这个名词时,都想要搞明白的问题。 认真读完这篇文章,我相信你会对异地多活架构,有更加深刻的理解。 12 异地多活理解了异地双活,那「异地多活」顾名思义,就是在异地双活的基础上,部署多个机房即可。 虽然物理上是两个机房,但「逻辑」上还是当做一个机房来用6、两地三中心是在同城双活的基础上,额外部署一个异地机房做「灾备」,用来抵御「城市」级别的灾害,但启用灾备机房需要时间7、异地双活才是抵御「城市」级别灾害的更好方案 值得提醒你的是,只有真正理解了「异地双活」,才能彻底理解「异地多活」。
应用场景 顾名思义,异地多活架构的关键点就是异地、多活,其中异地就是指地理位置上不同的地方,类似于“不要把鸡蛋都放在同一篮子里”;多活就是指不同地理位置上的系统都能够提供业务服务,这里的“活”是活动 单纯从异地多活的描述来看,异地多活很强大,能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务,我们都要去实现异地多活架构呢? 因此,异地多活虽然功能很强大,但也不是每个业务不管三七二十一都要上异地多活。 基于这个分析,跨城异地多活是架构设计复杂度最高的一种,接下来将介绍跨城异地多活架构设计的一些技巧 技巧1:保证核心业务的异地多活 “异地多活”是为了保证业务的高可用,但很多架构师在考虑这个“业务”时 核心思想 异地多活设计的理念可以总结为一句话:采用多种手段,保证绝大部分用户的核心业务异地多活!
为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地多活系统。主要介绍在我们在异地多活系统的实践。 JDHBase异地多活架构 JDHBase服务端与客户端交互主要包含三个组件:Client、JDHBase集群、Fox Manager。 我们对可靠性要求比较高的业务做了异地多活备份。 ? Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。 实际生产中,我们根据两个建群间的Replication,构建了多集群间的Replication拓扑,使得集群互为主备。 总结与展望 JDHBase在不断吸收业界异地灾备经验的同时,也经过一系列的实践和演进,目前SLA已经能够达到99.98%,从毫无异地容灾措施到完善的监控、告警、切换、一致性保障机制,为业务提供稳定可靠的存储服务
服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。 例如,企业内部的 IT 系统、管理系统、博客站点等,如果无法承受异地多活带来的复杂度和成本,是可以不做异地多活的,而对于重要的业务例如核心金融、支付、交易等有必要做多活。 2、多活方案 常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案,不同多活方案技术要求、建设成本、运维成本都不一样,下面我们会逐步介绍这几种多活方案并给出每种方案的优点和缺点。 四、异地多活 异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种,与传统的灾备设计的最主要区别在于“多活”,即所有站点都是同时在对外提供服务的。 这类数据部署情况像下面这样 6、方案评估 优势 容灾能力大幅度提高,服务异地多活,数据异地多活。 理论上系统服务可以水平扩展,异地多机房突破大幅度提升整体容量,理论上不会有性能担忧。
高可用的一些解决方案 高可用,从发展来看,大致经过了这几个过程: 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候,还是先看一些其他的方案,这有利于我们理解很多设计的缘由。 实际上,异地双活和异地多活已经很像了,双活的结构更为简单,所以在程序架构上不用做过多的考虑,只需要做传统的限流,failover等操作即可。但其实双活只是一个临时的步骤,最终的目的是切换到多活。 因为双活除了有数据冲突上的问题意外,还无法进行横向扩展。 异地多活 根据异地双活的思路,我们可以画出异地多活的一种示意图。每个节点的出度和入度都是4,在这种情况下,任何节点下线都不会对业务有影响。 如果我们已经将异地多活的业务部署为上图的结构,很大程度解决了数据到处同步的问题,不过依然会存在大量的冲突,冲突的情况可以简单认为和双活差不多。那么还有没有更好的方式呢? 相对而言,饿了么的多活方案可能更适合大多数的企业。 本文只是通过画图的方式进行了简单的描述,其实异地多活是需要很多很强大的基础能力的。
异地多活到底是什么?为什么需要异地多活?它到底解决了什么问题?究竟是怎么解决的? ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双活 两地三中心 异地双活 异地多活 系统可用性 让我们从最基础的开始往上垒。 ---- 异地双活 按照上面的思路,只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗? 因为是异地,两个机房之间的专线也将升级为 跨域专线 了。 例如系统配置、商品库存这类需要强一致的数据,这类服务依旧只能采用写主机房,读从机房的方案,不做双活。 == 双活的重点,是要优先保证「核心」业务先实现双活,并不是「全部」业务实现双活。 == ---- 异地多活 理解了异地双活,那「异地多活」顾名思义,就是在异地双活的基础上,部署多个机房即可。
如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。 今天我来聊聊异地多活架构,以及异地多活架构的设计技巧和流程。 应用场景 顾名思义,异地多活架构的关键点就是异地、多活,其中异地就是指地理位置上不同的地方,类似于“不要把鸡蛋都放在同一篮子里”;多活就是指不同地理位置上的系统都能够提供业务服务,这里的“活”是活动、 单纯从异地多活的描述来看,异地多活很强大,能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务,我们都要去实现异地多活架构呢? 因此,异地多活虽然功能很强大,但也不是每个业务不管三七二十一都要上异地多活。 设计跨城异地多活架构 我们讲完了异地多活设计的核心要点,下面我们谈一下如何设计跨城异地多活架构。
引言 在异地多活项目整体推过程中的一些注意事项和设计点归纳和整理,抛砖引玉,其中一些点还有待深入探讨和优化。 一、指导事项归纳 1.多活原因归纳 推动多活的原因大体可归纳为以下三种。 核心链路自包含可逻辑分片 调用尽可能收敛在本单元 流量分片逻辑尽可能均衡 中间件多活架构改造升级 业务改造支持多活方案 业务场景验证中间件能力 3.推动事项归纳 顺利推进多活事项是公司重要战略,需要统一思想 ,将多活项目当成最高优先级推进。 ,归纳了以下几种方式: 终端服务通过多域名切换:将请求直接路由到正确机房 在反向代理层转发:转发属于异地机房流量 在网关层转发:转发属于异地机房流量 3.多活管控中心服务 多活部署通过双向同步或者双写方式保证数据的一致性 注意事项: 是否需要redis双向复制提早规划 过滤过短时间key无效复制,比如:小于3秒的不再同步 批量写入提升性能 2.MySql双向同步 数据库的双向同步在异地多活通常是必须要做的事情,下面是阿里开源
多活架构解决的核心问题: 容灾能力:机房级故障的快速恢复 就近访问:用户访问延迟优化 扩展能力:突破单机房容量瓶颈 业务连续性:7x24小时不间断服务 上图展示了传统单机房架构与多活架构的根本差异。 2.2 多活架构分类 这张图清晰地展示了不同多活架构的特点。同城双活就像在同一个小区的不同栋楼里放设备,网络延迟很小;而异地多活则像在不同城市开分公司,距离远了但覆盖面更广。 3. 异地多活架构设计 异地多活是多活架构的高级版本,复杂度会有质的提升。就像从骑自行车升级到开飞机,需要掌握更多技能。 4.1 整体架构设计 这个架构图展示了典型的异地三活架构。 7. 避坑指南:常见问题及解决方案 多活架构虽然强大,但也有很多坑等着你。下面是一些常见的问题和解决方案,可以让你少走弯路。 7.1 数据一致性陷阱 问题:异地多活最大的坑就是数据一致性。 解决方案: 分阶段建设,先同城双活再异地多活 非核心业务可以使用冷备方案 充分利用云厂商的多活产品 8. 总结 多活架构设计是一个复杂的系统工程,需要考虑业务特点、技术实现、成本控制等多个方面。
随着业务的全球化和数字化转型,异地多活部署成为了数据管理的一种关键策略。如何实现这一部署方式以支持YashanDB,在技术实现和架构设计上都提出了挑战。 本文将深入探讨YashanDB异地多活部署的必要组件、架构设计和实施方案,确保数据安全和高可用性,从而提升系统的整体稳定性和业务连续性。 架构设计异地多活部署的架构设计必须可靠且高效,以确保在不同地理位置的数据中心之间能够实时处理数据,并保持一致性和可用性。1. 数据一致性管理在异地多活部署中,数据一致性至关重要,YashanDB通过以下几种策略维护数据一致性:1. 本文提供的技术方案和实施步骤,旨在帮助工程师快速实现YashanDB的异地多活部署,并通过不断的监控和优化,最终实现高效的数据管理。实现有效的异地多活部署将为企业带来更大的竞争优势以及持续的业务保障。
这就是我今天想聊的话题,单一机房内的高可用并不能算真正意义上的高可用,而「跨机房容灾」甚至「异地容灾」才算。异地容灾?异地多活? 而异地多活则是异地容灾的一种升级方案,单元节点如果仅仅是作为灾备实例,那也太浪费了,不如和中心节点一起,同步处理业务流量,这样一来,不仅可以提高资源利用率,也能保证在任意一个节点失效时,其他节点可以平稳接管流量 上图就是一个异地多活的解决方案,其核心是在所有节点间建立实时的数据同步机制,以确保各个节点的数据一致性。 3.单击数据源 ID 进入数据源详情页面,单击展开,找到多活标记,配置多活标记名称。该步骤所有参与复制的数据源都需要执行,以防止发生数据循环复制。 至此,你的异地多活架构已经全部配置完成,所有节点都可以提供业务读写,得益于实时的数据同步机制,任何一个节点发生故障时,其他节点均能够无缝接管中心节点的流量,由于所有单元节点本身就在处理业务,因此无需担心单元节点能否胜任
或者基于高可用 / 高性能的需求,需要做异地多活。 异地多活容灾 很多巨型互联网产品发展到一定规模之后,其可用性往往造成很大经济损失,比如微信,支付宝这些用户规模巨大的产品,如果可用性有一点的降级,都会对大规模的用户影响,所以微信,支付宝这些产品早已做了异地多活 传统灾备方案 传统数据中心的灾备方案,一般是同城两个互备数据中心,异地建设一个灾备中心,三个数据中心平时只能一个提供在线服务,故障时将业务流量切到其他数据中心。
p=299 导读:异地多活,作为一种高可用部署架构,成为大中型互联网公司的选择。像大家熟知的大型互联网公司,如阿里、腾讯、百度、网易、新浪等等都已经完成了异地多活的技术重构。 可以说,异地多活是互联网公司业务规模扩大后所必然要经历的阶段。那么如何解决高可用异地多活呢? 有状态服务 后台服务可以划分为两类,有状态和无状态。 高可用的一些解决方案 高可用,从发展来看,大致经过了这几个过程: 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候,还是先看一些其他的方案,这有利于我们理解很多设计的缘由。 实际上,异地双活和异地多活已经很像了,双活的结构更为简单,所以在程序架构上不用做过多的考虑,只需要做传统的限流,failover 等操作即可。 但其实双活只是一个临时的步骤,最终的目的是切换到多活。 因为双活除了有数据冲突上的问题意外,还无法进行横向扩展。 异地多活 图 4:异地多活的示意图 根据异地双活的思路,我们可以画出异地多活的一种示意图。
在软件开发领域,「异地多活」是分布式系统架构设计的一座高峰,很多人经常听过它,但很少人理解其中的原理。 异地多活到底是什么?为什么需要异地多活?它到底解决了什么问题?究竟是怎么解决的? 这些疑问,想必是每个程序看到异地多活这个名词时,都想要搞明白的问题。 有幸,我曾经深度参与过一个中等互联网公司,建设异地多活系统的设计与实施过程。所以今天,我就来和你聊一聊异地多活背后的的实现原理。 11 异地多活 理解了异地双活,那「异地多活」顾名思义,就是在异地双活的基础上,部署多个机房即可。 虽然物理上是两个机房,但「逻辑」上还是当做一个机房来用 6、两地三中心是在同城双活的基础上,额外部署一个异地机房做「灾备」,用来抵御「城市」级别的灾害,但启用灾备机房需要时间 7、异地双活才是抵御「城市 在写这篇文章时,我又仔细阅读了阿里、饿了么、微博等公司,关于异地多活架构设计的相关资料,如果你想更深入地学习异地多活架构,可以在我的公众号后台回复「异地多活」获取。
本文为第七部分,主要介绍异地多活,异地多活缩短了时延,提高可用性,但是带来复杂度和成本无疑是巨大的,不是一般公司可以承受的,只有在对可用性要求特别高的业务场景才建议使用。 代价很高 系统复杂度会发生质的变化,需要设计复杂的异地多活架构。 成本会上升,毕竟要多在一个或者多个机房搭建独立的一套业务系统。 跨城异地 跨城异地距离较远带来的网络传输延迟问题,给异地多活架构设计带来了复杂性,如果要做到真正意义上的多活,业务系统需要考虑部署在不同地点的两个机房,在数据短时间不一致的情况下,还能够正常提供业务。 跨国异地 为不同地区用户提供服务 只读类业务做多活 技巧 保证核心业务的异地多活 保证核心数据最终一致性 尽量减少异地多活机房的距离,搭建高速网络 尽量减少数据同步,只同步核心业务相关的数据 保证最终一致性 只保证绝大部分用户的异地多活 核心思想:采用多种手段,保证绝大部分用户的核心业务异地多活!
如何设计和实现一个高效的异地多活部署方案,是当今数据库行业亟待解决的技术问题。本文将深入探讨YashanDB支持的异地多活部署方案的核心技术点、架构和优势,帮助读者更好地理解其实现机制和应用价值。 通过全局资源管理机制,支持在多实例环境中对数据变化的实时同步,从而实现了异地多活的目标。分布式部署分布式部署采用了多管理节点(MN)、协调节点(CN)和数据节点(DN)的组合架构。 数据一致性与同步机制在异地多活部署中,数据一致性至关重要。YashanDB通过多版本并发控制(MVCC)和事务日志机制来提供保障。 异地数据备份与恢复在异地多活部署中,数据备份与恢复机制也是不可避免的关键问题。YashanDB提供了备份与恢复工具,用户可以通过执行备份策略,将数据定期备份至异地域的存储中。 结论YashanDB针对异地多活部署方案提供了多层次、多维度的技术支持,确保在实现高可用性的同时也能保证数据的一致性与安全性。
什么是异地多活? 为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。 事实上,异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。 异地多活常见的解决方案有哪些? 请求如何路由,如何实现会话保持对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据IP会话保持。 在常见的解决方案中有多机房单集群,和多机房多集群部署两种.数据的同步可以分为,数据库,缓存,消息队列,session等。在多机房单集群中如何部署? 对于强一致数据,应建立多机房单集群的部署模式,使用双读策略。多机房多集群模式,采用双写策略。 7.
分布式系统架构-----异地多活架构 背景 最近公司在搞异地多活,特来写篇文章来学习和回顾一下。 异地多活看字面意思 :不通的地方部署服务。 异地多活架构 1. 什么是异地多活架构? 异地:不同的地理位置,多活:不同的地理位置的服务都能独立提供服务。 异地多活的目的也就是容灾,容灾的话我们也可以理解为某个地方服务出现了灾难性故障,而服务仍然能正常提供服务。 2. 系统性能,因为异地多活会部署在不同的城市,所以距离就会带来延迟(距离越远,耗时越久)。 3. 常用的几种多活方案 同城异区 同城异区指的是将业务部署在同一个城市不同区的多个机房。 像我们现在比较流行的夸奖电商的那些服务,岂不是都是这种跨国异地机构呢? 应用 在背景也讲了我们公司也做了异地多活,多活的方式数据跨城异区。一个集群部署在广州南沙,一个部署在广东佛山。
作者:田守枝 来源:田守枝的技术博客订阅号(ID:tianshouzhi_blog) 在当今互联网行业,大多数人互联网从业者对"单元化"、"异地多活"这些词汇已经耳熟能详。 而数据同步是异地多活的基础,所有具备数据存储能力的组件如:数据库、缓存、MQ等,数据都可以进行同步,形成一个庞大而复杂的数据同步拓扑。 本文将先从概念上介绍单元化、异地多活、就近访问等基本概念。 不同单元的之间数据实时进行同步,相互备份对方的数据,才能做到真正意义上"异地多活”。 通常一个MySQL集群有一主多从构成。用户的数据都是写入主库Master,Master将数据写入到本地二进制日志binary log中。 7、数据同步架构设计 现在,让我们先把思路先从解决数据同步的具体细节问题转回来,从更高的层面讲解数据同步的架构应该如何设计。稍后的内容中,我们将讲解各种避免数据回环的各种解决方案。