- 综合排序
- 最热优先
- 最新优先
- 来自专栏程序员升级之路
多机房RPC调用实践
最近做的项目是和多机房有些关系，不过不是做多活，而是将数据从一个机房拆到多个机房，业务上又允许用户异地访问，即数据分业务数据和用户数据，业务数据跟业务发生的机房绑定，用户数据只有一份，按需要跨区访问 ： 上图中用户A注册时选择的国家最终保存在A机房，用户A可以到B机房下单，按照隐私合规的要求，用户A的数据只能保存一份，因此D机房下单时必须从A机房获取用户信息，就有跨机房调用的场景了； 还有原来的场景，在没做多机房改造之前，下订单也要查询用户信息，不过这里是同机房调用了； 上面就是RPC调用的2种典型场景，RPC调用系统上要支持同机房调用也支持跨机房调用，什么时候是同机房，什么时候是跨机房 路由表是典型的写少读多的场景，这里不具体讨论路由表的设计，注意数据的规模和一些一致性要求细节即可。 这里再说下通过这个项目对中间件的理解，中间件应该要解决大部分常见问题，对于一些特殊的问题应该预留接口让接入方来实现以保持良好的扩展性，而不是把所有的实现细节都抛给接入方； 我们在做这个多机房调用的时候刚开始的时候想着路由的过程其实就是根据输入参数算出一个机房的
1.6K20发布于 2021-09-02 - 来自专栏一个执拗的后端搬砖工
Dubbo跨机房调用
一、背景 在一些跨境业务中,特别是电商或者SAAS场景,用户群体是分离的,经营者在国内,而产品使用者在海外,或者外海用户分布在多个大区,而数据中心在其中一个大区,那么就会存在一些跨大区或者跨机房的服务调用场景 那么就需要在双机房部署的时候,优先调用本机房服务,然后如果本机房没有服务或者不符合要求,那么会调用其他机房的服务。 二、实现方案 多注册中心 dubbo2.7.5版本引入了多注册中心集群负载均衡能力支持,对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡： 在Cluster Invoker registry id="america" address="nacos://${nacos.address2}" weight=”20“ /> 默认，任意可用 配置调整 对于亚洲大区,读写都只需要调用本机房的服务 六、参考 ZoneAwareClusterInvoker 2.7.5新特性 多注册中心机制 [Dubbo-6034]
4.7K81编辑于 2022-04-06 - 来自专栏架构师之路
多机房多活，多机房平滑迁移架构方案全集（上+中+下）
放假前三天，写了三篇长文，关于多机房多活，多机房平滑迁移架构与方案的。可能是临近放假，又亦或疫情的影响，阅读都比较低，现将“上中下”汇总成全集，一窥全貌，欢迎错过的同学补课。 上篇 《多机房平滑迁移架构方案目标》，主要包含三块内容： （1）单机房架构的核心是什么？ （2）机房迁移架构方案的设计目标是什么？ （3）为什么说，想要平滑的实施机房迁移，临时性的多机房架构不可避免？ 中篇 《多机房多活，常见架构实践》，主要包含三块内容： （1）什么是理想多机房多活架构？ （2）理想多机房多活架构，存在什么问题，适用于什么业务场景？ （3）什么是伪多机房多活架构？适用于什么业务场景？ 希望通过这三篇，大家能够对多机房多活架构，多机房平滑迁移架构与方案，有一个初步的了解。 任何脱离业务的架构设计都是耍流氓。
1.4K41发布于 2020-03-23 - 来自专栏架构师之路
多机房多活架构，究竟怎么玩？
如前文所述，如果将单机房“全连接”架构复制到多机房，会有大量跨机房调用，极大增加请求时延，是业务无法接受的，要想降低这个时延，必须实施“同机房连接”。 多机房多活架构，做不到理想状态下的“同机房连接”，有没有折中方案？ 如果完全避免跨机房调用的理想状态做不到，就尽量做到“最小化”跨机房调用。 ? ，只有跨机房读“写”库了； 该方案没有完全避免跨机房调用，但它做到了“最小化”跨机房调用，只有写请求是跨机房的。 ； 写业务比例相对少，只有很少请求会跨机房调用。 该多机房多活架构，并没有做到100%的“同机房连接”，通常称作伪多机房多活架构。 伪多机房多活架构，有“主机房”和“从机房”的差别。
1.6K21发布于 2020-03-23 - 来自专栏idba
有赞NSQ多集群多机房设计
文 | 鲁林 on 基础保障 一、Overview 从有赞双机房开始到金融云架构，针对业务方在多机房的应该部署以及消息发送订阅需求，需要 NSQ 针对双机房以及多机房部署提供消息发送与订阅服务。 本文主要介绍了 NSQ 双机房以及多机房设计以及经验总结。 二、场景和需求 下图是一个机房内基本的 NSQ 消息生产和消费的部署。一个机房内生产者往 NSQ 集群发消息，多个消费者订阅消息。 ? 五、双机房到多机房 随着业务增长，NSQ 集群上topic数量以及读写流量日渐增加，同时为了满足更多的业务场景，公司机房再度增加。 migrate 的双机房方案的实现主要基于 NSQ 在两个集群间的迁移设计，而多机房场景下，生产消费流量要求在多个集群之间路由。 针对新的多机房集群需求，我们重新设计了 migrate 的数据结构，提出了一种保存 lookup 数据格式，以及一种 lookup 地址的 schema。
2.3K20发布于 2019-07-17 - 来自专栏Laoqi's Linux运维专列
Ansible 多机房自动部署发布
而当服务器数量增加，甚至服务器可能存在于跨地域的不同机房情况下，如何减少部署发布的人力和时间成本，实现自动化部署发布和无缝发布，而且在部署发布期间仍然能够正常提供服务，就成为一个至关重要的问题。 由于风控服务在用户场景中处于非常重要的地位，对SLA要求极高，需要提供毫秒级别的访问质量，为了达到这一点，消除掉公网的消耗，需要支持多机房服务，而同时带来的问题就是，如何保持各机房的软件版本统一，能够做到快速的统一发布 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 多机房数据同步 想要实现服务部署到多机房，供用户访问是有前提的，即每个机房的数据都一样，这就要求多机房间数据必须保持同步。 更简单方案如下： RPC调用实现 联通机房写请求会调用联通机房reship RPC=》调用电信机房collector RPC=》调用电信机房的处理机RPC，达到把联通机房写请求同步给电信机房处理机 多机房数据一致性 系统会给每次写请求生成一个全局唯一requestId，联通机房写请求： 调用联通机房的处理机RPC修改缓存和DB 调用联通机房的reship RPC，reship RPC再调用电信机房的collector RPC同步写请求，电信机房的collector RPC最后会调用电信机房的处理RPC来更新缓存。
89130编辑于 2021-12-07 - 来自专栏用户6296428的专栏
有赞发号器多机房方案
作者：小朋友 团队：中间件团队 有赞发号器多机房方案 发号器一般用来产生全局唯一 ID，有赞发号器的设计及背景参见文章《如何做一个靠谱的发号器》，本文在此基础上进行扩展，提供多机房发号与集群拆分能力，下文中使用 发号器架构 问题 根据图1 架构可以看出，将 etcd 跨多机房部署，借助 etcd 本身的就能保证在多机房的数据一致性及可用性，但在实践中还是会碰到一些问题： 若只有两个机房，没法实现机房级别的高可用 （极端情况下一个机房完全不可用时需要人工恢复） March 单主节点模式，多机房时造成大量的跨机房请求，网络稳定性和时延都会变差 March 单主节点不利于水平扩展 集群拆分需要停机，运维复杂度高 多机房方案 发号器多机房架构 图2 架构进行调整后可以发现已经解决了上述的问题中的：1(高可用)、2(跨机房请求)、3(水平扩容) 这些问题，接下来会详细说明方案如何实现及问题4(动态拆分)的解决方案。 有经验的读者可能会想到，发号器多机房同时发号只需要在ID 上选取几个bit 位作为机房的标记就万事大吉了，其实有赞的实现并非如此，其中原因牵涉到一些历史背景。
1.1K40发布于 2020-08-24 - 来自专栏用户9973510的专栏
服务器多线机房怎么判断
1、BGP多线机房 首先一个机房要想成为BGP多线机房，要具有自主IP和AS号;IP用来在移动、联通、电信等运营商之间广播学习，而AS号可以中国互联网信息中心(www.cnnic.cn)查询到;其次， 具备上述条件如果依然不能满足我们的南北互联互通的需求，这样的机房也算不上BGP多线机房。 这里我们可以使用第三方测速工具来检查不同区域不同线路到机房响应时间，如果仅个别区域出现超时情况，此类机房还是可以考虑的。 2、多线多IP机房 这类机房，IDC服务商会给你提供多个IP，比如说一个电信IP，一个网通IP。 如果你通过远程桌面登录服务器，看到服务器上绑定了多个IP，同时这个域名还解析到了多个IP，那么这是多线多IP机房。
3.1K10编辑于 2022-09-14 - 来自专栏猿天地
线上SpringCloud网关调用微服务跨机房了，咋整？
问题很明显，就是网关服务只有北京的，而微服务新增了天津机房的，此时会导致 跨机房调用，即北京网关调用到了天津微服务。 但是，大家看 粉红色粗体 的线条，仍然存在跨机房调用，天津网关调用到北京微服务。 对于线上并发访问量稍微大点，或者有些接口响应体大的，又或者网络抖动等场景下，可能就会导致接口响应时间变长了。 相当于网关以及微服务两侧都是通过基于 权重 的负载均衡算法来尽量减少跨机房调用的，但是无法避免跨机房调用。 过滤器内部获取同一机房（zone）的服务列表，先后会调用 ZonePreferenceServerListFilter 和 ZoneAffinityServerListFilter 两个过滤器实现 zone 本文提到的只是网关到微服务之间的调用，实际项目中，微服务还会调用其他第三方的服务，也要同时考虑到跨机房调用的问题，尽量都让各服务之间在同机房调用，减少网络延时，提高服务的稳定性。
1.6K30发布于 2020-03-11 - 来自专栏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 - 来自专栏Netkiller
怎样入住IDC机房或迁移IDC机房
机房迁移 总结一下5年前的工作，在不写下来自己都快忘光了，工作关系现在已经不涉及运维这块的工作。 4.3.1.
15.2K50发布于 2018-03-05 - 来自专栏腾讯数据库技术
腾讯云MongoDB多机房部署场景下就近访问原理详解
提示：公众号展示代码会自动折行，建议横屏阅读 多机房容灾是存储系统领域非常重要的课题。 本文将从内核代码层面，介绍腾讯云MongoDB数据库系统（CMongo）在多机房部署场景下，如何实现业务到机房的就近访问，并保证数据一致性。 1. 背景介绍 为了保证服务可用性和数据可靠性，一些重要业务会将存储系统部署在多地域多机房。 比如在北京，上海，深圳 每个地域的机房各存储一份数据副本，保证即使某个地域的机房无法提供访问，也不会影响业务的正常使用。 在多机房部署时，需要考虑多机房之间的网络延迟问题。 写操作是需要跨机房同步数据的，所以如果业务模型是写多读少，需要谨慎考虑。
5.3K62发布于 2019-08-29 - 来自专栏深度学习与python
基于 MySQL 多通道主主复制的机房容灾方案
一主多从 一主多从常见的主从架构，使用起来简单有效，不仅可以实现 HA，而且还能读写分离，进而提升集群的并发能力。 多主一从 多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上，方便统一分析处理。 本方案通过机房内建立 MySQL 主主复制，此时主从切换无需繁琐的命令，只需要设置 read_only；同城机房间也是建立主主复制，方便容灾演练回切，无需复杂的配置。 总 结 该 MySQL 数据同步方案优化了 MySQL 本身的日志同步机制，引入多通道主主复制技术，降低了机房容灾演练和回切时数据同步关系调整带的复杂性；每个通道仅同步临近主库 binlog event 依托数据库多通道主主复制数据容灾技术，机房容灾切换时间由传统的 30 分钟降低到 5 分钟，相关脚本集成到自动化平台后进一步降低到 2 分钟以内。机房回切效率由传统的 1 小时降低到 5 分钟以内。
80020编辑于 2023-11-17 - 来自专栏CSDN技术头条
荔枝FM架构师刘耀华：异地多活IDC机房架构
多机房架构存在的原因 单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可用。 荔枝 FM 要求业务离用户最近，南方的用户连南方的机房，北方的用户连北方的机房，国外的用户连国外的机房。大陆的网络和国外的网络有一定的隔离性，如果没有做多机房的连通性，数据的传输和实时性就会有问题。 跨机房的作用是为了备份，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝 FM 做跨机房的原因。 做过数据备份的各位一定知道CAP理论。 而数据多版本，类似于乐观锁，导致其他人和我方数据冲突的机会并不是那么多，只要在提交的时候发现版本不一样，更新一下，汇总数据就可以了。 超时非常难搞，可能是请求处理了，但没有响应，也有可能根本没处理，调用者根本不知道是哪种情况。如果操作不幂等，客户端会出现数据失败和冲突。 每次同一个操作都不会影响数据，都会产生同一个结果。
2K61发布于 2018-02-11 - 来自专栏爱可生开源社区
技术分享 | 基于 MySQL 多通道主主复制的机房容灾方案
一主多从 一主多从常见的主从架构，使用起来简单有效，不仅可以实现 HA，而且还能读写分离，进而提升集群的并发能力。 多主一从 多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上，方便统一分析处理。 本方案通过机房内建立 MySQL 主主复制，此时主从切换无需繁琐的命令，只需要设置 read_only；同城机房间也是建立主主复制，方便容灾演练回切，无需复杂的配置。 5总结 该 MySQL 数据同步方案优化了 MySQL 本身的日志同步机制，引入多通道主主复制技术，降低了机房容灾演练和回切时数据同步关系调整带的复杂性；每个通道仅同步临近主库 binlog event 依托数据库多通道主主复制数据容灾技术，机房容灾切换时间由传统的 30 分钟降低到 5 分钟，相关脚本集成到自动化平台后进一步降低到 2 分钟以内。机房回切效率由传统的 1 小时降低到 5 分钟以内。
1.8K51编辑于 2023-11-01 - 来自专栏用户8739405的专栏
idc机房的特点是什么？idc机房和自建机房有什么不同？
不管是什么行业都在广泛使用着idc机房，idc机房也就是一种超大型机房，它利用互联网的通信技术，建立起标准化的数据中心环境，能够给各种单位、各种公司提供全方位的服务，但是由于很多人并不了解idc机房，所以下面为大家具体地介绍一下 idc机房的特点是什么，以及idc机房和自建机房有什么不同。 最后，idc机房分为两种，一种是自用型，一种是商用型，这两种类型的机房都对环境的要求比较高。 二、idc机房和自建机房有什么不同？ 1、网络连接率较高。 idc机房必须按照国际标准进行设计，不管是电力设施还是消防体系，都十分可靠，如果是自建机房的话，则无法提供标准的机房环境，可能会减少服务器的寿命增加，出现故障的概率。 上面为大家简要介绍了idc机房，同自建机房相比，idc机房确实有很多优势。
10.8K30发布于 2021-07-02 - 来自专栏力哥聊运维与云计算
如何管理好IDC机房？（四） ----机房安全管理
如何管理好IDC机房？（四） ----机房安全管理 机房大部分设备都在公网上，安全工作搞不好，轻则影响业务运行，重则可能会丢失数据，造成不可弥补的损失。 2 技术方面 根据我的经验，采取一下技术措施，可以有效实现机房安全管理。 1) 复杂口令，定期更换。如有条件建议采取令牌认证等认证手段。
3K20发布于 2019-06-28 - 来自专栏鲜枣课堂
机房生存指南
说到机房，大家一定都很熟悉。 对于我们通信汪来说，机房就像我们的家。我们生命中很大一部分时间，是在机房度过的。 ? 在外界看来，机房是一个高大上且充满神秘感的地方。 机房之所以叫机房，就是因为这里存放了大量的机器设备。 ? 为了保证这些设备不会因为发热量太高而宕机罢工，机房通常都会配备强力空调进行散热降温。 所以，机房的温度会非常低，有时候甚至只有10℃左右。 KVM，Keyboard Video Mouse，多计算机切换器 这个时候，就会很麻烦。你看到电视上帅哥一手托电脑，一手敲键盘，貌似很帅的样子，你让他保持几个小时试试看？手都要残废掉。。。 在机房的时候，千万不要喝太多的水，万一你喝多了想要嘘嘘，万一你没有机房的门禁卡，万一局方工程师不在，万一你手机没信号，那么，你就惨了。。。（不要问我为什么有这么多“万一”，我不会告诉你原因的。 一定要事先观察好机房摄像头的位置！ 好啦！机房的四个大坑以及应对策略，我都介绍完了。 事实上，机房的坑远不止上述这些。
3.1K250发布于 2020-06-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号