- 综合排序
- 最热优先
- 最新优先
- 来自专栏云计算技术笔记
高可用技术概述
算机系统高可用技术的基本概念。 前言 在分析高可用的技术前，我们需要先对一些概念进行说明，先从相关的词语开始。 系统 系统，即若干部分相互联系、相互作用，形成的具有某些功能的整体。 高可用 如果生态系统受到过于大的破坏，会崩溃。计算机系统也是如此，我们做的就是提升抗风险的能力，避免系统崩溃。 高可用技术就是为了对抗这些风险。 本文只讨论应对外部风险的高可用技术，不考虑内部风险。内部风险是另一个话题。 容灾 提高可用性的本质是冗余，具体的实现方案会有不同，但目的都是降低不可用的时长。 从发现灾难到故障转移，多少会有一段时间被计入不可用时长。但随着技术发展，故障时长已经被降低到秒级。 更多分析请看自动灾备技术分析。 容错 容错指的是系统可以容忍局部的错误存在。 如果一个分片瘫痪了，对于这个分片的用户来说，系统不可用。所以分片不属于高可用技术。 总结 高可用的本质是减少系统不能提供服务的时间。 灾备和容错，主要区别是是否需要立刻故障转移。
45620编辑于 2022-09-07 - 来自专栏linux技术分享
mysql 高可用技术
masterha_master_switch 1原来的主从关系要解除 2构建新的主从关系 5应用透明vip 单独去做 master_ip_failover 6故障节点剔除集群 masterha_conf_host 7故障提醒 网络故障，默认manager是单一心跳检测 读写分离 可以把读的压力分担到从库 proxysql 在应用程序和数据库之间加了一层代理可以把流量转发 在互联网企业读写一般是73分读的请求比较大 一般配合高可用一起用 mysql -uroot -p123 -P 6033 -h 127.0.0.1 -e "begin;select @@server_id;commit" mysql ionndb cluster mha高可用技术前端会配合 nginx+php+mysql 2 nginx+php拆分mysql 3访问量上来了 有多套应用连接一套数据库(使用的仍然是一套库) nginx+php=mysql nginx+php=mysql 4做高可用架构 前面加个mycat/shardingjdbc 应用层和数据库之间加入 这种技术检查基于表的垂直拆分 如果单表，较大可以把单表拆分多份，分布到不同的数据库实例(基于表的水平拆分) 维护难度较大，分片较多
1.8K31编辑于 2022-03-28 - 来自专栏王忘杰的小屋
Zabbix7 keepalived VIP高可用部署 对接 OceanBase高可用集群
192.168.4.52 tntzabbix7-02 192.168.4.99 oceanbase高可用VIP数据库 oceanbase高可用数据库集群见其他文章，为zabbix7创建数据库 UJ5;u] 数据库具备VIP高可用能力 三、安装zabbix 1、准备主机 准备两台主机，关闭防火墙 systemctl stop firewalld && systemctl disable firewalld zabbix高可用切换时，备用主机10051端口关闭，可以利用此端口配置keepalived 配置01主机 安装keealived yum install -y keepalived 编写zabbix 高可用检测脚本 vi /etc/keepalived/check_zabbix.sh #! systemctl stop zabbix-server 刷新网页，切换为tntzabbix7-01 测试结论 高可用能力正常，满足需求。
9110编辑于 2026-03-18 - 来自专栏分布式｜微服务｜性能优化｜并发编程｜源码分析
7.Nacos2.0 高可用部署
快速入门章节，我们为了能够快速体验Nacos，所以进行单机部署，并且使用derby做数据库，这节课我们进行高可用部署。
41950编辑于 2023-08-18 - 来自专栏流川疯编写程序的艺术
技术调研----OpenResty高可用技术初步探索
OpenResty 介绍 OpenResty(又称：ngx_openresty) 是一个基于 NGINX 的可伸缩的 Web 平台，由中国人章亦春发起，提供了很多高质量的第三方模块。
81330发布于 2019-03-15 - 来自专栏Java技术栈
高可用高并发的 9 种技术架构！
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。 ? 2、冗余 网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。 具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。 异步架构的典型就是生产者消费者方式，两者不存在直接调用。 7、自动化 具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。 -END- 不错，转发分享一下吧 往期推荐 【1】京东购物车的 Java 架构实现及原理 【2】分布式作业 Elastic-Job 从理论到实战 【3】《阿里技术参考图册》发布，速度收藏 【4】最新后端架构师技术图谱
66050发布于 2018-07-31 - 来自专栏平凡文摘
高可用高并发的 9 种技术架构！
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。 ? 2、冗余 网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。 具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。 异步架构的典型就是生产者消费者方式，两者不存在直接调用。 7、自动化 具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。 -END- 不错，转发分享一下吧 转载声明：本文转载自「Java技术栈」
76750发布于 2018-07-03 - 来自专栏∑小熊猫的博客
Nginx系列(7) —— Nginx配置高可用集群
Nginx 配置 —— 高可用集群 CAP 原则 CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition （对数据更新具备高可用性） 分区容忍性（P）： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 KeepAlived keepalived 是基于 vrrp 协议的一款高可用软件。keepalived 有一台主服务器和和多个备份服务器。 主要为了解决静态路由高可用问题。 使用 keepalived 配置主备模式的高可用 Nginx 集群 为了防止某一台 linux 服务器宕机，我们需要在两台服务器上都进行 Nginx 和 keepalived 的安装。
2.1K10发布于 2020-11-25 - 来自专栏架构随笔录
电商交易高并发和高可用技术（一）
解决这个场景的高并发技术和高可用技术如下： 1.高可用架构技术 隔离技术： 线程隔离，交易请求网关肯定不止交易这一个业务接口，还有一些非核心业务接口，那么整个系统区分核心线程池和非核心线程池，在内存和系统核心数足够大的情况下 进程隔离，系统拆分 集群隔离，单实例无法满足交易业务，需要服务化技术，通过部署多个服务形成服务集群，提升系统容量，交易系统集群和其他非核心业务集群隔离 还可以在核心交易业务加一层网关服务集群部署，专门用于派发交易请求 热点隔离，热点就意味着高并发，在高并发的场景下，要保证高可用性，就必须隔离热点请求，快速的削峰。 目的是用来隔离分布式服务故障，提供线程和信号量隔离，以减少不同服务之间的资源竞争带来的相互影响，提供优雅降级机制，提供熔断机制让服务交易接口快速的失败，而不是一直阻塞，Hystrix可以阻止级联失败并保证系统弹性、和高可用性 2.高并发架构技术 缓存为王，队列也为王，10000个并发请求入分布式缓存队列(redis)或者mq(核心系统mq集群，做到核心业务和非核心业务集群隔离)，商品库存1000预存入redis，库存扣减都走
1.3K30发布于 2020-02-24 - 来自专栏技术杂记
Mycat HA(高可用) 与 LB(负载均衡)7
配置rsyslog日志 日志是可选的，因为日志并不是系统正常运转的必要基础，但是有了日志可以更有效理解系统当前的状态，出现问题后通过日志可以高效定位，所以是间接提升了系统的可用性(通过人力间接提高)，系统的高可用 * uucp,news.crit /var/log/spooler local7.
38030编辑于 2021-12-02 - 来自专栏Se7en的架构笔记
Centos7 部署 Zabbix 5.4 高可用集群
Zabbix 有以下几个主要组件: Zabbix Server：是 Zabbix 软件的核心组件，Zabbix Agent 向其报告可用性、系统完整性信息和统计信息。 数据库使用外部已经部署好的 MySQL 高可用集群。 本文将会介绍在 Centos7 上通过源码编译安装的方式部署一套 Zabbix 高可用集群。 systemctl enable keepalived systemctl start keepalived 高可用验证 浏览器访问 Zabbix Web，可以看到此时访问的是 ACP-ZABBIX-SERVER 5.4 版本源码安装] (https://www.zabbix.com/documentation/current/manual/installation/install) [zabbix ha 官方推荐高可用集群
2.9K20发布于 2021-10-09 - 来自专栏活动盒子
9种高性能高可用高并发的技术架构
所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。 为此，在实践中提出了许多解决方案，以实现独立商城网站建设高性能、高可靠性、易伸缩、可扩展、安全等各种网上电子商城技术架构目标。 但在网站的发展过程中，分层结构对网站支持高并发，向分布式方向的发展至关重要。 2、冗余 网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。 具体实现则在单一服务器内部可用通过多线程共享内存的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。 异步架构的典型就是生产者消费者方式，两者不存在直接调用。
2K30发布于 2019-04-18 - 来自专栏Hadoop数据仓库
HAWQ技术解析（十四） —— 高可用性
一、HAWQ高可用简介 HAWQ作为一个传统数仓在Hadoop上的替代品，其高可用性至关重要。通常硬件容错、HAWQ HA、HDFS HA是保持系统高可用时需要考虑并实施的三个层次。 总的来说，HAWQ容错高可用的实现方式包括： 硬件冗余 master镜像 双集群 1. 2. master镜像 高可用集群中的master节点有两个，一个主一个从。 三、HAWQ文件空间与HDFS高可用 如果在初始化HAWQ时没有启用HDFS的高可用性，可以使用下面的过程启用它。 配置HDFS集群高可用性。 收集目标文件空间的信息。 在Service Actions中选择Enable NameNode HA，如图7所示。 ? 图7 出现Enable HA向导。这个向导描述了配置NameNode高可用必须执行的自动和手工步骤。
1.9K100发布于 2018-01-03 - 来自专栏全栈程序员必看
Centos7安装mysql+keepalived 高可用环境
目录 一、环境准备 二、mysql下载和安装 三、keepalived下载和安装 四、配置mysql双主+keepalived 高可用环境 五、遇到的问题及解决方法 ---- 一、环境准备 1.节点信息 节点IP 节点名称 系统 软件及版本 192.168.51.187 node187 CentOS 7 keepalived-1.3.5 mysql-5.7.24 192.168.51.226 node226 CentOS 7 2.虚拟VIP 虚拟VIP 192.168.51.170 3.初始化, 在两个节点上进行常用工具的安装 yum install gcc gcc-c++ vim-enhanced x86_64 [root@node187 ~]# yum -y remove mariadb-libs-5.5.64-1.el7.x86_64 3.将安装包传输至服务器, 并解压 [root@node187 KEEPALIVED_OPTIONS ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target 四、配置mysql双主+keepalived 高可用环境
85220编辑于 2022-09-06 - 来自专栏开源部署
CentOS 7下安装配置Heartbeat高可用集群
Heartbeat项目是 Linux-HA 工程的一个组成部分，它实现了一个高可用集群系统。 心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 Heartbeat 模块实现了这两个功能。 一、环境说明 #uname -r 3.10.0-862.9.1.el7.x86_64 # cat /etc/RedHat-release CentOS Linux release 7.5.1804 ( Heartbeat高可用集群/ 下载方法见 http://www.linuxidc.com/Linux/2013-07/87684.htm ------------------------------- --0a7add1d9996/ .
1.3K20编辑于 2022-07-26 - 来自专栏架构师之路
高并发、高可用、高可靠微服务架构7大顶级设计思维模型
我们需要对主流微服务开发框架熟悉，需要有构建一个技术能力平台，还需要对业务、系统设计的领域模型、用户行为等要素有足够的理解。 其二、没有分布式的保护机制，盲目实现。 对此有两点想要在此明确： 首先，我们不能脱离开业务目标谈技术，这确实有点儿“耍流氓”； 其次，即使有了明确需求，也需要你前期进行相应的组织，包括团队的技术储备和积累，建立好相应的管控机制，否则很容易一片混乱 画外音：传统的微服务架构改造一定是围绕业务和场景驱动的，而不是简单的技术驱动。 微服务被诟病最多的地方主要是单体拆分为微服务粒度太细，导致了大量微服务集成，接口滥用，给后续的管控和治理造成极大困难。 《百万年薪架构师必备能力—亿级企业高可用高并发高可靠微服务架构设计与实践》。
1.2K30发布于 2021-04-22 - 来自专栏全栈程序员必看
rabbitmq高可用集群搭建_mongodb高可用架构
RabbitMQ 高可用集群搭建 1 集群简介 1.1 集群架构 当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时，此时可以通过 RabbitMQ 集群来进行扩展，从而达到提升吞吐量的目的 一个高可用，负载均衡的 RabbitMQ 集群架构应类似下图： 这里对上面的集群架构做一下解释说明： 首先一个基本的 RabbitMQ 集群不是高可用的，虽然集群共享队列，但在默认情况下，消息只会被路由到某一个节点的符合条件的队列上 HAProxy 同时支持四层和七层负载均衡，并基于单一进程的事件驱动模型，因此它可以支持非常高的井发连接数。 此时对外服务的 VIP 依然可用，代表已经成功地进行了故障转移。 juejin.im/post/6844904071183220749 RabbitMQ 官方文档 —— 集群指南：www.rabbitmq.com/clustering.… RabbitMQ 官方文档 —— 高可用镜像队列
3K10编辑于 2022-09-30 - 来自专栏后台技术底层理解
redis高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 ==怎么保证redis是高并发以及高可用的==？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。 （2）非阻塞I/O，Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。
3.2K10发布于 2020-08-04 - 来自专栏SY小站的专栏
ingress高可用
kube-proxy转发到Ingress Controller的pod上,多走一趟路 4、不创建svc,效率最高,也能四层负载的时候不修改pod的template,唯一要注意的是`hostNetwork: true 高可用选择第四种
2.5K30发布于 2020-06-15 - 来自专栏Java周某人
Redis高可用技术解决方案总结分析
Redis高可用技术解决方案总结分析 本文主要针对Redis常见的几种使用方式及其优缺点展开分析。 优点： 架构简单，部署方便； 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务 缺点： 不保证数据的可靠性； 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务； 高性能受限于单核CPU的处理能力（Redis 优点： 无中心架构； 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布； 可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除； 高可用性：部分节点不可用时，集群仍可用。 优点： 高可靠性、高可用性； 自主可控性高； 贴切业务实际需求，可缩性好，兼容性好。
78000发布于 2019-08-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号