分布式系统稳固性建立-性能优化篇

打印 上一主题 下一主题

主题 815|帖子 815|积分 2445

分布式系统稳固性建立-性能优化篇

系统稳固性建立是系统工程的核心内容之一。以下是一些重要的方面:

  • 架构设计:

    • 采用模块化、松耦合的架构设计,以提高系统的可扩展性和可维护性。
    • 合理划分系统功能模块,降低单个模块的复杂度。
    • 界说清晰的接口和数据交换标准,确保各模块之间协调工作。

  • 容错机制:

    • 建立完善的异常处理和容错机制,及时检测并隔离故障,防止故障流传。
    • 实现关键功能的冗余备份,提高系统的可用性。
    • 设计自动恢复和自修复机制,缩短系统故障的恢复时间。

  • 性能优化:

    • 进行系统性能测试和瓶颈分析,确定系统的承载能力。
    • 优化关键模块的性能,提高系统的团体响应速度。
    • 采用缓存、异步处理等手段,缓解系统的瞬时压力。

性能优化



  • 在当今高并发、大流量的互联网环境中,分布式系统的性能和稳固性至关重要。本文将深入探究分布式系统性能优化的关键计谋和实践。
  • 性能优化可以从:代码优化、缓存、消息队列、并发、容量评估、压测、监控预警等来提高系统性能
代码优化

代码优化是提拔系统性能的重要手段。
时间复杂度优化



  • 选择合适的算法和数据布局、制止嵌套循环、使用空间换时间计谋
缓存优化



  • 想要提高服务的性能,根本会想到可以使用缓存来提高性能、应用服务的缓存一般就是存储一些使用频繁、但是存储空间占用不大,且根本不怎么变更的数据,大概作为多级缓存中的一级。
  • 缓存是提拔系统性能的关键技术之一,通过减少数据访问耽误和降低后端存储压力,明显加快数据检索速度。在现代应用架构中,缓存不但用于提拔用户体验,也是实现高并发处理的底子。
  • 在分布式的场景在,应用服务缓存需要留意多节点缓存更新题目、同等性题目、LRU 缓存淘汰计谋。
常见的缓存实现方式



  • 内存缓存:利用服务器的RAM来存储热门数据,提供快速的数据访问能力。常见的内存缓存实现包括Ehcache、Memcached等。
  • 分布式缓存:通过多台服务器共享缓存数据,解决了单机内存限制的题目,并提供了更好的扩展性和可用性。比方,Redis和Hazelcast是流行的分布式缓存解决方案。
  • 欣赏器缓存:利用客户端的存储能力,减少网络传输的数据量,加快页面加载速度。通过设置合适的HTTP头信息,如Cache-Control和Expires,可以控制欣赏器缓存的生命周期。
  • 内容分发网络(CDN):通过在网络边缘节点存储静态资源,使用户可以就近获取数据,从而减少耽误和带宽消耗。
缓存可能带来的题目

在使用缓存的过程中,需要考虑到一些相对极致的场景题目,比如:缓存的穿透、击穿、雪崩、等题目。


  • 缓存穿透: 是指查询一个一定不存在的数据时,由于缓存中没有此数据,每次查询都会落到数据库层。恶意攻击或程序bug可能会不停尝试不存在的数据查询,使得数据库蒙受巨大压力。
  • 缓存击穿: 特指对于那些热门key,在缓存失效的瞬间,大量并发请求同时到达,这些请叱责部穿透缓存直达数据库,对数据库形成巨大压力。
  • 缓存雪崩: 是指在一段时间内,大量缓存在同一时刻集体失效,后续请求均直接打到数据库,可能导致数据库瞬间压力过大,服务不可用。
  • 大Key: 制止在redis中存储大量数据,导致内存大量使用,以及大key操作导致堵塞,分布式部署下节点内存使用不均,等题目。
  • Key命名: key长度不宜太长,尽可能简短且清晰表达用途,key需要能够根据业务领域、模块区分前缀,易于后续管理区分业务,尤其是对于redis集群共用的业务,后续做大key清理、redis拆分迁移。
  • 过期时间: 一般使用redis做热数据存储,也存在一些做持久化的场景,但是大部分都是需要对key设置过期时间,制止冷缓存,恒久占用内存空间,资源被浪费。
  • 数据同等性: 数据DB更新,未能及时同步redis,导致数据不同等题目,对于同等性要求高的业务,需要重点考虑更新计谋,保障同等性。
  • 缓存预热:缓存预热是在系统启动或低负载时段预先加载热门数据到缓存中,制止在高负载时发生缓存缺失。
消息队列



  • 在过往的业务开辟过程中,经常会有一些功能需求,它需要在核心接口中拓展,但黑白接口主要流程内容,同时可以接受一定耽误处理,我们每每会引入消息队列的使用,
  • 消息队列(如RabbitMQ、Kafka)在分布式系统中用于解耦服务,实现异步通讯,提高系统的可扩展性和容错性。

    • 业务 解耦:生产者和消费者不需要直接知道对方的存在,降低了系统的耦合度。
    • 削峰填谷:帮助平滑系统负载,处理请求峰值,防止系统过载。
    • 异步处理:生产者无需等待消息处理完成即可继续工作,提高了系统响应速度和吞吐量。
    • 可扩展性和灵活性:容易添加或更改消费者,适应系统变革。

