最近阅读了一本架构方面的入门图书叫《从零开始学架构:照着做,你也能成为架构师》,部分内容比较不错,先做书摘总结,以便加深印象与未来回顾学习。
当谈到架构的高可用时,无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,也可能是一天。因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。
在软件开发领域,「异地多活」是分布式系统架构设计的一座高峰,很多人经常听过它,但很少人理解其中的原理。
导读:《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第七部分,主要介绍异地多活,异地多活缩短了时延,提高可用性,但是带来复杂度和成本无疑是巨大的,不是一般公司可以承受的,只有在对可用性要求特别高的业务场景才建议使用。
无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,也可能是12小时。因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。
在软件开发领域,异地多活是分布式系统架构设计的一座高峰,很多人经常听到过他,但很少人理解其中的原理;
本文由公众号“水滴与银弹”号主Kaito原创分享,原题“搞懂异地多活,看这篇就够了”,为使文章更好理解,有修订。
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读:异地多活,作为一种高可用部署架构,成为大中型互联网公司的选择。像大家熟知的大型互联网公司,如阿里
灾备: 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行,帮助企业实现业务7*24小时连续性的目标,备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
点击上方蓝色“程序猿DD”,选择“设为星标” 回复“资源”获取独家整理的学习资料! 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如MySQL数据库,redis等内存数据库。除了这两种类型的维护方式,还有jvm的内存的状态维持,但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用,从发展来看,大致经过了这几个
8月18日,云+社区开发者大会(杭州站)圆满落幕。本次云+社区开发者大会诚邀业内技术大咖为你带来云开发、小程序、云上“多活”架构等革命性的技术,更有云上直播以及零成本获客这几个当前电商领域的热点业务话题,与大家共探技术与产业转型背景下的电商如何成为时代引领者。下面是腾讯云TVP王晓波老师关于如何基于公有云提供的这些基础设施来简化“多活”架构的一些设计和实践的分享。
很多产品发展到一定规模之后,可能会走出国门,技术架构要做到国际化。或者基于高可用 / 高性能的需求,需要做异地多活。
数据时代,企业对技术创新和服务水准的要求不断提高,数据已成为企业极其重要的资产,数据同步也成为企业数据开发和使用一个绕不过去的技术需求。那么,什么时候我们需要进行数据同步,甚至是实时同步呢?目前又有什么实时同步方案?
来源:https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过 F5 或者任何代理
前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库(MySQL)实现异地多活时要考虑的点。本文不讨论为什么做异地多活,可以参考末尾的文章。
编者按:在本次RTSCon2022中,我们邀请到了烟台小樱桃网络科技有限公司CTO,FreeSWITCH中文社区创始人 杜金房,为大家详细分享双机、三机,到可弹性伸缩的通信集群建设经验。包含一对一通话、呼叫中心及音视频会议、日志监控等场景,包含FreeSWITCH、Kamailio、WebRTC、MCU、SFU、Docker、K8S、ETCD、NATS、Loki等相关技术。
为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上,异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。
本来这个公众号的交流消息中间件相关的技术的。这周去上海参加了QCon,第一次参加这样的技术会议,感受挺多的,所以整理一下自己的一些想法接公众号和大家交流一下。
说起容灾,很多同学脑子冒出来熟悉字眼,”同城双活”,“两地三中心”,“单元化”,“set化”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
最近恰好在搞异地双活,以下是一个梳理: 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候,另外一个机房只是当做备份。 2、异地双(多)活。而异地双(多)活,却是指有两个或者多个可以同时对外服务的节点,任意一个点挂了,也可以迅速切换到其他节点对外服务,节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类: 1、必须同步型。(比如数据库) 2、无须同步型。比如缓存,仅仅是当做缓存,就可以这样做(这个有待商榷,其实缓存也需要同步的,严格来说的话)。 3、只能单活(对全局原
数据库选型一直是困扰客户的难题,不仅要考虑底层的数据库技术,还需要结合企业业务特点、企业未来规划做决策。如何快速掌握数据库选型秘诀呢?答案无疑是看市场怎么做,看市场的同行是如何选择的。 近期,腾讯云数据库TDSQL助力福建海峡银行新一代核心业务系统正式上线(点击查看详情),为城商行提供核心改造解决方案。新核心关键业务系统采用“微服务+分布式”架构,改造历时14个月,依托腾讯云企业级分布式数据库TDSQL良好的兼容性、成熟的迁移能力和技术服务支持,海峡银行快速完成了核心系统的国产数据库替换,并基于腾讯云数据库
当前市场上常见的容灾模式可分为同城容灾、异地容灾、双活 数据中心、两地 三中心几种。
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等,今天主要是一起聊下,多机房部署的灾备架构模式,来确保服务的高可用。
TiDB的存储用的TiKV, TiKV是基于RocksDB实现了分布式(可水平扩展,支持主从),RocksDB是对单机版LevelDB的封装。
当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题。为了解决这些性能压力带来问题,我们需要在Web系统架构层
大规模流量的网站架构,从来都是慢慢“成长”而来。而这个过程中,会遇到很多问题,在不断解决问题的过程中,Web系统变得越来越大。并且,新的挑战又往往出现在旧的解决方案之上。希望这篇文章能够为技术人员提供一定的参考和帮助。 以下为原文 当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题。为了解决这些性能压力带来问题,我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段,我们会遇到不同的问题,通过搭建不
RabbitMQ集群架构模式 主备模式 实现RabbitMQ的高可用集群,一般在并发和数据量不高的情况下,这种模型非常的好用且简单。主备模式也称为Warren模式 HaProxy配置 listen rabbitmq_cluster bind 0.0.0.0:5672 # 配置TCP模式 mode tcp #简单的轮询 balance roundrobin #主节点 server bhz76 192.168.11.76:5672 check inter 5000 rise 2 fall 3 server bh
企业业务敏感程度差异,对容灾指标RPO&RTO要求也不同。之前两篇文章主要介绍数据冷备,主要特点是数据备份存储非实时,备份系统存储数据通常昨天的数据,当灾难真正来临的时候,今天新产生的数据会丢失情况。对于企业核心业务来讲,业务恢复(RTO)可以接受小时级别,但是对于数据无法接受丢失,即RPO接近为“零”。结合腾讯云数据备份能力,本文重点介绍数据热备解决方案,旨在让客户上好云,用好云,管好云。
当一个Web系统从日访问量10万逐步增长到1000万,甚至超过1亿的过程中,Web系统承受的压力会越来越大,在这个过程中,我们会遇到很多的问题。为了解决这些性能压力带来问题,我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段,我们会遇到不同的问题,通过搭建不同的服务和架构来解决。
在互联网大厂,有个普遍的现象:某种程度上,只要是比较重要的系统,都需要考虑系统的容灾问题。
高可用,英文单词High Availability,缩写HA,它是分布式系统架构设计中一个重要的度量。业界通常用多个9来衡量系统的可用性,如下表:
系列文章索引: [WCF邮件通信系统应用 之 数据同步程序 之 设计内幕 之 一] 同步一个数据库要发多少个数据包? [WCF邮件通信系统应用 之 数据同步程序 之 设计内幕 之 二] "开门待客"还是“送货上门”? [WCF邮件通信系统应用 之 数据同步程序 之 设计内幕 之 三] “设计应对变化”--实例讲解一个数据同步系统 [WCF邮件通信系统应用 之 数据同步程序 之 设计内幕 之 四] 唯一不变的就是一直在变”--“数据”的华丽“变身术” 客户需要一个产品,是让客户上门取好呢还是主动送货上
总第249篇 2018年 第41篇 引言 在任何一家互联网公司,不管其主营业务是什么,都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产,它可以用来衡量业务指标,例如日活、月活、留存等,同时也给不同业务线提供了大量潜在用户,业务可以基于账号来做用户画像,制定各自的发展路径。因此,账号服务的重要性不言而喻,同时美团业务飞速发展,对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。 衡量一个系统的可用性有两个指标: 1. MTBF (Mean Time Between
2001年的“911事件”中,没有远程备份的企业都遭受了巨大损失,甚至部分公司因为核心业务部署在公司大楼而又没有远程备份,导致公司业务无法继续运营而倒闭。美国“911事件”后,全球用户提升了对灾备的重视程度,异地灾备建设一时成为趋势。
作者:[美]威廉·肯尼迪(William Kennedy)布赖恩·克特森(Brian
https://www.cnblogs.com/grefr/p/6087942.html#top
MySQL技术专家,现任爱可生技术服务总监,负责MySQL数据库在传统行业客户的应用推广与技术咨询,曾为运营商、银行、证券、保险、航空等行业内数家大型企业提供MySQL技术咨询服务。
我很喜欢的一句话和大家分享一下:很多模式是不能直接复制的。当数量级直线上升的时候,其背后的难度是几何增长的。
第一次尝试自己组建硬件到软件的服务器,经过几个月折腾,服务器框架基本完成,整体框架如下:
去年写过一篇《做容灾,冷备是不是个好方案?》,当时提出来,冷备或者主备,其实并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的容灾模式根本起不到作用。
事务问题:一致性。 【问题】 如何保证主机和从机的数据一致???主从复制的延迟性问题。
近年来,从国家到地方都在积极探索政府数字化转型之路。当前,数字政府改革建设任务已经从“从无到有”的探索时期,逐渐转变为“量变带来质变”的优化时期。 从建设内容看,一体化政务服务平台相关建设目前已进入了平台互联互通和提质增效的深化建设阶段。 本文是腾讯云数据库高级工程师余超在《腾讯数字政务云端系列直播》的演讲实录,将带大家共同探索数字政务行业发展趋势、前沿技术和TDSQL技术实践,感受分布式数据库的技术之美。 数字政务行业发展趋势 大家好,我是腾讯云国产数据库产品中心的余超,目前主要负责政务行业、国大行等重
随着企业规模的扩大,对数据库可用性要求越来越高,更多企业采用两地三中心、异地多活的架构,以提高数据库的异常事件应对能力。 在数据库领域,我们常听的“两地三中心”、“异地多活”到底是什么呢? “两地三中心”就是生产数据中心、同城灾备中心、异地灾备中心。这种模式下,两个地域的三个数据中心互联互通,当一个数据中心发生异常,其他数据中心可以正常运行并进行业务接管。 “异地多活”就是在多个地域建设多个数据中心, 业务数据能够在三个及以上的数据中心之间进行双向同步。异地多活架构具有更高的可用性,抗风险能力极强。 不
腾讯云数据库【国产数据库专题线上技术沙龙】正在火热进行中,4月28日陈爱声的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。
陈培新,参与国信证券基础平台研发工作(DevOps、微服务治理、Serverless)
冷备或者主备并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的容灾模式根本起不到作用。
Oracle GoldenGate 是一款实时访问、基于日志变化捕捉数据,并且在异构平台之间迚行数据传输的产品。GoldenGate TDM是一种基于软件的数据复制方式,它从数据库的日志解析数据的变化(数据量只有日志的四分之一左右)。GoldenGate TDM将数据变化转化为自己的格式,直接通过TCP/IP网络传输,无需依赖于数据库自身的传递方式,而且可以通过高达10:1的压缩率对数据迚行压缩,可以大大降低带宽需求。在目标端,GoldenGate TDM可以通过交易重组,分批加载等技术手段大大加快数据投递的速度和效率,降低目标系统的资源占用,可以在亚秒级实现大量数据的复制,并且目标端数据库是活动的。
领取专属 10元无门槛券
手把手带您无忧上云