- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构精进之路
面向业务的高可用架构设计
通常情况下我们在谈论高可用架构设计的时候，主要关注的是系统结构的高可用，例如主备架构、集群架构、多中心架构。 因此，真正做到高可用，不能单纯从系统结构的角度出发来考虑问题，不能局限于某个系统的高可用，而应该从业务的角度出发，全方位的来考虑高可用的架构设计。 前者我称之为“面向系统的高可用架构”，后者我称之为“面向业务的高可用架构”。 为了实现业务的高可用，我们跳出传统的面向系统的高可用的思路，转而从业务的角度来整体考虑高可用，最终实现了一套“立体化的高可用架构”。接下来我将逐一展示这套立体化高可用架构的一些具体实践。 一、面向业务的高可用目标 业界高可用的通用指标是几个9，例如5个9代表一年业务不可用的时间是5分钟，4个9代表一年业务的不可用时间是50分钟。
1.2K30发布于 2021-03-15 - 来自专栏云计算专栏
如何设计高可用的云业务架构？
如何设计可靠云业务架构？个人认为应该从业务容错、高可用和灾备三个方面入手。 什么是容错？ 容错（fault tolerance）指的是， 单个组件发生故障时，业务还能继续运行。 高可用（high availability）通常来描述一个架构经过专门的设计，从而减少业务中断时间，最终实现保障其服务的高度可用性。 0.png 汽车的备胎就是一个高可用的例子。 注意，高可用不是指业务不中断（那是容错能力），指的是能以最短时间恢复正常访问业务的能力，无论这个故障是业务流程、物理设施、网络或者服务器软/硬件的故障。如果需要很长时间才能恢复可用性，就不叫高可用了。 设计一个高可靠的云业务架构，至少需要考虑以下三点： 容错：单个组件误操作或异常时，保证业务继续稳定运行。 高可用：业务访问出现故障中断时，保证快速恢复。 灾备：基础设施毁灭时，保证尽快恢复业务。 本文主要概括性介绍了设计高可靠云业务架构的主要考量，具体容错、高可用、灾备如何运用还要看每个公司业务的具体情况来定。
3K72发布于 2019-12-13 - 来自专栏架构随笔录
全链路监控系统整合业务系统如何高可用
参照zinpkin全链路监控系统的弊端:监控系统收集器，通过集成SpringBoot插件，耦合侵入业务，和应用部署在同一个jvm中，影响洪峰下的业务系统的高可用性。 高可用设计方案: 保障高可用必须牺牲一致性 目前全链路架构方案的改进： 方案：将影响业务性能的模块和应用解耦，以java agent和应用部署在同一台服务器上，保证进程隔离。 搜集器单独部署，业务侵入以java agent方式侵入。 2）在需要与集群解耦的业务场景下，使用TransportClient，为了提升效率，可以考虑将kafka和es通信的通道抽离成一个基础服务组件，单独分布式部署（高可用架构部署)，一个节点一个客户端，负载均衡 ，比如有3个节点，这样就可以并行的消化生产者消息，到es集群，从而解决高流量日志消息对业务系统的影响。
1K30发布于 2020-02-24 - 来自专栏架构之美
构建企业级业务高可用的延时消息中
1.业务场景剖析 公司业务系统（比如：电商系统）中有大量涉及定时任务的业务场景，例如：实现买卖双方在线沟通的IM系统，为了确保接收方能够收到消息，服务端一般都会有重试策略，即服务端在消息发出的一段时间内 2.时间轮算法剖析 时间轮算法可以高效的处理定时任务，并且有非常高的精度。我们以IM的消息重发功能为例介绍下时间轮算法的应用。 5.延时服务中台化 到现在为止，上面介绍的模型已经可以满足业务的定时任务需求，但它还只是一个功能逻辑，我们不能让每个有需求的业务方都去实现一个时间轮，重复造轮子。 图5 延时服务中台化 业务模块与延时服务的交互可以使用RPC Over TCP，但是对于延时服务来说，需要调用业务模块的RPC接口来触发延时任务，延时服务与业务模块耦合，不利于系统的稳定性，同时业务也需要实现回调接口 ---- 近期热文 大中台模式下如何构建复杂业务核心状态机组件 基于CAP模型设计企业级真正高可用的分布式锁 如何设计真正高性能高并发分布式系统（万字长文） 微服务架构中分布式事务实现方案如何取舍
1.3K21发布于 2019-11-25 - 来自专栏全栈程序员必看
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 - 来自专栏SY小站的专栏
ingress高可用
kube-proxy转发到Ingress Controller的pod上,多走一趟路 4、不创建svc,效率最高,也能四层负载的时候不修改pod的template,唯一要注意的是`hostNetwork: true 高可用选择第四种
2.6K30发布于 2020-06-15 - 来自专栏后台技术底层理解
redis高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 ==怎么保证redis是高并发以及高可用的==？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
3.3K10发布于 2020-08-04 - 来自专栏写代码和思考
高可用 - 简述
背景 本文记录一些高可用的内容，和数据库在高可用方面的演进过程。 1. 概念 可用性: 即软件系统在一段时间内提供 有用资源 的能力。 如何设计来做到高可用 保证系统高可用，架构设计的核心准则是：冗余 和 故障转移。 单点系统的问题是，挂了就完全不可用了，服务会受影响。如果有冗余备份，其他后备的系统能够顶上，保证服务继续可用。 所以，又往往是通过“自动故障转移”来使得快速切换到备份系统来实现高可用。 常见的互联网分布式架构是： 前端 ---> 反向代理 --> WEB应用 --> 服务 --> 数据库（及缓存） 其中，高可用可涉及到上面每个节点的高可用保障，我们看下数据的高可用架构的演变过程。 因为依靠单台机器处理流量，所以仍然受限于单台机器的最大可用资源。 3.2 分片 从单机到分布式：扩展到多台机器 随着互联网的快速发展，业务需求在规模和复杂性方面也有所增长。
2.2K10发布于 2020-05-08 - 来自专栏问天丶天问
SkyWalking 高可用
生产环境中，后端应用需要支持高吞吐量并且支持高可用来保证服务的稳定，因此需要高可用集群管理。 高可用需要： 至少一个 Nacos（可以是nacos集群） 至少一个 ElasticSearch / mysql（可以是es/msql集群） 至少2个skywalking oap服务； 至少1个UI（UI
56310编辑于 2024-10-03 - 来自专栏编程一生
实践高可用
本篇文章是之前一篇《大话高可用》的高可用心法的案例篇。 说实践之前先说概念。 具体实践如下： 架构高可用 交易这边进行在进行重构。将原有的核心交易从职责上划分为交易收单、交易保障和数据中心三个大块。 从高可用上，交易收单要保证实时交易现场的可用。 所以它才是对高可用需要考虑最多的，对MTBF和MTTR都要考虑和权衡。但是在对高可用要求上交易收单和交易保障是基本职责，指标就是稳定、稳定和稳定。 数据中心关乎的用户体验，是可以持续优化的，但是对高可用是有一定容忍度的：比如页面会加载慢，或者第一次加载不了刷新就成功了。 强依赖高可用 比如数据库的密码，不仅是加密的，而且是在中央集群秘钥管理中心统一管理的。中央集群的就会有秘钥获取不到的风险。按照API，如果获取不到则会抛出指定异常。 这是强依赖，需要容灾。
1.2K30发布于 2018-07-02 - 来自专栏编程一生
大话高可用
今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。 高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。 然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。 有依赖的时候要尽量弱化依赖，除了理清业务逻辑之外，技术手段上可以采用异步化和旁路来解决。 再考虑怎么自己不作死。自己不作死，就是要考虑两个关键字：一个作，一个死。 作就是：改出问题？ 别人死我们不死和不被队友搞死的区别在于，队友和我们需要有明确的业务边界，搞清楚哪些是我们负责的，然后就是保证别人死我们不死。 ?
1.1K20发布于 2018-07-02 - 来自专栏用户1337634的专栏
高可用 --- Redis
因为Redis拥有诸多优秀的特性，使用范围越来越广，系统对其可用性的依赖也越来越重，当前绝大部分系统使用的Redis都实现了高可用。 这里主要介绍Redis官方推荐的两种高可用方案Sentinel和Redis Cluster。 （如有不明白可以参考《Redis设计与实现》） 高可用 Redis实现高可用主要有两种方式，一种是Sentinel（3.0之前），一种是3.0正式支持的Redis Cluster（推荐）。 注意事项 因为Sentinel与Redis Cluster都没有实现强一致性（也没有实现最终一致性），所以在使用时，要牢记这一点，不能用在一致性要求特别高的场景，比如全局唯一ID，交易数据等。 如果master没有设置持久化，存在风险，如果不小心重启，则会丢失所有数据，而且从机也会因为同步，丢失所有数据（所以一定要高可用）。
1.2K40发布于 2019-03-27 - 来自专栏院长运维开发
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.6K20发布于 2020-06-13 - 来自专栏PHPer 进击
MySQL - 高可用性：少宕机即高可用？
我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。 老规矩，讨论一个名词，首先要给它下个定义，那么什么是可用性？ 1 什么是可用性 我们常见的可用性通常以百分比表示，这本身就有其隐藏的意味：高可用性不是绝对的。换句话说，100% 的可用性是不可能达到的。没错，这里可以这么肯定的说。 因此，对于可用性，我们可以遵循这样一个原则： 能够承担多少宕机成本，就保证相应的可用时间。 这也说明了一个普遍的情况： 许多高可用策略可能会产生反作用 了解了可用性的定义及其降低可用性的因素，我们就要来考虑如何提高系统的可用性了。 3 如何实现高可用性 通过上面的分析，也许你已经发现了，我们可用性取决于两个时间： 应用的平均失效时间 应用的平均恢复时间 因此，提高可用性也可以从这两个方面入手。
2K20发布于 2019-05-13 - 来自专栏深入理解Android
高并发与高可用实战
高可用 高可用：相对于高并发来说，高可用并不是一个比较有规律的参数，7*24 是每个网站的梦想，但是你并不知道，在某一刻，他就没理由的宕机了。 高并发设计原则 系统设计不仅需要考虑实现业务功能，还要保证系统高并发、高可用、高可靠等。 高可用设计原则 通过负载均衡和反向代理实现分流。 通过限流保护服务免受雪崩之灾。 通过降级实现部分可用、有损服务。 通过隔离实现故障隔离。 降级 对于高可用服务，很重要的一个设计就是降级开关，在设计降级开关时，主要依据如下思路： 1.开关集中化管理：通过推送机制把开关推送到各个应用。 这样就可以把一些同步调用改成异步调用，优先处理高优先级数据或特殊特征的数据，合理分配进入系统的流量，以保障系统可用。
2K20编辑于 2022-06-22 - 来自专栏后台技术底层理解
redis 的高并发高可用
redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了，就可以实现，任何一个实例宕机，可以进行主备切换。 所以就有了几个问题？ 什么是主从架构，主从如何备份？ 但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 怎么保证redis是高并发以及高可用的？ sdown 和 odown 转换机制 sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机。
1.9K00发布于 2020-08-04 业务系统非功能性架构和高可用性设计
今天逐步谈下业务系统非功能性架构设计和高可用性方面的内容，在前面一篇谈软件架构设计的文章中，对于非功能性架构设计方面的内容我们没有太展开描述，今天将重点谈非功能性架构设计和高可用性设计。 当前我们谈的业务系统高可用性，一般的要求都是要达到4个9，即99.99%的高可用性，这个高可用性下，需要业务系统完全具备故障自动恢复能力。其年度停机时间53分钟。 在文章首页图也可以看到首先是要基于业务目标驱动建立高可用性战略目标，不同的业务目标对于软件平台的高可用性要求显然是不一样的，其次是建立端到端的高可用性管理体系，这个管理体系包括了标准规范，业务流程和约束 在运行期引入SLA就是一种分级的管理策略和报警预警兼顾的高可用性管理方式。 业务系统性能测算模型 Oracle性能测算模型 在讲高可用具体架构的时候，首先还是得谈下业务系统性能测试模型。 高可用性的目标和关键要素 对于业务系统的高可用性，实际上包括了高可靠，高性能和高扩展三个方面的内容。而且三方面相互之间还存在相互的依赖和影响关系。 对于三者的关系，我们可以用下图进行描述。
34510编辑于 2025-06-24YashanDB高可用架构设计，保障企业业务零中断
在现代企业业务系统中，数据库的高可用性直接决定了业务的连续性和稳定性。业务中断不仅导致数据损失，还影响用户体验及企业信誉。 分布式部署的高可用架构策略针对对处理能力有较强线性扩展需求的业务场景，YashanDB提供分布式集群模式。 总结与建议选择合适的部署架构（单机主备、分布式集群或共享集群）以满足不同业务性能和高可用需求。主备机制配置同步或异步复制模式，结合业务容忍的延迟要求与数据丢失风险合理设置保护模式。 持续关注YashanDB高可用能力的技术演进，结合最新架构特性优化系统部署和运维。结论随着企业业务对数据可靠性和系统连续性的严苛要求不断提升，数据库高可用架构设计成为数据库技术竞争的核心。 未来，伴随数据规模的不断增长和技术的发展，数据库高可用技术将持续成为企业关键业务支撑的竞逐焦点。
31610编辑于 2025-08-19- 来自专栏A周立SpringCloud
从MySQL高可用架构看高可用架构设计
百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上 MySQL高可用 说到MySQL的高可用，不得不提到复制，复制是MySQL高可用的基础。复制解决了什么问题呢？ 1.2 高可用复制架构 ? 1.3.mysql 高可用架构 1.3.1 MySQL Cluster架构 限制存储引擎为NDB存储引擎： ? 为了高可用的保证，有了多主或者主从切换。 数据库的高可用架构一般在系统的底层，这方面的技术要求比较高，整个高可用系统大致如下： ? 3.总结 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。
1.2K20发布于 2019-08-23 - 来自专栏后台技术底层理解
消息队列高可用
常见的消息队列有ActiveMQ,RabbitMQ,RocketMQ,kafka,前两个属于集群模式部署来提供高可用，后两个可以部署分布式模式提供HA。 集群模式MQ ? 2.可用性难以保障，如果queue所在的主机挂掉，那么queue数据就会丢失。 镜像集群MQ ? kafka的高可用，对写入的机器进行备份，在一个相同副本的主机中分为leader和follower,保证集群的高可用。 如何保证消费系统的幂等性？
54820发布于 2020-08-04
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号