0


Java后端项目性能优化实战-群发通知

背景

公司群发通知模块性能存在问题,我进行全面的系统调优,系统处理能力大幅提升。

原发送流程

在这里插入图片描述

优化后的发送流程

在这里插入图片描述

优化的点

  • 说明:以下问题基本都是压测过程遇到的,有些问题普通的功能测试暴露不了。
  • 优化目标:保证高可用、高并发、可扩展。

添加索引

普通索引:

  • 现象:发送过程出现SQL超时异常。
  • 原因:基本都是随着数据量不断提升,某些表没有索引导致的,对于群发这个场景,会因为这种异常影响主流程。
  • 建议:设计表的时候预估业务量,对于关键字段添加索引是成本最低的性能优化手段。

唯一索引:

  • 现象:生成的雪花ID重复,导致数据库要求的唯一字段重复。
  • 原因:多节点雪花算法指定了相同的数据中心ID和机器ID,高并发情况下导致重复。
  • 建议:某些需要保证唯一的场景,不要过分依靠代码逻辑,数据库添加唯一索引至少可以保证一致性。

优化表结构(垂直拆分、水平拆分)

  • 现象:发送过程中有一个发送记录表被锁死。
  • 原因:发送、第三方回调、定时任务都会去操作这个表(包括新增、修改),update操作的时候会加锁,导致大量请求排队处理。(这里把发送记录和回调记录拆成了2个表,瞬间缓解了压力)
  • 建议:合理的进行表结构设计,解耦,不强相关的字段可以拆成多个表。

雪花ID处理

  • 现象:生成的雪花ID重复
  • 原因:多节点雪花算法指定了相同的数据中心ID和机器ID,高并发情况下导致重复。
  • 建议:网上有很多方案 - 大厂的做法应该是有一个专门生成雪花ID的服务集群- 思路是使用注册中心、redis等维护数据中心ID和机器ID- 我们目前的临时方案是采用redis的递增,每次服务重启递增拿id,到某个值之后清零(这种方案解决我们目前的场景没什么问题,当集群机器数增加和遇到不断重启的场景可能会有点问题)

使用设计模式

  • 现象:之前代码很多地方采用if else、switch,代码可读性和可扩展性都很差。
  • 原因:一开始开发时间比较赶,想着if else、switch写起来方便。
  • 建议:预估可能会频繁扩展的地方使用工厂模式、策略模式、模板方法模式提高扩展性。(主要就是添加新功能可以尽可能少的改动其他代码)

池化思想

  • 现象:http句柄被用完
  • 原因: - 服务有时候发送大量http请求,导致http句柄被用完。- redis、数据库没用连接池导致频繁创建和销毁连接。- 没用线程池,导致频繁创建销毁线程等。
  • 建议:能用池的就尽量用池,可以提高效率、节约资源。

批处理思想

  • 现象:接口效率低、占用资源多
  • 原因:频繁操作数据库、频繁调用第三方接口
  • 建议:看看能不能分批处理、有没有批量接口

集群思想

  • 现象:处理慢
  • 原因:一台机器处理能力有限
  • 建议:想办法利用集群的优势、把压力分散到其他节点

使用MQ

  • 现象:突然的流量洪流使系统满载或者崩溃
  • 原因:系统处理能力有限
  • 建议:使用MQ销峰,先把要处理的任务推送到MQ,消费者根据自己的消费能力指定消费线程数慢慢处理。

使用多线程

  • 现象:代码执行效率低
  • 原因:逻辑多,串行处理,没用充分利用cpu和内存资源
  • 建议:适当使用多线程相关技术提高效率,JUC包下面的工具

JVM调优

  • 现象:OOM、系统停顿
  • 原因:代码复杂之后(高并发、大数据)、运用了很多线程池、批处理,内存和cpu消耗会有上升
  • 建议: - 通过压测合理设置JVM参数(垃圾回收器、堆内存配置等)- 常用的观察工具使用(本地VisualVM、线上Arthas等,还有其他的);- 观察GC次数和时间,Full GC会暂停整个进程- 观察堆内存使用情况(防止各个区域OOM)

使用限流

  • 现象:突然的流量洪流使系统满载或者崩溃
  • 原因:系统处理能力有限
  • 限制接口处理能力,多余请求直接拒绝

服务拆分

  • 现象:已经不能从技术上优化系统了
  • 原因:服务处理能力有限,业务放到一起会互相影响
  • 合理的服务拆分,根据不同服务的业务量来选择部署方案

数据一致性保证

  • 现象:服务重启、OOM会导致业务流程中断,导致业务没有执行完整
  • 原因:业务流程太长
  • 预估可能会出现的系统问题,合理的设计做补偿措施,就算出错了也要有办法能够补偿回来

使用缓存

库存处理等使用缓存,避免频繁操作数据库


本文转载自: https://blog.csdn.net/py1215/article/details/137012975
版权归原作者 peakyu 所有, 如有侵权,请联系我们删除。

“Java后端项目性能优化实战-群发通知”的评论:

还没有评论