一、多活业务架构 1、OPPO多活架构原则 第一，主线多活。 多活成本比较高的，双活是两倍，三活可能成本会低一些，但三活的难度更大。因此没有办法对所有业务进行多活，只能对主线做多活。...5、异地双活——评论系统案例 ? 上图是平台型业务-评论系统异地生活的案例，评论系统从SDK开始，就进行了域名拆分，避免了在业务域名所在机房内部去做跨机房的评论服务调用，影响服务的可用性和性能。...在第二级划分的单元内部，我们再应用异地双活的模式，或者是同城多活的模式，比如说左边单元1，按照地域做第二级的划分，把它划分成南北两个副本，既然是副本，肯定数据是全量的，是异地双活模式，两个副本数据做双向同步...>>>> Q&A Q1：Http DNS也有缓存的吧？...A1 ：对，刚刚提到我们Http DNS缓存时间非常长，缓存了一周的时间，而且缓存的时候是根据环境来缓存的，就是按照 WiFi名称、运营商的名称来做缓存，这样网络切换的时候可以拿到最优的IP。
在实际的架构中，用户从端上过来访问，会基于DNS或是HTTP DNS来访问我们的DCDN的节点，在DCDN回源时会有POP点来做流量的汇聚，再进入到我们的可用区。...②缓存一致性 为避免业务直连缓存实例，缓存接入方面我们提供统一的Proxy。SDK 在各开发语言上并不统一，所以可能会引发短连接的风暴，并引起性能下降。...Q&A Q1：同城双活架构下应用层做了双多活，基础架构层还有必要双活吗？ A1：我觉得有必要。...若是比较远距离异地多活，需要进行数据分片、单元化双写的改造，并且能够接受部分数据的同步延迟，因为跨地域的耗时增加属于物理层面，无法避免。只能根据一个合适的业务场景，适配相应的多活方案。...关于缓存数据，前面也介绍了缓存一致性的几种维护方式。 Q3：高可用多活的成本如何把控，过程中对ROI的考虑是怎样的？ A3：要从以下两个方面分析：一是收益。发生故障时，就会感知到多活的收益是有价值的。
又能怎样？ 4、 忆 回忆之中，到处都是风。。。风的声音在耳边回响。。。 偏执，目光的局限性，导致错过了很多美好的东西，有些东西回忆起来，满目疮痍。。 心态有多开放？...2、 同城双活，使用DNS解析为两个IP地址，从而可以达到轮询的作用，从网络的层面来说，单机房属于网络架构中的单点，而DNS则是这个双机房的负载均衡器； 3、 全局的调度功能，这属于智能DNS...在双机房的时候，也就是同城双活的时候，这个时候，可能在A机房有一个redis，在B机房也有一个redis，进行负载均衡的时候，由于对外出口只有一个，从而要么在前端再加上一个负载均衡，要么就是最简单的方式...DNS的难点： 在使用DNS的时候，存在几个主要的问题： DNS缓存问题，在各级的NS中，每个缓存的时间不一致，从而在进行更新的时候，发现全网生效时间比较长，在进行DNS切换的时候，...缓存更新复杂。
多云架构有如此多的优势，那么选择怎样的架构才能达成，下面具体展开描述下。 主备多云 企业的应用服务还是在一家云厂商上，用户通过 DNS 解析过来，数据沿着网关、应用、数据存储这条链路流转。...成本优化、避免供应商锁定，1 分。企业已经在尝试第二家云供应商了，虽然只是存储方面的一小步，但在成本、避免锁定等方面逐渐有了一定的进步。...为了确保有突发流量时第二家云可以稳定承接，所以常态下就要承接一定流量，保证服务是双活的。当流量增加时，弹性云进行快速扩容，通过 DNS 或者网关将主云上无法承载的流量转移到弹性云上。...多活多云 这种也是最复杂的一种，企业将服务等量部署在两家云供应商上，通过 DNS 进行流量分配。数据存储一般采用主从模式，随着分布式数据库的逐渐兴起，也有较多的选型，这里先简单按照主从来讲。...单家云出现故障时，只需要将 DNS 路由到另一家云即可，又可以正常提供服务了。 成本优化、避免供应商绑定，3 分。不同云有完整的服务，只是流量占比不同，所以迁移成本很低。
资料怎样保存？ 事务处理相关 简述什么是事务处理？ 在不能使用数据库的事务处理以及锁（表锁/行级锁）时，怎么保持数据一致性？怎么解决数据库并发操作？ 怎样解决避免多个用户读读取同一条数据记录？...怎样防止一个订单被一个以上的人看到？ 如果两个员工同事看到同一个个订单，怎样避免员工，重复审批同一张订单？...JSON 可能缓存吗？ 浏览器缓存与CDN缓存的关系，怎样实现用户浏览器与CDN同时缓存？ 面向对象试题?...高可用设计 什么是高可用 什么是双机热备，双机热备有那些缺陷 什么是双活 请简述实现软件高可用要考虑那些因素 软件设计中的灾备问题 请简述设计一个远程异地灾备系统 两个机房怎样设计灾备系统 三个机房怎样设计灾备系统...跨境情况需要考虑那些影响因素 软件灾备开发问题 数据库怎样实现灾备 缓存怎样实现灾备 应用服务器怎样实现灾备 Web 服务器怎样实现灾备 计划任务、定时周期运行的程序怎样灾备 消息队列怎样实现灾备 双活的软件怎样实现同一时刻只能一个运行
用户基于DNS和HTTP DNS访问DCDN节点，然后DCDN回源时，由边缘POP点做流量汇聚，路由到机房。 因为B站做了多活，所以有多个可用区。...对于网络故障时，比如DNS故障时，很多公司的做法是降级到HTTP DNS。 对于端上来说，HTTP请求解析到一个地区返回多个DCND节点，让客户端做一个最佳链路选择。...因为两个可用区都在上海，做同城双活网络延迟低，基本不存在服务延迟问题。 B站很多业务场景都适合做同城双活，因为很多数据都偏向于用户之间共享。...延迟巡检，因为使用了GZone，所以DB和KV同步延迟较低，同城双活一般1ms延迟，没有什么问题。...切量演练时，验证是否可以做到双活容灾。 713故障时，因为登录不了鉴权系统，导致不能及时处理问题，现在已经改为登录认证可降级了，不强依赖于登录态。
客户端保存两个DNS地址，根据网络线路的健康状况，由客户端操作系统选择第一步地址请求的DNS服务器地址，每个数据中心的DNS服务器一般会通过HA方式来避免设备的单点故障。...② 数据层的双副本或者多副本技术（如分布式存储技术），毕竟状态、会话、缓存也是数据。 4....4.2 HA数据库服务模式 所谓 HA数据库服务模式是指通过操作系统HA软件结合数据库服务实现的容灾架构，架构设计之初是为了实现各类应用服务的本地服务器高可用，但双活容灾技术兴起之后，也常常被用来作为近距离...（百公里内范围）双活容灾的数据库服务架构 。...4.3 AA数据库服务模式 所谓 AA模式的数据库服务就是以Oracle RAC、DB2 pureScale为代表的双活集群架构，同样它们的设计初衷也是为了解决数据库服务本地高可用的解决方案，后来衍生为
# 企业没有一个优秀的架构师 怎样才能成为一名优秀的架构师 # 得有实战经验 # 实战的应用场景 历经15次架构演进过程 # 首先: 定义当前企业的架构，目前所处的一个阶段并且绘制出架构图谱 # 定位问题...第三次架构: 引入本地缓存和分布式缓存 # Tomcat服务器上或同JVM增加本地缓存 # 在外部增加分布式缓存 # 缓存热数据和静态html页面 # 通过缓存把大多数的请求在读写数据库前拦截掉 # 会应用到那些技术栈尼...# memcached 作为本地缓存 # Redis作为分布式缓存 # 问题. # 缓存一致性，缓存穿透/击穿，缓存雪崩 # 热点数据集中生效 # 缓存抗住了大部分用于请求，用户增长，并发的压力就会落到...； # 资源隔离设计: 应避免单一业务占用全部资源； # 架构应能水平扩展。...系统只有做到能水平扩展，才能有效避免瓶颈问题； # 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品； # 使用商用硬件。
一、入口层高可用 nigix两个 keeplive保活 心跳做好。 ?...keeplive提供这个技术 比如机器A IP是1.2.3.4，机器B IP是1.2.3.5，那么再申请一个IP （1.2.3.6）我们称之为心跳IP，平时绑定再A上面，如果A宕机，那么IP会自动绑定到B上面 DNS...然后DNS加IP就可以了吧？...那么在有机器添加或者删除后，很多原有的数据就无法找到了，这样严重的违反了单调性原则 一致性HASH可以有效解决这个问题，一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移...】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性
双活、灾备，能帮到我们！ 一、单数据中心架构的隐患 单数据中心的常见架构如下图所示，如果在该数据中心在极端情况下，出现网络全阻、设备掉电全阻等情况，业务可能发生全阻。...1、通过智能DNS服务，实时两个SLB的连通性进行检测，当主用SLB中断时，进行秒极的检测，将备用SLB同步至全网的DNS服务器。...四、两地三中心的应用双活架构 该架构实际是以上两种方式的结合。双活架构一般是发生是两个数据中心相邻距离不远的场景。如果对于金融级的客户，还会考虑异地的灾备。则采用以下的架构。...保障双活的公有云中断时，异地的私有云还能够在一定的时间内接管业务。 ? 五、数据灾备级的容灾方案 对于以上的方案，投入的代价较大，例如需要支付双活数据中心的高速通道费用、相同配置的云主机费用。...六、小结 1、如果中型企业、资金预算较充足，可以选择双AZ方案、或线上+线下的双活高可用方案。 2、对于金融级客户，可以选择两地三中心的方案。 3、对于普通企业客户，可以选择数据级的灾备方案。
为了避免在极端情况下，得物的交易主链路出现长时间不可用的情况，团队决定启动同城双活项目，目标是快速建设流量动态切换能力及快速恢复能力，同时降低改造难度、减少改造工作量，不增加大量额外成本。...、卖家库存等，一般需要考虑在某个机房维护(gzone)，避免数据同步问题带来的超卖、超用切流时需要做目标机房的局部数据禁写，避免脏数据产生同城双活特点：只有一份数据源，不需要考虑数据同步的延迟问题及切流时的禁写逻辑...双活整体架构可以看到，整体在架构层面分为四层：接入层： DNS 域名解析+ SLB主备 + DLB（自研流量网关)+DAG(自研业务网关) 多机房部署，保障接入层高可用。...上线环节前期准备阶段：整体思路确定：基于当前的蓝绿发布做双活，每次的蓝绿发布过程就是一次双活切流演练，避免长久不使用，需要用的时候手忙脚乱或者年久失修。...RT变化，对于下游未加入双活、或者某些存储/缓存中间件，如DB/Hbase/Redis未开启就近读取，B机房的RT会普遍高5-8ms。已在逐步投入优化。
接下来我分享下双活的部署架构，这是一个双活的部署架构，那么双活的部署架构是什么样的呢？ ?...这里我来总结下双活与主备的差异。 ? 实例数：双活是有两个完全独立的实例，而主备只有一个实例。 写入属性：双活是双向的，主备是单向。 应用接入：路由会变得很简单，所有应用都是在单中心内完成数据交换。...同步方向：双活数据同步双向的，主备是单向的。 同步粒度：同步配置的级别，主备必需基于实例级别，双活本身可以表级，也可以库级。 本地可写：双活两边实例都可以写，主备只有一个中心可以写。...本地数据同步到异构数据库：双活都是支持的，而主备是不支持。 南北切换成本：双活数据库不需要切换，但主备必须要切换，如果数据同步配置为异步级别，那么切换后数据怎样去补全回来？...从中心级的故障切换来看，多活部署的架构，异地切换时数据库不需要做任何操作。对于微服务来说，是切DNS，等故障恢复，数据同步完成以后，只要把DNS回切回去，把流量切回去就可以了。
本文会通过一个业务 Demo 案例，介绍混合云容灾建设的难点，以及如何基于 MSHA 来快速搭建应用双活架构并具备分钟级业务恢复能力。...建设难点 流量管理难度高 若采用 DNS 将流量按权重解析到云上和云下，存在修改 DNS 解析生效时间长的问题（通常为十分钟或小时级，参见 DNS 解析生效时间 FAQ [2] ），不能满足容灾切换小于...解决方案 结合业务容灾需求和混合云 IDC+云形态的特点，采用应用双活架构能够较好的满足业务容灾诉求。...应用双活架构 架构简图： 架构规范： 选择离 IDC 物理距离<=200km 的云上 Region，网络延迟较低（约 5~7ms）。...应用、中间件云上云下冗余对称部署，同时对外提供服务（应用双活）。 数据库异地主备，异步复制备份。应用读写同一数据中心的数据库，避免考虑一致性问题。
最近有个集团级的云项目处于实施过程中，客户对数据备份、应用双活视为同一个事物，要求我方将原秒级数据备份升级为秒级应用双活。实际问题，备份与双活是不同的两个概念。...以下我们用图文方式简述双活与数据备份的区别。 ? 一、数据备份：一般数据备份采用定期全量备份（如七天），更短周期数据增量备份（如一天或秒级）的方式。...数据备份达不到应用双活的要求，因为仅实现了数据的备份，应用实际是单部署。一旦主应用服务器中断，实际是无备应用服务器接替服务器的。...二、应用双活： 1、在两个数据中心边界部署GSLB，在单数据中心全部中断服务情况下，秒级切换。...6、最后，应用双活是很复杂的体系，需要网络、数据中心等多台设备的联动，成本、实施难度很高。
八、DNS轮训与数据库全文检索引擎 uDNS轮询 DNS负载均衡技术实现原理是在DNS服务器上一个主机名配置多个IP地址，用户访问时，轮训返回解析记录，从而达到负载均衡目的。...使用CDN技术，它通过一种缓存技术将频繁访问的资源（主要静态）分布到全国各地边缘服务器，用户先访问CDN服务器，CDN根据职能DNS返回客户端就近网络中的缓存服务器，如果这个缓存服务器有缓存请求的静态资源就直接返回...u异地容灾 如果不可容忍网站不可用，应考虑到异地备份或异地双活。...u应急预案 十三、谈古至今 尽量将请求拦截在前面，从而减少数据库和HTTP请求 数据库层是架构瓶颈，需要精心设计，比如架构扩展、SQL优化（压缩、索引等） 避免单点 分解压力 扩展性 找瓶颈出方案 十四...2、全链路分析 梳理从网站入口到数据存储的各个环节，找出依赖服务，假设性去分析问题，如果某环节故障，影响范围怎样。
，其中影响的因素是多种多样的，这里针对两个最常见的场景进行剖析 TTL缓存导致 不同区域的LDNS我们无法得知，可能不同运营商之间、省份之间、DNS品牌不同，他们LDNS的递归机制也不尽相同。...这里主要影响DNS解析权重效果的是LDNS对于TTL缓存时间的处理：在单个域名的TTL缓存中，LDNS收到该域名的解析请求后，不会再向权威DNS进行解析请求，而是直接将缓存的结果应答给客户端。...一般情况下：LDNS会遵循权威DNS给出应答的TTL值，在本地缓存指定的时间。...，将TTL强制修改为300秒 3）在3600s内，区域A、B的客户端按照正常的调度，一直正常向服务器A:1.1.1.1发起了访问 4）而区域C的LDNS在300s后因为缓存过期，进而重新向权威DNS请求得到...虽然DNS按权重比例是“粗粒度”的，但是目前而言在多数据中心容灾、双活、多活等场景下基于DNS调度是目前较好的方式，且应用范围最广，下面对使用该功能提出几点最佳实践探索的建议： 1)在权威DNS上设置的按权重比例调度的域名
服务注册中心：故障影响新服务注册、配置下发，TSF 在应用本地设计了缓存机制，在注册中心不可用时，应用仍可发起服务间调用。组件使用 Consul 集群部署，一主多从模式。...应用层：无状态服务同时对外提供服务，双活的前提是微服务管控层双活以及数据库跨 AZ 时延低。 数据库层高可用部署模式仍为一主多从，后面不再对数据库层进行异常分析。...整体架构是同城双活+主备的组合方案。 部署方案： 微服务管控层：同城双活部署，异地灾备，各自的数据不需要做同步，只负责各自的服务管控。...部署方案： 微服务管控层：服务同城双活，异地不互通。 应用层：不同数据分片的应用异地多活，相同数据分片的应用同城双活，异地灾备。 数据库层：数据分片一主多从，不同分片异地互备。...容灾切换策略：如南方城市整体故障，入口出做 DNS 切换南方用户访问 IP 至北方。 单元化 一般如果数据量过大，单纯使用数据库 Sharding 模式无法解决问题，可以考虑使用单元化架构。
如果我们还期望业务的可用性达到99.999%以上，还需要实现对象存储的跨AZ部署，也就是所谓的“同城双活”。...由于对象存储是基于HTTP的，而HTTP是基于IP的，所以，我们首先要解决HTTP Server的双活问题。 让我们举一个栗子。...对于这个图，熟悉云计算网络的同学一定会想到，为了避免单点故障，图中的http server实际上并不是一台真实的服务器，而是由VM或容器构成的集群。...(可以称为RS，Real Server)，oss.por***b.com会被解析为106.15.220.171 （双活AZ的VIP）。...Rhino的访问被双活AZ所接管，从而实现了HTTP层的双活。 大家可能会问一个问题：如果Rhino在上传(put)或下载(get)一个文件的时候，主AZ整体断电呢？
前面我们讲了同城双活，那异地双活是不是直接「照搬」同城双活的模式去部署就可以了呢？事情没你想的那么简单。...如果还是按照同城双活的架构来部署，那异地双活的架构就是这样的：图片注意看，两个机房的网络是通过「跨城专线」连通的。...看到了么，虽然我们只是简单的把机房部署在了「异地」，但「同城双活」的架构模型，在这里就不适用了，还是按照这种方式部署，这是「伪异地双活」！那如何做到真正的异地双活呢？...例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。...12 异地多活理解了异地双活，那「异地多活」顾名思义，就是在异地双活的基础上，部署多个机房即可。
前面我们讲了同城双活，那异地双活是不是直接「照搬」同城双活的模式去部署就可以了呢？ 事情没你想的那么简单。...12、真正的异地双活架构 既然「跨机房」调用延迟是不容忽视的因素，那我们只能尽量避免跨机房「调用」，规避这个延迟问题。...13、更好的异地双活架构及实施思路 接上节：既然自动合并数据的方案实现成本高，那我们就要想，能否从源头就「避免」数据冲突呢？ 这个思路非常棒！...双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。 至此，我们才算实现了真正的「异地双活」！...值得提醒你的是：只有真正理解了「异地双活」，才能彻底理解「异地多活」。 在我看来：从同城双活演变为异地双活的过程，是最为复杂的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
