异地多活看字面意思 ：不通的地方部署服务。前段时间发生的B站挂掉的事情，网上众说纷纭，有的说是有机房着火了，导致服务宕机。那对于这种突发的情况，我们应该如何应对呢？包括说有些地方地震了导致机房宕机等等。
最近恰好在搞异地双活，以下是一个梳理： 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候，另外一个机房只是当做备份。 2、异地双（多）活。而异地双（多）活，却是指有两个或者多个可以同时对外服务的节点，任意一个点挂了，也可以迅速切换到其他节点对外服务，节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类： 1、必须同步型。（比如数据库） 2、无须同步型。比如缓存，仅仅是当做缓存，就可以这样做（这个有待商榷，其实缓存也需要同步的，严格来说的话）。 3、只能单活（对全局原
灾备： 是指容灾和备份。容灾是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务7*24小时连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。容灾备份产品的最终目标是帮助企业应对人为误操作、软件错误、病毒入侵等“软”性灾害以及硬件故障、自然灾害等“硬”性灾害。
同城异地灾备，主要是用来进行备份容灾的，从而当一个数据中心挂了，另外一个数据中心经过切换之后，能让服务迅速的恢复。
在异地多活项目整体推过程中的一些注意事项和设计点归纳和整理，抛砖引玉，其中一些点还有待深入探讨和优化。
在全球化战略的背景下，Trip.com作为一个面向国际市场的全球OTA平台，正努力推进国际化战略部署。Trip.com火车票正在积极投入资源和技术力量来拓展海外业务，通过将应用、数据部署新加坡、法兰克福等中心，从而给全球用户带来更好的购票体验和减少数据合规带来的风险。
Redis在携程内部得到了广泛的使用，根据客户端数据统计，整个携程全部Redis的读写请求在每秒200W，其中写请求约每秒10W，很多业务甚至会将Redis当成内存数据库使用。 这样，就对Redis多数据中心提出了很大的需求，一是为了提升可用性，解决数据中心DR（Disaster Recovery）问题；二是提升访问性能，每个数据中心可以读取当前数据中心的数据，无需跨机房读数据。在这样的需求下，XPipe应运而生 。 从实现的角度来说，XPipe主要需要解决三个方面的问题，一是数据复制，同时在复制的过程中保
在互联网大厂，有个普遍的现象：某种程度上，只要是比较重要的系统，都需要考虑系统的容灾问题。
作者简介 孟文超，携程技术中心框架研发部高级经理。2016年加入携程，目前主要负责Redis多数据中心项目XPipe。此前曾在大众点评工作，任基础架构部门通信团队负责人。 Redis在携程内部得到了广泛的使用，根据客户端数据统计，整个携程全部Redis的读写请求在200W QPS/s，其中写请求约10W QPS/S，很多业务甚至会将Redis当成内存数据库使用。 这样，就对Redis多数据中心提出了很大的需求，一是为了提升可用性，解决数据中心DR(DisasterRecovery)问题；二是提升访问性能，每
Redis 的优点中提到 Redis 支持持久化数据，宕机后可恢复数据，持久化就是基于内存读写的 Redis 数据一旦断电后，数据就无法恢复，为了解决这个问题，Redis 提供了可以将数据保存到磁盘的功能，这个过程称作持久化，被持久化的数据可以在机器重启后重新加载到内存中。
多活成本比较高的，双活是两倍，三活可能成本会低一些，但三活的难度更大。因此没有办法对所有业务进行多活，只能对主线做多活。
上一节讲面试中被问到分布式系统概念相关的，讲完了分布式系统的概念，优点缺点和 RPC 后，我以为这个问题就到此结束了，没想到成功给自己挖了个坑（微笑脸），关于 CAP，以前只是听说过，并没有详细点整理过，这一次问好好整理了下。
采用高可用系统架构支持重要系统，为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段，本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
2022年，基于对稳定性的焦虑...和思考，交易平台联动中间件平台启动过异地多活项目的探索，虽然完成了核心应用及基础组件的改造，但在疫情&降本增效的影响下并未真正投产，同时也缺乏充分的测试以及线上流量的大规模验证；后续在不断的业务迭代中，相关设计及代码被冲击的面目全非，相关的多活自动化测试case也并没有沉淀下来。
为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。
异地多活的概念以及为什么要做异地多活这里就不进行概述了。概念性的很多，像什么同城双活、两地三中心、三地五中心等等概念。如果有对这些容灾架构模式感兴趣的可以阅读下这篇文章进行了解：《浅谈业务级灾备的架构模式》。
在有赞早期的时候，当时只有 MySQL 做存储，codis 做缓存，随着业务发展，某些业务数据用 MySQL 不太合适， 而 codis 由于当缓存用， 并不适合做存储系统， 因此， 急需一款高性能的 NoSQL 产品做补充。考虑到当时运维和开发人员都非常少， 我们需要一个能快速投入使用， 又不需要太多维护工作的开源产品。 当时对比了几个开源产品， 最终选择了 aerospike 作为我们的 KV 存储方案。 事实证明， aerospike 作为一个成熟的商业化的开源产品承载了一个非常好的过渡时期 在很少量的开发和运维工作支持下， 一直稳定运行没有什么故障， 期间满足了很多的业务需求， 也因此能抽出时间投入更多精力解决其他的中间件问题。
本文将主要首先聊一聊数据库同步和迁移两个话题，之后将会围绕这 2 个话题介绍一下阿里云开源的基于 MongoDB 和 Redis 的数据同步&迁移工具 MongoShake 和 RedisShake，最后介绍一些用户的使用案例。
导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第七部分，主要介绍异地多活，异地多活缩短了时延，提高可用性，但是带来复杂度和成本无疑是巨大的，不是一般公司可以承受的，只有在对可用性要求特别高的业务场景才建议使用。
在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。
CAP问题已经成了计算机科学中一个研究领域，之前说到分布式系统有哪些优势时讲到三个提升：
当谈到架构的高可用时，无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是一天。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
Redis中国用户组（China Redis User Group），简称CRUG，是中国地区最大的Redis技术交流社区。社区成立有近3年的时光，是信仰、是信念、是信心、是坚守，让我们一起见证成长。感谢不离不弃、长久的陪伴！自2019年始，每一年的CRUG年会，都诚挚地邀请大中华地区所有的Redis用户都共襄盛举、畅谈梦想。
无论是高可用计算架构，还是高可用存储架构，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但在一些极端场景下，有可能所有服务器都出现故障。例如，典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障，或者业务整体瘫痪，而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是12小时。因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。
声明：本文首发于CSDN，禁止未经许可的任何形式转载，可咨询文末的责编。 多机房架构存在的原因 单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可
为了保障系统可用性， 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害， 发生的频率一次降低。
在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理;
本文由公众号“水滴与银弹”号主Kaito原创分享，原题“搞懂异地多活，看这篇就够了”，为使文章更好理解，有修订。
本文由极客时间整理自微博研发中心基础架构部资深系统架构开发工程师臣勇在 QCon+ 案例研习社的演讲《微博 KV 服务探索与实践》。 作者｜臣勇 编辑｜支小亚 你好，我是来自新浪微博的臣勇，我目前负责 KV 缓存与存储相关的工作，今天和您交流分享的是微博在 KV 服务上的探索与实践。 首先介绍一下目前 Redis 和 Memcached 在微博里的应用情况，我们遇到的问题以及如何解决这些问题。接下来会介绍几个落地案例，最后做一个总结。其中重点在我们的解决方案上。 1. 背景 1.1 Redis / Memc
KV 存储作为美团一项重要的在线存储服务，承载了在线服务每天万亿级的请求量，并且保持着 99.995% 的服务可用性。在 DataFunSummit 2023 数据基础架构峰会上，我们分享了《美团大规模 KV 存储挑战与架构实践》，本文为演讲内容的整理。文章主要分为四个部分：第一部分介绍了美团 KV 存储发展历程；第二部分分享了内存 KV Squirrel 挑战和架构实践；第三部分阐述了持久化 KV Cellar 挑战和架构实践；最后一部分介绍了未来的发展规划。希望这些内容能对大家有所帮助或启发。
同城异区两个机房距离一般就是几十千米，网络传输速度几乎和同一个机房相同，降低了系统复杂度、成本。
在系统设计时，如果能预先看到一些问题，并在设计层面提前解决，就会给后期的开发带来很大的便捷。相反，有缺陷的架构设计可能会导致后期的开发工作十分艰难，甚至会造成“推倒重来”的情形。因此，在系统设计阶段，应该尽可能的规避项目开发中可能会遇到的各种问题。本文就选取了几个经典的问题进行介绍。
饿了么技术团队花了1年多的时间，实现了业务的整体异地多活，能够灵活的在多个异地机房之间调度用户，实现了自由扩容和多机房容灾的目标。本文介绍这个项目的整体结构，还简要介绍实现多活的5大核心基础组件，为读者建立基本的概念模型，后续会有系列文章陆续介绍每个组件的实现细节。读者能够从中了解到做异地多活的大方向，为实现自己的异地多活，或者是容灾备份提供参考。
互联网特别是电商平台，阿里双11秒杀、还有12306春运抢票、以及平时各种节假日抢购活动等，都是典型的高并发场景。
导语：传统行业转型的过程中，腾讯向来扮演的是数字化助手的角色，腾讯云作为帮助企业数字化转型的入口，也已经成为腾讯的“独角兽”业务。 然而伴随着云业务的增长，腾讯内部业务如何上云，对于外界来说一直是个秘密。近日，腾讯自研上云项目负责人周小军首次披露，腾讯如何把内部海量的自研业务搬上云端的故事。以下是他的分享内容。 大家好，我今天分享的核心内容有三个： 腾讯自研业务如何从私有云的模式搬迁到公有云； 如何把这些大体量的业务搬到云端； 如何拥抱云原生。 腾讯的业务量非常庞大，社交业务包括QQ和空间的体量有
我们做数据库选型的时候首先要问：需求是谁提出的，也就是说谁选型？是负责采购的同学、 DBA 还是业务研发？
大家也许开发过高并发的系统或者秒杀程序，但肯定都有接触过，像电商平台的秒杀、抢购等活动，还有12306春运抢票。
过去几年，携程技术保障部门在Redis治理方面做了很多工作，解决了运营上的问题，在私有云上也积累了丰富的经验。后又通过引入Kvrocks，在公有云上实现降本增效的目的，从而支撑了公司的国际化战略。
在 2019 年 QCon 全球软件开发大会（上海站）上，美团高级技术专家齐泽斌分享了《美团点评万亿级 KV 存储架构与实践》，本文系演讲内容的整理，第一部分讲述了美团 KV 存储的发展历程；第二部分阐述了内存 KV Squirrel 架构和实践；第三部分介绍了持久化 KV Cellar 架构和实践；最后分享了未来的发展规划和业界新趋势。
我很喜欢的一句话和大家分享一下：很多模式是不能直接复制的。当数量级直线上升的时候，其背后的难度是几何增长的。
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，今天主要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。
一开始各个模块都把需要调用的服务地址放到配置文件里，每次修改或者添加了服务需要修改各自的配置文件。而且NLU和BOT的服务是动态变化的。所以修改配置文件特别不灵活。为了解决这个问题，我们基于ETCD做了服务发现。在ETCD中约定一个目录，当服务有新增或者删除的时候，webServer会调用ETCD的接口，修改目录中的配置 ；“中控”watch某个目录，当内容有变的时候，读取服务配置存储到redis中。当请求到达“中控”的时候，“中控”根据请求中的场景ID，获取服务地址、并调用相关的NLU、FAQ服务。
首先是运维成本，包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等；
文章目录 1. Redis主从复制 1.1. 作用 1.2. 搭建前的准备 1.3. 主从节点关系 1.4. 查看复制信息 info replication 1.5. 建立复制 1.5.1. 动态配置 1.5.2. 配置文件配置 1.5.3. 操作 1.6. 断开复制 1.7. 切主 1.7.1. 执行流程 1.7.2. 提示 1.8. 安全性 1.9. 只读 1.10. 传输延迟 1.10.1. 提示 1.11. 一主一从 1.12. 一主多从 1.13. 树状主从结构 Redis主从复制 本章介绍
* 主要思路： 1、数据变更还是通过MQ通知； 2、数据异构Worker得到通知，然后按照一些维度进行数据存储，存储到数据异构JIMDB集群（JIMDB：Redis+持久化引擎），存储的数据都是未加工的原子化数据，如商品基本信息、商品扩展属性、商品其他一些相关信息、商品规格参数、分类、商家信息等； 3、数据异构Worker存储成功后，会发送一个MQ给数据同步Worker，数据同步Worker也可以叫做数据聚合Worker，按照相应的维度聚合数据存储到相应的JIMDB集群；三个维度：基本信息（基本信息+扩展
Redis 主从架构下，使用默认的异步复制模式来同步数据，其特点是低延迟和高性能。当 Redis master 下有多个 slave 节点，且 slave 节点无法进行部分重同步时， slave 会请求进行全量数据同步，此时 master 需要创建 RDB 快照快照发送给 slave ，从节点收到 RDB 快照到开始解析与加载。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
