- 综合排序
- 最热优先
- 最新优先
- 来自专栏在码圈
Nginx+Keepalived 保障HA高可用
什么事应用程序的高可用 高可用性(high availability)通常用来描述一个系统经过专门的设计,从而减少停工的时间,而保持其服务的高度可用性 说白了，就是保障服务器应用红旗不倒 前提 服务器如果采用 ，但是实际上是可用的 如果对于要求服务高可用的公司来说，这就成了严重的单点故障 解决思路是 增加一台备用Nginx服务器，当主Nginx负载服务器宕机后，备用机毫秒级瞬间顶上去 图例： ? Lvs+Keepalived 保障HA高可用 跳转至 https://www.arcinbj.com/archives/ha2 安装 Keepalived (主备负载服务器都需要安装) yum install unicast_peer { 192.0.0.3 ##（对端IP地址）此地址一定不能忘记 } priority 100 ## 节点优先级，值范围 0-254，MASTER 要比BACKUP 高 nopreempt ## 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题 advert_int 1 ## 组播信息发送间隔，两个节点设置必须一样，默认 1s
96230发布于 2020-07-21 - 来自专栏在码圈
Lvs+Keepalived 保障HA高可用
前面讲了Nginx+Keepalived 保障HA高可用 这是 Lvs+Keepalived 保障HA高可用 什么是 Lvs LVS的英文全称是Linux Virtual Server，即Linux虚拟服务器 内存2.6中，它已经成为内核的一部分，在此之前的内核版本则需要重新编译内核 Lvs是属于4层网络协议，Nginx是属于7层网络协议 Lvs只做转发和监听，不负责握手 Nginx+Keepalived 保障 HA高可用 跳转至 https://www.arcinbj.com/archives/ha1 安装 Keepalived 和 ipvsadm yum install keepalived ipvsadm
83530发布于 2020-07-22 - 来自专栏得物技术
系统稳定性与高可用保障
一、前言 高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。 二、高可用的定义 业界常用 N 个 9 来量化一个系统可用性程度，可以直接映射到网站正常运行时间的百分比上。 要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。 所以，又往往是通过“自动故障转移”来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。 如何做好稳定性和高可用保障是一个很庞大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的系统高可用建设过程中，有一套系统的框架可以参考。最后感谢耐心看完的同学。
1.2K21编辑于 2023-06-06 - 来自专栏软件工程
Redis哨兵(Sentinel)机制 --高可用的保障
背景：哨兵是redis集群架构中非常重要的一个组件,我们想要保证redis的高可用性，必须保证我们的redis集群可以做到 故障转移或者说是主备切换。 一 . 当其恢复后命令它去复制新的master节点 配置中心，如果故障转移发生了，通知client客户端新的master地址 二 哨兵机制和核心内容 2.1 Redis Sentinel本身也是一个分布式系统 试想如果用来保障 redis集群高可用的哨兵是单机的，然后哨兵挂了，redis也挂了，这tm是何等卧槽？ 2.2 哨兵常规配置 （1）哨兵至少需要3个实例，来保证自己的健壮性 （2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性 为什么redis哨兵集群只有2
92930编辑于 2021-12-24 - 来自专栏性能与架构
Hadoop如何使用Zookeeper来保障高可用？
从图中就可以看出 ResourceManager 的地位非常重要，负责集群中所有资源的管理分配，与其他部分进行沟通协作，所以，ResourceManager必须是高可用的。
1.8K60发布于 2018-04-04 - 来自专栏DT乱“码”
原 如何保障数据库的高可用
低读低写并发、低数据量方案 方案一：双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。 .51cto.com/art/201012/237204.htm http://gaoke.iteye.com/blog/2283890 4.适应场景 读和写都不高的场景（单表数据低于500万），双机高可用 4.适应场景 读和写都不是非常高的场景（单表数据低于1000万），高可用。比方案一并发要高很多。 5.优缺点 优点是一个机器故障了可以自动切换；读写分离，并发有了很大的提升。 缺点是引入了一个Mycat节点，若要高可用需要引入至少两个Mycat。常规的解决方案是引入haproxy和keepalive对mycat做集群。 当然，Mycat依然需要设计高可用方案。
97720发布于 2018-06-06 - 来自专栏Java项目实战
Redis哨兵：保障高可用的守护神
引言 在现代分布式系统中，高可用性（High Availability，HA）是至关重要的。当一个关键组件出现故障时，系统需要能够自动切换到备用组件，以确保持续的服务可用性。 Redis是一个流行的内存数据库，它提供了很多强大的功能，但在保障高可用性方面，Redis哨兵（Sentinel）是一个不可或缺的组件。 本文将深入探讨Redis哨兵的主要功能，为您展示如何使用它来构建高可用的Redis集群。 Redis简介 Redis是一个开源的内存数据库，广泛用于缓存、会话管理和实时分析等场景。 总结 Redis哨兵是确保Redis高可用性的关键组件。它能够监视主服务器的运行状况，自动检测故障并触发故障转移，以确保服务的连续可用性。 在构建分布式系统时，高可用性是一个不可或缺的要素。Redis哨兵是一个强大的工具，可以帮助您实现Redis集群的高可用性。
40140编辑于 2023-09-25 - 来自专栏别先生
keepalived+Nginx实现主备保障Nginx的高可用。
Keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip（VIP = 这样的话就可以保证路由器的高可用了。 keepalived主要有三个模块，分别是core、check和VRRP。 4、如何实现keepalived+Nginx高可用环境。 两台nginx，一主一备：192.168.110.142和192.168.110.140。
1K20发布于 2019-10-08 - 来自专栏得物技术
浅谈系统稳定性与高可用保障的几种思路
一、前言 高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。 二、高可用的定义 业界常用N个9来量化一个系统可用性程度，可以直接映射到网站正常运行时间的百分比上。 要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。 所以，又往往是通过“自动故障转移”来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。 如何做好稳定性和高可用保障是一个很庞大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的系统高可用建设过程中，有一套系统的框架可以参考。最后感谢耐心看完的同学。
2.5K141编辑于 2022-11-02 - 来自专栏云服务器运维实践
Nginx系列教程(5)如何保障nginx的高可用性(keepalived)
不仅可以做Nginx的高可用，也可以做其他的例如Mysql高可用。 高可用故障切换转移原理 Keepalived高可用故障切换，是通过VRRP虚拟路由器冗余协议来实现的。 这样的话就可以保证路由器的高可用了。 keepalived主要有三个模块 分别是core、check和vrrp。 传统的高可用思路 tomcat的高可用的思路，是在tomcat集群前面加一层负载服务nginx。如下图 [rja206bt5o.png? 但是引入了前面的负载机器的高可用问题（Nginx如果挂了，玩完） 如果nginx沿用此思路，总会有一个最前端是单机的，存在宕机玩完的风险（鸡生蛋蛋生鸡无穷尽） 15.2. lvs 思想解决高可用问题 [
2.4K21发布于 2020-04-03 - 来自专栏CODING DevOps
CODING DevOps 高可用实践，保障服务稳定的“定海神针”
如何为客户提供高可用、不间断的服务体验，如何多层面、多渠道来保障 CODING 本身的服务稳定性，成为了 CODING 发展道路上不懈的追求。 除生产环境之外，CODING 还进行了备用环境的部署，如果发生发布事故，可迅速切换至备用环境，保障服务可用，在生产环境变更验收通过后，才会更新备用环境。 持续性架构升级，关键服务保障 除了通过云的能力和流程规范确保 CODING 整体的可靠性之外，根据不同产品线的不同场景，也在架构设计上进行了高可用保障。 在某个地域无法创建构建机器时，会导致使用该地资源节点的用户无法顺利构建，为了防范这个问题， CODING 持续集成采用灵活的容灾策略，对构建节点池进行地域切换，对故障进行转移，确保构建的稳定性，实现服务的高可用 在服务的扩展上，CODING 持续部署支持 HA 高可用拆分，同一服务可根据业务需求以及访问量，按功能拆分部署提供服务。
57520发布于 2021-03-16 YashanDB数据库的多区域分布部署及高可用保障
YashanDB是一种高性能、高可用的分布式数据库，它的多区域分布部署和高可用性保障是通过多种技术手段实现的。以下是一些关键要点，概述了YashanDB在这些方面的设计理念和实现方式：1. 高可用保障- 故障切换：YashanDB内置了自动故障切换机制。如果某个区域的节点发生故障，系统可以自动将流量切换到其他健康区域，确保服务持续可用。 总结YashanDB通过多区域分布、智能负载均衡、自动故障切换、共识算法等多种高可用性和分布式部署技术，确保了在面对区域性故障、网络分区等复杂场景时，系统能够继续稳定运行，满足用户对高可用性和性能的需求
19610编辑于 2025-11-21- 来自专栏CODING DevOps
CODING DevOps 高可用实践，保障服务稳定的“定海神针”
如何为客户提供高可用、不间断的服务体验，如何多层面、多渠道来保障 CODING 本身的服务稳定性，成为了 CODING 发展道路上不懈的追求。 除生产环境之外，CODING 还进行了备用环境的部署，如果发生发布事故，可迅速切换至备用环境，保障服务可用，在生产环境变更验收通过后，才会更新备用环境。 持续性架构升级，关键服务保障 除了通过云的能力和流程规范确保 CODING 整体的可靠性之外，根据不同产品线的不同场景，也在架构设计上进行了高可用保障。 在某个地域无法创建构建机器时，会导致使用该地资源节点的用户无法顺利构建，为了防范这个问题， CODING 持续集成采用灵活的容灾策略，对构建节点池进行地域切换，对故障进行转移，确保构建的稳定性，实现服务的高可用 在服务的扩展上，CODING 持续部署支持 HA 高可用拆分，同一服务可根据业务需求以及访问量，按功能拆分部署提供服务。
64440发布于 2021-03-16 - 来自专栏日志服务CLS
CLS 监控告警：实时保障线上服务高可用性
可观测性的意义【服务的可用性】对于任何一个线上服务来说，可用性都是一个重要的质量指标，用户能否用产品完成任务？效率如何？主观感受怎样？ 这实际上是从用户角度所看到的产品质量，是产品竞争力的核心，是产品可靠性、维修性和维修保障性的综合反映。 99%的高可用意味着一年中服务只有3.56天不可用，而99.9%的高可用意味着一年中服务最多8小时不可用，99.99%的高可用则意味着一年中服务最多只有52分钟不可用。 图片对于分布式服务，保证服务质量需要关注的点有很多（如下图），一般的业务只需要做好其中几个点就可以保障服务的质量了。 在未来，CLS会继续打磨日志服务细节，不断精进监控告警能力，帮助用户在日志运维、运营、合规审计等业务方面实现跨越式发展，为线上服务的高可用性保驾护航，造福更多运维团队与开发团队。
1.4K101编辑于 2022-07-27 - 来自专栏腾讯云开发者社区推荐
SLA 4 个 9 ，贝壳高可用架构的质量保障体系
导语 | 贝壳用户需求和用户量的不断增长，对系统的高可用性提出了更高的要求，服务端的质量保证工作该如何开展？ 由于业务的特点，所以我们在高性能，高可用和安全上有特别的要求。 2. 但对测试来说挑战更大了，模块变多了，发布变多了，测试一次任务变复杂了，回归轮次和范围变多，环境更不稳定， 同时我们还要保持高性能，高可用。 质量问题涉及各环节、各角色，系统全面且高可用的提升质量和效率要靠体系化建设。 二、贝壳质量体系 贝壳质量体系的建设，分成理论、策略和信息来进行讲解。 1. （1）KeTest平台 KeTest 平台统一质量和解决方案标准，把各专项能力一站式提供，为全集团赋能，整体对各业务做质量保障，尤其产业互联网在自动化回归，数据，环境，高性能，高可用等部分做深入的能力建设
5.2K332256发布于 2020-10-19 YashanDB高可用架构设计，保障企业业务零中断
因此，如何设计一套具备高可用性的数据库架构，能够实现故障的快速切换和无缝恢复，是企业数据库建设中的关键问题。主备复制架构及故障切换机制YashanDB采用主备复制机制实现数据库的高可用保障。 共享集群架构的多活高可用设计为满足对高性能、高扩展和高可用的更高要求，YashanDB支持基于共享存储的共享集群部署形态。 集群高可用由崖山集群服务（YCS）及崖山文件系统（YFS）共同保障。YCS实现集群资源管理、故障感知和投票仲裁，支持实例的在线故障自动切换及快速故障恢复。 YFS作为高性能并行文件系统，保障共享存储的可靠一致访问。分布式部署的高可用架构策略针对对处理能力有较强线性扩展需求的业务场景，YashanDB提供分布式集群模式。 高可用保障的运维与自动化能力YashanDB通过自动选主、多级切换、在线故障自动恢复等特性降低运维复杂度。YCS和YFS的集群管理和文件管理接口支持对集群组件的全生命周期管理，线上维护无缝不中断。
32210编辑于 2025-08-19- 来自专栏Java项目实战
构建高可用的消息队列系统：保障消息传递的稳定性
然而，为了确保系统的稳定性和高可用性，我们需要特别关注如何构建高可用的消息队列系统。本文将介绍如何保证MQ的高可用性，并提供代码示例，帮助您构建一个可靠的消息队列系统。为什么需要高可用的MQ？ 提高系统可伸缩性：高可用的MQ可以分担大量的消息传递负载，从而支持系统的水平扩展。保证消息按照顺序处理：在一些业务场景中，消息的处理顺序非常重要，高可用MQ可以确保消息按照正确的顺序传递。 减少系统维护成本：高可用的MQ可以减少系统停机时间，降低维护成本。构建高可用的MQ系统要构建高可用的消息队列系统，我们需要考虑以下几个关键方面：1. 示例代码：使用RabbitMQ构建高可用的消息队列下面是一个示例，演示如何使用RabbitMQ构建一个高可用的消息队列系统。首先，确保您已经安装了RabbitMQ，并启动了服务。 请点赞和分享这篇文章，让更多的开发者受益，共同构建高可用的消息队列系统！谢谢阅读！
91320编辑于 2023-09-01 - 来自专栏全栈程序员必看
rabbitmq高可用集群搭建_mongodb高可用架构
RabbitMQ 高可用集群搭建 1 集群简介 1.1 集群架构 当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时，此时可以通过 RabbitMQ 集群来进行扩展，从而达到提升吞吐量的目的 一个高可用，负载均衡的 RabbitMQ 集群架构应类似下图： 这里对上面的集群架构做一下解释说明： 首先一个基本的 RabbitMQ 集群不是高可用的，虽然集群共享队列，但在默认情况下，消息只会被路由到某一个节点的符合条件的队列上 HAProxy 同时支持四层和七层负载均衡，并基于单一进程的事件驱动模型，因此它可以支持非常高的井发连接数。 此时对外服务的 VIP 依然可用，代表已经成功地进行了故障转移。 juejin.im/post/6844904071183220749 RabbitMQ 官方文档 —— 集群指南：www.rabbitmq.com/clustering.… RabbitMQ 官方文档 —— 高可用镜像队列
3.1K10编辑于 2022-09-30 - 来自专栏后台技术底层理解
redis高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 什么时候整个集群不可用(cluster_state:fail)? 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 ==怎么保证redis是高并发以及高可用的==？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
3.4K10发布于 2020-08-04 - 来自专栏SY小站的专栏
ingress高可用
kube-proxy转发到Ingress Controller的pod上,多走一趟路 4、不创建svc,效率最高,也能四层负载的时候不修改pod的template,唯一要注意的是`hostNetwork: true 高可用选择第四种
2.7K30发布于 2020-06-15
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号