汶川县建设局网站,烟台唯佳网络科技有限公司,福永网站推广,高质量的南京网站建设背景
公司群发通知模块性能存在问题#xff0c;我进行全面的系统调优#xff0c;系统处理能力大幅提升。
原发送流程 优化后的发送流程 优化的点
说明#xff1a;以下问题基本都是压测过程遇到的#xff0c;有些问题普通的功能测试暴露不了。优化目标#xff1a;保证高…背景
公司群发通知模块性能存在问题我进行全面的系统调优系统处理能力大幅提升。
原发送流程 优化后的发送流程 优化的点
说明以下问题基本都是压测过程遇到的有些问题普通的功能测试暴露不了。优化目标保证高可用、高并发、可扩展。
添加索引
普通索引
现象发送过程出现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会导致业务流程中断导致业务没有执行完整原因业务流程太长预估可能会出现的系统问题合理的设计做补偿措施就算出错了也要有办法能够补偿回来
使用缓存
库存处理等使用缓存避免频繁操作数据库 …