消息队列可能带来的题目



  • ACK 机制: 消息的执行需要确认被消费者乐成消费后,才气从消息队列中移除。
  • 容错机制: 需要保障消费结果终极乐成,通过异常兜底,大概消息的死信队列,保障异常情况下消息也能够兜底处理。
  • 结果幂等: 不能完全信任生产者的消息不重复,以是需要保障多次执行相同消息后结果幂等。
  • 执行时序/顺序: 当存在多个消费者同时消费的时间,需要考虑消费时序题目,可能后进的会被先执行,需要保障逻辑不被影响,如果存在影响,就需要考虑将消息进行分片路由到不同队列中,进行多消费者消费,提高吞吐的同时,也能保障相同标识的消息执行时序是正确的。
并发

在面临一些性能题目的时间,每每都是有一些耗时的操作(如I/O操作、网络请求、数据库访问等),除了将耗时的操作本身进行优化以外,我们还可以使用并发编程,golang 里面最常用的就是使用协程实现并发编程

并发可能带来的题目



  • 负载评估: 需要对并行操作的发起方和目的方服务器进行负载、服务器资源利用率的情况进行评估,在一些高并发、高峰期场景下,服务器本身负载就高,再对其并行改造,可能会事倍功半,可能会发展成压死骆驼的最后一根稻草,把服务搞崩溃了。
容量评估

根据应用的DAU、MAU,模块接口请求QPS、业务未来拓展方向、等信息,进行容量评估,作为设计的前置信息,衡量技术方案可行性。
容量评估包罗这些内容:


  • QPS : 评估每秒请求数目,均匀值、最高值,用于方案设计,以及性能压测。
  • DAU: 评估功能日访问量。
  • 数据量: 评估用户大概日生产数据量,用于用户表设计,如:是否纵向拆分列、横向分表、索引设计。
  • 资源利用: 评估数据存储占用多少空间、应用服务占用多少资源(cpu、mem、i/o、load、…),用于评估部署机器配置、是否扩容 。
  • 预测增长: 评估未来增长情况,用于方案设计考虑未来可拓展、可伸缩。
服务压测

压测需要订定一套标准,如:什么接口需要性能测试?性能测试需要关注哪些指标?以及指标的基线要求。
以下是一些压测标准,仅供参考


  • 是否 压测 : P0、P1核心业务接口、高 QPS 接口、无依赖第三方 / 内部耗时服务(算法/搜索…) 接口 。
  • 压测 配置: 最低48线程数,支持按倍数增长、压测时间、压测倍数、等。
  • 关注指标:请求数、QPS、TPS、CPU、MEM、I/O、Load、响应时间、错误数、错误率。
  • 判定依据: 性能测试基线 + 容量评估。
  • 单容器 压测 通过基线:

    • 响应时间 < 500ms
    • TPS > 500,QPS> 1000
    • 乐成率 100%;
    • 在达到接口处理能力预期指标值时,数据库无慢查询出现;
    • 均匀 CPU < 75%,均匀负载小于 CPU 的核数
    • 趋势上在并发数增长情况下,TPS 跟随增长,响应时间 < 500ms。

监控预警

实实际时监控,当性能指标超出预设阈值时,系统应能自动发出告警,以便及时采取措施。


  • 高性能的系统通常需要实时、正确的性能监控。通过监控关键性能指标(如CPU使用率、内存占用、磁盘I/O、网络带宽、响应时间等),可以及时发现系统瓶颈和异常状况。这些数据是衡量系统是否运行在高性能状态的重要依据,也是调优的出发点。
  • 监控系统不但要收集数据,还需要具备预警功能。当监控到的性能指标超过预设阈值时,预警系统会自动触发警告,通过邮件、短信、电话或集成的消息系统关照运维人员。这样可以在题目影响用户体验或造成系统故障之前,及时采取行动进行干预,保障系统的高性能运行。
  • 在可观测性的内容中,可以抽象出三大元素:日志(Logs) 、跟踪(Traces) 、指标(Metrics) ,这三大元素就是可观测性的三大支柱。
USE 方法

USE是utilization、saturation、erros(利用率、饱和度、错误)三个词的缩写,应用于性能研究,用来识别系统瓶颈,一言以蔽之,就是:对于所有的资源,查察它的使用率、饱和度和错误。


  • 识别系统中有哪些资源(CPU/内存/磁盘/IO带宽等)
  • 分别查察这些资源的三个指标(使用率、饱和度和错误)跟进现象,分析并缩小性能瓶颈的范围(数据中央,服务集群,单机节点,进程,线程,函数,指令)
  • 定位瓶颈,使用适当的优化计谋进行优化
  • 观测系统,验证优化收益
  • Utilization:整个系统的均匀 CPU 利用率
  • Saturation:一个近似值是第 99 个之间的差异耽误百分位平静均耽误(假设第 99 个是饱和驱动的)
  • Errors:每秒失败的请求数
RED 方法

RED 方法界说了应为体系布局中的每个微服务度量的三个关键指标。这些指标是:
*(请求)Rate - 您服务每秒提供的请求数
*(请求)Errors - 每秒失败的请求数
*(请求)Duration - 每个请求所花时间的分布
一般来说,RED方法只实用于请求驱动的服务,它不实用于面向批处理或流式服务。 它也不是包罗万象的。 而 USE 方法应用于主机 CPU 和内存或缓存等资源时就是一个很好的例子。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

水军大提督

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表