- 综合排序
- 最热优先
- 最新优先
- 来自专栏程序员升级之路
多机房RPC调用实践
最近做的项目是和多机房有些关系，不过不是做多活，而是将数据从一个机房拆到多个机房，业务上又允许用户异地访问，即数据分业务数据和用户数据，业务数据跟业务发生的机房绑定，用户数据只有一份，按需要跨区访问 ： 上图中用户A注册时选择的国家最终保存在A机房，用户A可以到B机房下单，按照隐私合规的要求，用户A的数据只能保存一份，因此D机房下单时必须从A机房获取用户信息，就有跨机房调用的场景了； 还有原来的场景，在没做多机房改造之前，下订单也要查询用户信息，不过这里是同机房调用了； 上面就是RPC调用的2种典型场景，RPC调用系统上要支持同机房调用也支持跨机房调用，什么时候是同机房，什么时候是跨机房 只要路由表算出来的结果是准确的，最终选择的机房就是正确的，如果在Provider做，则所有Provider要感知其它机房的Provider，增加系统的复杂性； 2、性能下降不大 如果在Provider 这里再说下通过这个项目对中间件的理解，中间件应该要解决大部分常见问题，对于一些特殊的问题应该预留接口让接入方来实现以保持良好的扩展性，而不是把所有的实现细节都抛给接入方； 我们在做这个多机房调用的时候刚开始的时候想着路由的过程其实就是根据输入参数算出一个机房的
1.6K20发布于 2021-09-02 - 来自专栏一个执拗的后端搬砖工
Dubbo跨机房调用
一、背景 在一些跨境业务中,特别是电商或者SAAS场景,用户群体是分离的,经营者在国内,而产品使用者在海外,或者外海用户分布在多个大区,而数据中心在其中一个大区,那么就会存在一些跨大区或者跨机房的服务调用场景 那么就需要在双机房部署的时候,优先调用本机房服务,然后如果本机房没有服务或者不符合要求,那么会调用其他机房的服务。 二、实现方案 多注册中心 dubbo2.7.5版本引入了多注册中心集群负载均衡能力支持,对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡： 在Cluster Invoker }" weight=”80“ /> <dubbo:registry id="america" address="nacos://${nacos.address<em>2</em>}" weight=”20“ /> 默认， 任意可用 配置调整 对于亚洲大区,读写都只需要调用本机房的服务,只需配置: <dubbo:registry address="nacos://${asia.address}" preferred
4.7K81编辑于 2022-04-06 - 来自专栏架构师之路
多机房多活，多机房平滑迁移架构方案全集（上+中+下）
上篇 《多机房平滑迁移架构方案目标》，主要包含三块内容： （1）单机房架构的核心是什么？ （2）机房迁移架构方案的设计目标是什么？ （3）为什么说，想要平滑的实施机房迁移，临时性的多机房架构不可避免？ 中篇 《多机房多活，常见架构实践》，主要包含三块内容： （1）什么是理想多机房多活架构？ （2）理想多机房多活架构，存在什么问题，适用于什么业务场景？ （3）什么是伪多机房多活架构？适用于什么业务场景？ 下篇 《自顶向下的平滑机房迁移方案》，主要讲解了自顶向下，平滑机房迁移的架构方案： （1）站点层、业务服务层、基础服务层如何迁移？ （2）缓存层如何迁移？ （3）数据库层如何迁移？ 希望通过这三篇，大家能够对多机房多活架构，多机房平滑迁移架构与方案，有一个初步的了解。 任何脱离业务的架构设计都是耍流氓。
1.4K41发布于 2020-03-23 - 来自专栏架构师之路
多机房多活架构，究竟怎么玩？
如前文所述，如果将单机房“全连接”架构复制到多机房，会有大量跨机房调用，极大增加请求时延，是业务无法接受的，要想降低这个时延，必须实施“同机房连接”。 多机房多活架构，做不到理想状态下的“同机房连接”，有没有折中方案？ 如果完全避免跨机房调用的理想状态做不到，就尽量做到“最小化”跨机房调用。 ? ，只有跨机房读“写”库了； 该方案没有完全避免跨机房调用，但它做到了“最小化”跨机房调用，只有写请求是跨机房的。 ； 写业务比例相对少，只有很少请求会跨机房调用。 （2）跨机房写，会多10毫秒延时； 小结： （1）理想多机房多活架构，是纯粹的“同机房连接”，仅有异步数据同步会跨机房； （2）理想多机房多活架构，会有较严重数据一致性问题，仅适用于具备数据聚集效应的业务场景
1.6K21发布于 2020-03-23 - 来自专栏idba
有赞NSQ多集群多机房设计
文 | 鲁林 on 基础保障 一、Overview 从有赞双机房开始到金融云架构，针对业务方在多机房的应该部署以及消息发送订阅需求，需要 NSQ 针对双机房以及多机房部署提供消息发送与订阅服务。 本文主要介绍了 NSQ 双机房以及多机房设计以及经验总结。 二、场景和需求 下图是一个机房内基本的 NSQ 消息生产和消费的部署。一个机房内生产者往 NSQ 集群发消息，多个消费者订阅消息。 ? 五、双机房到多机房 随着业务增长，NSQ 集群上topic数量以及读写流量日渐增加，同时为了满足更多的业务场景，公司机房再度增加。 migrate 的双机房方案的实现主要基于 NSQ 在两个集群间的迁移设计，而多机房场景下，生产消费流量要求在多个集群之间路由。 ": "this.is.url.of.nsq3:4161" } } 支持多机房 lookup 代理的流程如下图： ?
2.3K20发布于 2019-07-17 - 来自专栏Laoqi's Linux运维专列
Ansible 多机房自动部署发布
而当服务器数量增加，甚至服务器可能存在于跨地域的不同机房情况下，如何减少部署发布的人力和时间成本，实现自动化部署发布和无缝发布，而且在部署发布期间仍然能够正常提供服务，就成为一个至关重要的问题。 由于风控服务在用户场景中处于非常重要的地位，对SLA要求极高，需要提供毫秒级别的访问质量，为了达到这一点，消除掉公网的消耗，需要支持多机房服务，而同时带来的问题就是，如何保持各机房的软件版本统一，能够做到快速的统一发布 version yum: pkg=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 inventory文件，分别为production、staging，inventory文件中定义对应环境的服务器所在的组，以staging为例，web_server_sh、web_server_bj表示两个机房的主机 六、总结 ansible 很好的帮助了我们解决了自动化部署发布的事情，现在项目同步更新到几个机房，已经只需要几分钟就可以完成，节省了许多人力。
2K30发布于 2018-05-31 - 来自专栏杨建荣的学习笔记
MySQL机房多活的初步设想
我们主要从数据延迟和数据冲突来展开，如下是一个多IDC架构的设计方案，可以把两个不同的业务整合起来，做到schema级别的隔离，然后业务侧可以实现多写。 ? 比如北京顺义和亦庄可以作为同城机房，但是因为地域距离，必然会产生延迟，其实对于有些业务来说，如果为了追求数据强一致性，那么吞吐量就会打折，所以如果是数据写入，那么理想的情况应该是数据写入应该成功，数据的复制关系应该是异步模式
1.4K40发布于 2019-07-22 - 来自专栏JavaEdge
微服务应用的多机房部署
为了实现高可用性，微服务一般部署在多机房，只要部署到多机房就万无一失了？ Tomcat容器配置到电信机房的Nginx的upstream里 2 多机房数据同步 想要实现服务部署到多机房，供用户访问是有前提的，即每个机房的数据都一样，这就要求多机房间数据必须保持同步。 2.独立机房架构 联通和电信机房都有写请求，通过消息同步组件把各自机房的写请求同步一份给对方机房，相当于每个机房都有全量写请求。 更简单方案如下： RPC调用实现 联通机房写请求会调用联通机房reship RPC=》调用电信机房collector RPC=》调用电信机房的处理机RPC，达到把联通机房写请求同步给电信机房处理机 多机房数据一致性 系统会给每次写请求生成一个全局唯一requestId，联通机房写请求： 调用联通机房的处理机RPC修改缓存和DB 调用联通机房的reship RPC，reship RPC再调用电信机房的collector
89330编辑于 2021-12-07 - 来自专栏用户9973510的专栏
服务器多线机房怎么判断
1、BGP多线机房 首先一个机房要想成为BGP多线机房，要具有自主IP和AS号;IP用来在移动、联通、电信等运营商之间广播学习，而AS号可以中国互联网信息中心(www.cnnic.cn)查询到;其次， 具备上述条件如果依然不能满足我们的南北互联互通的需求，这样的机房也算不上BGP多线机房。 这里我们可以使用第三方测速工具来检查不同区域不同线路到机房响应时间，如果仅个别区域出现超时情况，此类机房还是可以考虑的。 2、多线多IP机房 这类机房，IDC服务商会给你提供多个IP，比如说一个电信IP，一个网通IP。 如果你通过远程桌面登录服务器，看到服务器上绑定了多个IP，同时这个域名还解析到了多个IP，那么这是多线多IP机房。
3.2K10编辑于 2022-09-14 - 来自专栏用户6296428的专栏
有赞发号器多机房方案
作者：小朋友 团队：中间件团队 有赞发号器多机房方案 发号器一般用来产生全局唯一 ID，有赞发号器的设计及背景参见文章《如何做一个靠谱的发号器》，本文在此基础上进行扩展，提供多机房发号与集群拆分能力，下文中使用 发号器架构 问题 根据图1 架构可以看出，将 etcd 跨多机房部署，借助 etcd 本身的就能保证在多机房的数据一致性及可用性，但在实践中还是会碰到一些问题： 若只有两个机房，没法实现机房级别的高可用 （极端情况下一个机房完全不可用时需要人工恢复） March 单主节点模式，多机房时造成大量的跨机房请求，网络稳定性和时延都会变差 March 单主节点不利于水平扩展 集群拆分需要停机，运维复杂度高 多机房方案 图2. 发号器多机房架构 图2 架构进行调整后可以发现已经解决了上述的问题中的：1(高可用)、2(跨机房请求)、3(水平扩容) 这些问题，接下来会详细说明方案如何实现及问题4(动态拆分)的解决方案。 有经验的读者可能会想到，发号器多机房同时发号只需要在ID 上选取几个bit 位作为机房的标记就万事大吉了，其实有赞的实现并非如此，其中原因牵涉到一些历史背景。
1.1K40发布于 2020-08-24 - 来自专栏猿天地
线上SpringCloud网关调用微服务跨机房了，咋整？
问题很明显，就是网关服务只有北京的，而微服务新增了天津机房的，此时会导致 跨机房调用，即北京网关调用到了天津微服务。 相当于网关以及微服务两侧都是通过基于 权重 的负载均衡算法来尽量减少跨机房调用的，但是无法避免跨机房调用。 zone：简单理解为 region 内的具体机房，比如说 zone 划分为北京、天津，且北京有两个机房，就可以在 region 内划分为三个zone，北京划分为zone1、zone2，天津为zone3。 最开始获取的Servers一共是有4条记录，根据调试的代码看，我们是为了获取 zone 为2的服务，所以得到的结果是一条，即 zone = "2"，说明找到了同 zone 服务。 ，内部会调用到ILoadBalancer 具体实现的 chooseServer() 方法，最终会获取到 zone="2" 里的一个Server。 ? 那么这里是如何选择的Server呢？
1.6K30发布于 2020-03-11 - 来自专栏devops
【架构实战】多机房容灾架构设计方案
一、为什么需要多机房容灾单机房部署存在诸多风险：硬件故障：服务器、交换机、存储设备故障电力中断：UPS电池耗尽、发电机故障网络故障：光纤被挖断、运营商故障自然灾害：火灾、水灾、地震等不可抗力人为失误：运维操作失误导致服务中断多机房容灾的目标 ：RTO（恢复时间目标）：接近0RPO（恢复点目标）：数据丢失接近0二、多机房架构模式1.主备模式（Active-Standby）展开代码语言：TXTAI代码解释主机房（Active）←同步复制→备机房 ，另一机房承载全部流量技术挑战：跨机房网络延迟（10-50ms）数据一致性保证请求路由的准确性3.多活模式（Multi-Active）展开代码语言：TXTAI代码解释机房A←→机房B←→机房C←→机房D =2auto-increment-increment=2relay-log=relay-bin建立复制关系：展开代码语言：SQLAI代码解释--机房A配置CHANGEMASTERTOMASTER_HOST 解决方案：强一致性场景使用同步复制最终一致性场景使用异步复制+补偿机制重要数据采用"写入确认"机制七、总结多机房容灾是保障业务高可用的终极方案：架构选型：根据业务需求选择主备、双活或多活数据同步：根据数据特性选择同步方案流量调度
5900编辑于 2026-04-09 - 来自专栏Django Scrapy
python3 下调用zabbix api 获取多个机房的IP
根据工作的需要，需要查看监控中的所有ip，我们一共有三个机房，每个机房都部署了同样的zabbix监控 根据三个园区的 监控api的url 实现功能：不输入参数 显示所有ip 输入参数 ali yq m6 = json.loads(token.text) return json_dict_token['result'] def get_3area_ips(self): # 调用接口 "output": ["host",], }, "auth": self.get_token(), #调用之前的 item.get_3area_ips() else: item = Zabbix_ip_3area(sys.argv[1]) # 用IDE工具运行会报错 terminal调用使用
2.1K50发布于 2018-04-11 - 来自专栏深度学习与python
基于 MySQL 多通道主主复制的机房容灾方案
多主一从 多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上，方便统一分析处理。 两地三中心 MySQL 主从方案 2 为解决复制回路问题，在主机房边界节点实例上，本方案使用上文中根据对端主库 server id 判断是否和 event 的 server id 相同，对 IDC1 边界 总 结 该 MySQL 数据同步方案优化了 MySQL 本身的日志同步机制，引入多通道主主复制技术，降低了机房容灾演练和回切时数据同步关系调整带的复杂性；每个通道仅同步临近主库 binlog event 依托数据库多通道主主复制数据容灾技术，机房容灾切换时间由传统的 30 分钟降低到 5 分钟，相关脚本集成到自动化平台后进一步降低到 2 分钟以内。机房回切效率由传统的 1 小时降低到 5 分钟以内。 今日好文推荐 “谷歌有谷歌的规矩” 丢掉 LangChain、像 Docker一样编排大模型应用程序：这支十余人的年轻创业团队如何在2个月做出一个LLMOps平台？
83720编辑于 2023-11-17 - 来自专栏腾讯数据库技术
腾讯云MongoDB多机房部署场景下就近访问原理详解
提示：公众号展示代码会自动折行，建议横屏阅读 多机房容灾是存储系统领域非常重要的课题。 本文将从内核代码层面，介绍腾讯云MongoDB数据库系统（CMongo）在多机房部署场景下，如何实现业务到机房的就近访问，并保证数据一致性。 1. 背景介绍 为了保证服务可用性和数据可靠性，一些重要业务会将存储系统部署在多地域多机房。 比如在北京，上海，深圳 每个地域的机房各存储一份数据副本，保证即使某个地域的机房无法提供访问，也不会影响业务的正常使用。 在多机房部署时，需要考虑多机房之间的网络延迟问题。 写操作是需要跨机房同步数据的，所以如果业务模型是写多读少，需要谨慎考虑。
5.4K62发布于 2019-08-29 - 来自专栏CSDN技术头条
荔枝FM架构师刘耀华：异地多活IDC机房架构
多机房架构存在的原因 单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可用。 荔枝 FM 要求业务离用户最近，南方的用户连南方的机房，北方的用户连北方的机房，国外的用户连国外的机房。大陆的网络和国外的网络有一定的隔离性，如果没有做多机房的连通性，数据的传输和实时性就会有问题。 跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝 FM 做跨机房的原因。 做过数据备份的各位一定知道CAP理论。 最佳实践 首先把坑总结出来：一是数据切分，当数据量到达一定的情况，一定会出现分片，分片有两种，一是用户库、电台库、数据库；二是ID，尾数1是1，尾数2是2。 超时非常难搞，可能是请求处理了，但没有响应，也有可能根本没处理，调用者根本不知道是哪种情况。如果操作不幂等，客户端会出现数据失败和冲突。 每次同一个操作都不会影响数据，都会产生同一个结果。
2K61发布于 2018-02-11 - 来自专栏爱可生开源社区
技术分享 | 基于 MySQL 多通道主主复制的机房容灾方案
灾难与 RTO、RPO 的关系 灾难恢复能力等级 RTO RPO 1 2 天以上 1 天至 7 天 2 24 小时以后 1 天至 7 天 3 12 小时以上 数小时至 1 小时 4 数小时至 2 天 数小时至 1 小时 5 数分钟至 2 天 0 至 30 分钟 6 数分钟 0 两地三中心容灾 两地三中心能够组合本地高可用，同城灾备中心，异地灾备中心，提高可用性，提升业务连续性，重点业务多采用“两地三中心” 两地三中心 MySQL 主从方案 2 为解决复制回路问题，在主机房边界节点实例上，本方案使用上文中根据对端主库 server id 判断是否和 event 的 server id 相同，对 IDC1 边界 5总结 该 MySQL 数据同步方案优化了 MySQL 本身的日志同步机制，引入多通道主主复制技术，降低了机房容灾演练和回切时数据同步关系调整带的复杂性；每个通道仅同步临近主库 binlog event 依托数据库多通道主主复制数据容灾技术，机房容灾切换时间由传统的 30 分钟降低到 5 分钟，相关脚本集成到自动化平台后进一步降低到 2 分钟以内。机房回切效率由传统的 1 小时降低到 5 分钟以内。
1.8K51编辑于 2023-11-01 - 来自专栏携程技术
干货 | 携程数据基础平台2.0建设，多机房架构下的演进
在 OPS 团队的大力支持下，启动了第三个 IDC 数据机房建设项目，2 个月内交付了新 IDC。 二、面临的问题 随着集群规模不断增长，2022-2023 年亟待解决的基础平台几大痛点： 多机房架构支持三数据中心架构，数据存储和计算调度 数据迅速增长、机房需要建设周期，冷数据搬迁上云上对象存储可以有效缓解整体存储容量压力 存储层支持多机房架构， 热/温/冷三分层数据，透明迁移，并且具备读取缓存，透明加速的能力。 四、存储 4.1 多机房架构升级：支撑三个以上数据中心架构 Hadoop 多机房架构升级，数据支持按 IDC 或者跨多个 IDC 共享，Client 支持就近读写，避免产生跨机房流量，新增数据中心对使用数据平台的用户无感知 跨机房的数据迁移，实现跨机房副本分布配置，支持路径的数据可以按单机房或者多机房策略放置，实现 Client 可以就近读和写，对用户无感。
99710编辑于 2024-05-31 - 来自专栏ytkah
调用finecms栏目多图怎么实现
finecms栏目自定义字段添加图集怎么调用出来？已经上传两张图片了，点击可以预览图片，前端显示不了，如下图所示。 调用栏目多图这个要涉及到二次开发，首先要先添加栏目自定义字段，设为文件的格式，然后可以插入如下的代码，亲测可用，不明白的小伙伴可以加ytkah微信寻求帮助 {php $bb=dr_string2array
98560发布于 2018-03-06 - 来自专栏魏艾斯博客www.vpsss.net
Linode 开通日本 TK2 机房线路体验及速度性能评测
今天我们来写一下开通Linode 日本 TK2 机房线路体验及速度性能评测的过程。希望对初次接触 Linode 的朋友有所帮助，这也是老魏写博客一直坚持的想法。 这里详细说一下开通日本 TK2 机房线路的操作过程。 二、开通日本 TK2 机房线路 首先你的账户中得有余额足够购买对应的配置。 三、Linode VPS 日本 2 号机房线路评测 PING 速度测试结果 ? 路由线路图 ? CPU 内存等配置信息 ? IO 读写和随机下载测试 ? 最后总结 Linode 的日本 TK2 机房线路，总体来说比美国线路对大陆的连接速度要快且稳定，而且目前价格也降低到了 5 美元/月的 1G 内存套餐了，对于一般网站和项目来说配置、速度都足够了。 目前看 TK1 线路不会再开放了，TK2 对大陆是最好的选择。
3.6K30发布于 2018-06-01
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号