- 综合排序
- 最热优先
- 最新优先
- 来自专栏云计算技术笔记
高可用技术概述
算机系统高可用技术的基本概念。 前言 在分析高可用的技术前，我们需要先对一些概念进行说明，先从相关的词语开始。 系统 系统，即若干部分相互联系、相互作用，形成的具有某些功能的整体。 高可用 如果生态系统受到过于大的破坏，会崩溃。计算机系统也是如此，我们做的就是提升抗风险的能力，避免系统崩溃。 高可用技术就是为了对抗这些风险。 本文只讨论应对外部风险的高可用技术，不考虑内部风险。内部风险是另一个话题。 容灾 提高可用性的本质是冗余，具体的实现方案会有不同，但目的都是降低不可用的时长。 从发现灾难到故障转移，多少会有一段时间被计入不可用时长。但随着技术发展，故障时长已经被降低到秒级。 更多分析请看自动灾备技术分析。 容错 容错指的是系统可以容忍局部的错误存在。 如果一个分片瘫痪了，对于这个分片的用户来说，系统不可用。所以分片不属于高可用技术。 总结 高可用的本质是减少系统不能提供服务的时间。 灾备和容错，主要区别是是否需要立刻故障转移。
43620编辑于 2022-09-07 - 来自专栏linux技术分享
mysql 高可用技术
网络故障，默认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做高可用架构 mha读写分离 主库提供写入，从库提供读取 5演变单业务单数据库服务(垂直拆分) 应用端拆分不同服务，有不同数据库服务 逻辑拆分 6单业务变得非常高，基于每个业务拆分数据库的热表，每个热表拆分到多个库中 前面加个mycat/shardingjdbc 应用层和数据库之间加入 这种技术检查基于表的垂直拆分 如果单表，较大可以把单表拆分多份，分布到不同的数据库实例(基于表的水平拆分) 维护难度较大，分片较多
1.8K31编辑于 2022-03-28 - 来自专栏流川疯编写程序的艺术
技术调研----OpenResty高可用技术初步探索
OpenResty 介绍 OpenResty(又称：ngx_openresty) 是一个基于 NGINX 的可伸缩的 Web 平台，由中国人章亦春发起，提供了很多高质量的第三方模块。
80830发布于 2019-03-15 - 来自专栏平凡文摘
高可用高并发的 9 种技术架构！
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。 ? 2、冗余 网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。 网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。 具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。 异步架构的典型就是生产者消费者方式，两者不存在直接调用。 -END- 不错，转发分享一下吧 转载声明：本文转载自「Java技术栈」
76550发布于 2018-07-03 - 来自专栏Java技术栈
高可用高并发的 9 种技术架构！
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。 ? 2、冗余 网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。 网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。 具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。 异步架构的典型就是生产者消费者方式，两者不存在直接调用。 -END- 不错，转发分享一下吧 往期推荐 【1】京东购物车的 Java 架构实现及原理 【2】分布式作业 Elastic-Job 从理论到实战 【3】《阿里技术参考图册》发布，速度收藏 【4】最新后端架构师技术图谱
65050发布于 2018-07-31 - 来自专栏架构随笔录
电商交易高并发和高可用技术（一）
解决这个场景的高并发技术和高可用技术如下： 1.高可用架构技术 隔离技术： 线程隔离，交易请求网关肯定不止交易这一个业务接口，还有一些非核心业务接口，那么整个系统区分核心线程池和非核心线程池，在内存和系统核心数足够大的情况下 进程隔离，系统拆分 集群隔离，单实例无法满足交易业务，需要服务化技术，通过部署多个服务形成服务集群，提升系统容量，交易系统集群和其他非核心业务集群隔离 还可以在核心交易业务加一层网关服务集群部署，专门用于派发交易请求 热点隔离，热点就意味着高并发，在高并发的场景下，要保证高可用性，就必须隔离热点请求，快速的削峰。 目的是用来隔离分布式服务故障，提供线程和信号量隔离，以减少不同服务之间的资源竞争带来的相互影响，提供优雅降级机制，提供熔断机制让服务交易接口快速的失败，而不是一直阻塞，Hystrix可以阻止级联失败并保证系统弹性、和高可用性 2.高并发架构技术 缓存为王，队列也为王，10000个并发请求入分布式缓存队列(redis)或者mq(核心系统mq集群，做到核心业务和非核心业务集群隔离)，商品库存1000预存入redis，库存扣减都走
1.3K30发布于 2020-02-24 - 来自专栏活动盒子
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集群高可用性。 收集目标文件空间的信息。 这个向导描述了配置NameNode高可用必须执行的自动和手工步骤。
1.9K100发布于 2018-01-03 - 来自专栏全栈程序员必看
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.1K10发布于 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多个节点，节点可动态添加或删除； 高可用性：部分节点不可用时，集群仍可用。 优点： 高可靠性、高可用性； 自主可控性高； 贴切业务实际需求，可缩性好，兼容性好。
77500发布于 2019-08-05 - 来自专栏Java周某人
Redis高可用技术解决方案总结分析
Redis高可用技术解决方案总结分析 本文主要针对Redis常见的几种使用方式及其优缺点展开分析。 优点： 架构简单，部署方便； 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务 缺点： 不保证数据的可靠性； 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务； 高性能受限于单核CPU的处理能力（Redis 优点： 无中心架构； 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布； 可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除； 高可用性：部分节点不可用时，集群仍可用。 优点： 高可靠性、高可用性； 自主可控性高； 贴切业务实际需求，可缩性好，兼容性好。
99400发布于 2019-08-05 - 来自专栏问天丶天问
SkyWalking 高可用
生产环境中，后端应用需要支持高吞吐量并且支持高可用来保证服务的稳定，因此需要高可用集群管理。 高可用需要： 至少一个 Nacos（可以是nacos集群） 至少一个 ElasticSearch / mysql（可以是es/msql集群） 至少2个skywalking oap服务； 至少1个UI（UI
44110编辑于 2024-10-03 - 来自专栏写代码和思考
高可用 - 简述
背景 本文记录一些高可用的内容，和数据库在高可用方面的演进过程。 1. 概念 可用性: 即软件系统在一段时间内提供 有用资源 的能力。 如何设计来做到高可用 保证系统高可用，架构设计的核心准则是：冗余 和 故障转移。 单点系统的问题是，挂了就完全不可用了，服务会受影响。如果有冗余备份，其他后备的系统能够顶上，保证服务继续可用。 所以，又往往是通过“自动故障转移”来使得快速切换到备份系统来实现高可用。 常见的互联网分布式架构是： 前端 ---> 反向代理 --> WEB应用 --> 服务 --> 数据库（及缓存） 其中，高可用可涉及到上面每个节点的高可用保障，我们看下数据的高可用架构的演变过程。 然后在集群前添加某种路由技术，将客户端定向到正确的节点上。 ? 分片 通过分片可以在多台计算机之间分配工作负载，提高吞吐量，并通过容忍更多的部分故障来获得更大的弹性。
2.1K10发布于 2020-05-08 - 来自专栏编程一生
实践高可用
本篇文章是之前一篇《大话高可用》的高可用心法的案例篇。 说实践之前先说概念。 具体实践如下： 架构高可用 交易这边进行在进行重构。将原有的核心交易从职责上划分为交易收单、交易保障和数据中心三个大块。 从高可用上，交易收单要保证实时交易现场的可用。 所以它才是对高可用需要考虑最多的，对MTBF和MTTR都要考虑和权衡。但是在对高可用要求上交易收单和交易保障是基本职责，指标就是稳定、稳定和稳定。 数据中心关乎的用户体验，是可以持续优化的，但是对高可用是有一定容忍度的：比如页面会加载慢，或者第一次加载不了刷新就成功了。 强依赖高可用 比如数据库的密码，不仅是加密的，而且是在中央集群秘钥管理中心统一管理的。中央集群的就会有秘钥获取不到的风险。按照API，如果获取不到则会抛出指定异常。 这是强依赖，需要容灾。
1.1K30发布于 2018-07-02 - 来自专栏编程一生
大话高可用
今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。 高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。 然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。 有依赖的时候要尽量弱化依赖，除了理清业务逻辑之外，技术手段上可以采用异步化和旁路来解决。 再考虑怎么自己不作死。自己不作死，就是要考虑两个关键字：一个作，一个死。 作就是：改出问题？ 不当小白鼠，只用成熟的技术。职责单一化。 ? 死就是：要考虑单个接口挂了咋办？单个接口挂了现场返回错误，同时不扩大影响，用其他服务补数据。单个节点挂了咋办？用集群。一个机房挂了咋办？多机房。
99220发布于 2018-07-02 - 来自专栏院长运维开发
ingress高可用
app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx --- Ingress Contronler 高可用 也就是使用了主机的dns,会导致svc的请求直接走宿主机的上到公网的dns服务器而非集群里的dns server,需要设置pod的dnsPolicy: ClusterFirstWithHostNet即可解决 高可用选择第四种
2.5K20发布于 2020-06-13 - 来自专栏用户1337634的专栏
高可用 --- Redis
因为Redis拥有诸多优秀的特性，使用范围越来越广，系统对其可用性的依赖也越来越重，当前绝大部分系统使用的Redis都实现了高可用。 这里主要介绍Redis官方推荐的两种高可用方案Sentinel和Redis Cluster。 （如有不明白可以参考《Redis设计与实现》） 高可用 Redis实现高可用主要有两种方式，一种是Sentinel（3.0之前），一种是3.0正式支持的Redis Cluster（推荐）。 注意事项 因为Sentinel与Redis Cluster都没有实现强一致性（也没有实现最终一致性），所以在使用时，要牢记这一点，不能用在一致性要求特别高的场景，比如全局唯一ID，交易数据等。 如果master没有设置持久化，存在风险，如果不小心重启，则会丢失所有数据，而且从机也会因为同步，丢失所有数据（所以一定要高可用）。
1.1K40发布于 2019-03-27 - 来自专栏PHPer 进击
MySQL - 高可用性：少宕机即高可用？
我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。 老规矩，讨论一个名词，首先要给它下个定义，那么什么是可用性？ 1 什么是可用性 我们常见的可用性通常以百分比表示，这本身就有其隐藏的意味：高可用性不是绝对的。换句话说，100% 的可用性是不可能达到的。没错，这里可以这么肯定的说。 3 如何实现高可用性 通过上面的分析，也许你已经发现了，我们可用性取决于两个时间： 应用的平均失效时间 应用的平均恢复时间 因此，提高可用性也可以从这两个方面入手。 我们可能引入新的的技术来解决单点失效问题，但引入的新技术可能导致更多的宕机时间。因此，我们应该按影响级别对失效单点进行排序，按照排序针对性解决单点失效问题。 这里的解决方案本质上负载均衡里的虚拟 IP 技术是一样的，不同的是现在是用于故障转移。 这种方法的好处是对应用透明。它会中断已有的连接，但不用修改配置。
1.9K20发布于 2019-05-13
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号