ToB企服应用市场:ToB评测及商务社交产业平台

标题: 分布式系统稳固性建立-性能优化篇 [打印本页]

---

作者: 水军大提督    时间: 2024-11-24 20:59
标题: 分布式系统稳固性建立-性能优化篇
分布式系统稳固性建立-性能优化篇

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

• 架构设计:
  
  
  
  • 采用模块化、松耦合的架构设计,以提高系统的可扩展性和可维护性。
    
  • 合理划分系统功能模块,降低单个模块的复杂度。
    
  • 界说清晰的接口和数据交换标准,确保各模块之间协调工作。
    
  
  
• 容错机制:
  
  
  
  • 建立完善的异常处理和容错机制,及时检测并隔离故障,防止故障流传。
    
  • 实现关键功能的冗余备份,提高系统的可用性。
    
  • 设计自动恢复和自修复机制,缩短系统故障的恢复时间。
    
  
  
• 性能优化:
  
  
  
  • 进行系统性能测试和瓶颈分析,确定系统的承载能力。
    
  • 优化关键模块的性能,提高系统的团体响应速度。
    
  • 采用缓存、异步处理等手段,缓解系统的瞬时压力。
    
  
  

性能优化

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

代码优化

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

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

缓存优化

• 想要提高服务的性能，根本会想到可以使用缓存来提高性能、应用服务的缓存一般就是存储一些使用频繁、但是存储空间占用不大，且根本不怎么变更的数据，大概作为多级缓存中的一级。
  
• 缓存是提拔系统性能的关键技术之一，通过减少数据访问耽误和降低后端存储压力，明显加快数据检索速度。在现代应用架构中，缓存不但用于提拔用户体验，也是实现高并发处理的底子。
  
• 在分布式的场景在，应用服务缓存需要留意多节点缓存更新题目、同等性题目、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企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4