搭建高可用系统架构与性能优化

简介: 搭建高可用系统架构与性能优化

以下内容参考微信公众号架构师之路,欢迎大家关注,结合文章内容写一些自己的补充和心得感悟

1 单点架构分析

当我们看到一个庞大的系统架构,看似高可用,但是避免不了部分单点问题,因为有成本在,有时候不是非常需要某一部分高可用,设计上就比较简单。

在哪些场景中会存在单点?先来看一下一个典型互联网高可用架构。

典型互联网高可用架构:

(1)客户端层,这一层是浏览器或者APP,第一步先访问DNS-server,由域名拿到nginx的外网IP


(2)负载均衡层,nginx是整个服务端的入口,负责反向代理与负载均衡工作


(3)站点层,web-server层,典型的是tomcat或者apache


(4)服务层,service层,典型的是dubbo或者thrift等提供RPC调用的后端服务,或者微服务架构体系


(5)数据层,包含cache和db,典型的是主从复制读写分离的db架构


在这个互联网架构中,站点层、服务层、数据库的从库都可以通过冗余的方式来保证高可用


但是存在的问题:


(1)nginx层是一个潜在的单点

(2)数据库写库master也是一个潜在的单点

2 单点架构存在的问题

单点系统一般来说存在两个很大的问题:


(1)非高可用:既然是单点,master一旦发生故障,服务就会受到影响

(2)性能瓶颈:既然是单点,不具备良好的扩展性,服务性能总有一个上限,这个单点的性能上限往往就是整个系统的性能上限


接下来,就看看有什么优化手段可以优化上面提到的两个问题


3 shadow-master解决单点高可用问题

shadow-master是一种很常见的解决单点高可用问题的技术方案。


“影子master”,顾名思义,服务正常时,它只是单点master的一个影子,在master出现故障时,shadow-master会自动变成master,继续提供服务。


shadow-master它能够解决高可用的问题,并且故障的转移是自动的,不需要人工介入,但不足是它使服务资源的利用率降为了50%,业内经常使用keepalived+vip的方式实现这类单点的高可用。

96f584694b604239b34b6c90c829ddd9.png

对于mysql读写分离主master解决方法


(1)两个主库设置相互同步的双主模式


(2)平时只有一个主库提供服务,言下之意,shadow-master不会往master同步数据


(3)异常时,虚IP漂移到另一个主库,shadow-master变成主库继续提供服务


需要说明的是,由于数据库的特殊性,数据同步需要时延,如果数据还没有同步完成,流量就切到了shadow-master,可能引起小部分数据的不一致。


4 减少与单点的交互

减少与单点的交互是单点的系统优化的核心方向


既然知道单点存在性能上限,单点的性能有可能成为系统的瓶颈,那么,减少与单点的交互,便成了存在单点的系统优化的核心方向。


怎么来减少与单点的交互,这里提两种常见的方法。


4.1 批量写

分布式系统之所以难,很重要的原因之一是“没有一个全局时钟,难以保证绝对的时序”,要想保证绝对的时序,还是只能使用单点服务,用本地时钟保证“绝对时序”。数据库写压力大,是因为每次生成ID都访问了数据库,可以使用批量的方式降低数据库写压力。


数据库中只存储当前ID的最大值,例如0。ID生成服务假设每次批量拉取6个ID,服务访问数据库,将当前ID的最大值修改为5,这样应用访问ID生成服务索要ID,ID生成服务不需要每次访问数据库,就能依次派发0,1,2,3,4,5这些ID了,当ID发完后,再将ID的最大值修改为11,就能再次派发6,7,8,9,10,11这些ID了,于是数据库的压力就降低到原来的1/6了。


4.2 合理利用缓存

缓存也是一种降低与单点交互次数,提升系统整体性能的方法。


0db0bf7d83c1405bbdc36cc0253e9fa2.png

1、用户请求经过Nginx

2、Nginx检查是否有缓存,如果Nginx有缓存,直接响应用户数据

3、Nginx如果没有缓存,则将请求路由给后端Java服务

4、Java服务查询Redis缓存,如果有数据,则将数据直接响应给Nginx,并将数据存入缓存,Nginx将数据响应给用户

5、如果Redis没有缓存,则使用Java程序查询MySQL,并将数据存入到Reids,再将数据存入到Nginx中


5 水平扩展是提升单点系统性能的好方案

无论怎么批量写,客户端缓存,单点毕竟是单机,还是有性能上限的。


想方设法水平扩展,消除系统单点,理论上才能够无限的提升系统系统。


并不是所有的业务场景都可以水平拆分,例如秒杀业务,商品的条数可能不多,数据库的数据量不大,就不能通过水平拆分来提升秒杀系统的整体写性能(总不能一个库100条记录吧?)。


6 总结

(1)单点系统存在的问题:可用性问题,性能瓶颈问题

(2)shadow-master是一种常见的解决单点系统可用性问题的方案

(3)减少与单点的交互,是存在单点的系统优化的核心方向,常见方法有批量写,客户端缓存


(4)水平扩展也是提升单点系统性能的好方案


目录
相关文章
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
运维 监控 搜索推荐
MSE ZooKeeper:Flink 高可用架构的企业级选择
本文深入解析了 Apache Flink 架构中 ZooKeeper 的核心作用,包括 Leader 选举、Checkpoint 管理、作业协调及配置管理等关键功能,并结合金融风控与电商推荐等典型场景,分析了 ZooKeeper 在实际应用中的技术实现。
|
11月前
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
12月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
缓存 Cloud Native Java
性能优化与架构能力复盘报告
本复盘总结了在性能优化、架构设计及云原生方面的实践经验,涵盖性能分析、全链路压测、缓存策略、微服务治理等内容,展示了从系统性能提升到成本控制的综合能力,并规划了未来在JVM优化、ServiceMesh及APM平台建设等方面的能力提升路径。
341 3
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
4388 57
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
1598 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
3771 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
576 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
监控 NoSQL 算法
百万级URL重定向工程:大规模网站架构设计与性能优化实战
本文深入探讨了大规模重定向系统的核心挑战与解决方案,涵盖技术瓶颈分析、分布式架构设计、十亿级URL处理策略、全球化部署方案及全链路监控体系。通过数学建模与性能优化,提出三层架构模型,并结合一致性哈希分片算法实现高效路由。同时,对比不同架构的吞吐量与容灾能力,分享某电商平台实践案例,展示性能显著提升。最后展望重定向即服务(RaaS)未来趋势,包括AI动态路由、量子安全跳转和边缘智能等关键技术,为企业提供扩展性强、稳定性高的系统设计参考。
589 25