后端服务性能优化实战篇

本文简单介绍下后端服务开发中常用的一些性能优化策略。

1、代码

优化代码实现是第一位的,特别是一些不合理的复杂实现。如果结合需求能从代码实现的角度,使用更高效的算法或方案实现,进而解决问题,那是最简单有效的。

2、数据库

数据库的优化,总体上有3个方面:

1)  SQL调优:除了掌握SQL基本的优化手段,使用慢日志定位到具体问题SQL,使用explain、profile等工具来逐步调优。

2)  连接池调优:选择高效适用的连接池,结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断,通过反复的几次调试得到最终的调优参数。

3)  架构层面:包括读写分离、主从库负载均衡、水平和垂直分库分表等方面,一般需要的改动较大,需要从整体架构方面综合考虑。

3、缓存

分类

本地缓存(HashMap/ConcurrentHashMap、Ehcache、RocksDB、Guava Cache等)。

缓存服务(Redis/Tair/Memcache等)。

设计关键点

1、什么时候更新缓存?如何保障更新的可靠性和实时性?

更新缓存的策略,需要具体问题具体分析。基本的更新策略有两个:

1)  接收变更的消息,准实时更新。

2)  给每一个缓存数据设置5分钟的过期时间,过期后从DB加载再回设到DB。这个策略是对第一个策略的有力补充,解决了手动变更DB不发消息、接收消息更新程序临时出错等问题导致的第一个策略失效的问题。通过这种双保险机制,有效地保证了缓存数据的可靠性和实时性。

2、缓存是否会满,缓存满了怎么办?

对于一个缓存服务,理论上来说,随着缓存数据的日益增多,在容量有限的情况下,缓存肯定有一天会满的。如何应对?

1)  给缓存服务,选择合适的缓存逐出算法,比如最常见的LRU。

2)  针对当前设置的容量,设置适当的警戒值,比如10G的缓存,当缓存数据达到8G的时候,就开始发出报警,提前排查问题或者扩容。

3)  给一些没有必要长期保存的key,尽量设置过期时间。

3、缓存是否允许丢失?丢失了怎么办?

根据业务场景判断,是否允许丢失。如果不允许,就需要带持久化功能的缓存服务来支持,比如Redis或者Tair。更细节的话,可以根据业务对丢失时间的容忍度,还可以选择更具体的持久化策略,比如Redis的RDB或者AOF。

缓存问题

1、缓存穿透

描述:缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。

解决方案:

1)  接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截;

2)  从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-value对写为key-null,缓存有效时间可以设置短点,如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击。

2、缓存击穿

描述:缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力。

解决方案:

1)  设置热点数据永远不过期。

2)  加互斥锁,业界比较常用的做法,是使用mutex。简单地来说,就是在缓存失效的时候(判断拿出来的值为空),不是立即去load db,而是先使用缓存工具的某些带成功操作返回值的操作(比如Redis的SETNX或者Memcache的ADD)去set一个mutex key,当操作返回成功时,再进行load db的操作并回设缓存;否则,就重试整个get缓存的方法。类似下面的代码:

public String get(key) {
    String value = redis.get(key);
    if (value == null) { //代表缓存值过期
        //设置3min的超时,防止del操作失败的时候,下次缓存过期一直不能load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
            value = db.get(key);
                    redis.set(key, value, expire_secs);
                    redis.del(key_mutex);
            } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了,这时候重试获取缓存值即可
                    sleep(50);
                    get(key);  //重试
            }
        } else {
            return value;
        }
}

3、缓存雪崩

描述:缓存雪崩是指缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至down机。和缓存击穿不同的是,缓存击穿是并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

解决方案:

1)缓存数据的过期时间设置随机,防止同一时间大量数据过期现象发生。

2)如果缓存系统是分布式部署,将热点数据均匀分布在不同的缓存节点中。

3)设置热点数据永远不过期。

4、缓存更新

Cache Aside 模式:这是最常用最常用的pattern了。其具体逻辑如下:

失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。

命中:应用程序从cache中取数据,取到后返回。

更新:先把数据存到数据库中,成功后,再让缓存失效。

4、异步

使用场景

针对某些客户端的请求,在服务端可能需要针对这些请求做一些附属额外的事情,这些事情其实用户并不关心或者不需要立即拿到这些事情的处理结果,这种情况就比较适合用异步的方式去处理。

作用

异步处理的好处:

1)  缩短接口响应时间,使用户的请求快速返回,用户体验更好。

2)  避免线程长时间处于运行状态,这样会引起服务线程池的可用线程长时间不够用,进而引起线程池任务队列长度增大,从而阻塞更多请求任务,使得更多请求得不到及时处理。

3)  提升服务的处理性能。

实现方式

1、线程(线程池)

采用额外开辟一个线程或者使用线程池的做法,在IO线程(处理请求响应)之外的线程来处理相应的任务,在IO线程中让response先返回。

如果异步线程处理的任务设计的数据量非常大,那么可以引入阻塞队列BlockingQueue作进一步的优化。具体做法是让一批异步线程不断地往阻塞队列里添加要处理的数据,然后额外起一个或一批处理线程,循环批量从队列里拿预设大小的数据,来进行批处理,这样进一步提高了性能。

2、消息队列(MQ)

使用消息队列(MQ)中间件服务,MQ天生就是异步的。一些额外的任务,可能不需要这个系统来处理,但是需要其他系统来处理。这个时候可以先把它封装成一个消息,扔到消息队列里面,通过消息中间件的可靠性保证把消息投递到关心它的系统,然后让其他系统来做相应的处理。

5、NoSQL

和缓存的区别

这里介绍的NoSQL和缓存不一样,虽然可能会使用一样的数据存储方案(比如Redis或者Tair),但是使用的方式不一样,这一节介绍的是把它作为DB来用。如果当作DB来用,需要有效保证数据存储方案的可用性、可靠性。

使用场景

需要结合具体的业务场景,看这块业务涉及的数据是否适合用NoSQL来存储,对数据的操作方式是否适合用NoSQL的方式来操作,或者是否需要用到NoSQL的一些额外特性(比如原子加减等)。

如果业务数据不需要和其他数据作关联,不需要事务或者外键之类的支持,而且有可能写入会异常频繁,这个时候就比较适合用NoSQL(比如HBase)。监控类、日志类系统通常会采集大量的时序数据,这类时序指标数据往往都是“读少写多”的类型,可以使用Elasticsearch、OpenTSDB等。

6、多线程与分布式

使用场景

离线任务、异步任务、大数据任务、耗时较长任务的运行,适当地利用,可达到加速的效果。

注意:线上对响应时间要求较高的场合,尽量少用多线程,尤其是服务线程需要等待任务线程的场合(很多重大事故就是和这个息息相关),如果一定要用,可以对服务线程设置一个最大等待时间。

常见做法

如果单机的处理能力可以满足实际业务的需求,那么尽可能地使用单机多线程的处理方式,减少复杂性;反之,则需要使用多机多线程的方式。

对于单机多线程,可以引入线程池的机制,作用有二:

1)  提高性能,节省线程创建和销毁的开销。

2)  限流,给线程池一个固定的容量,达到这个容量值后再有任务进来,就进入队列进行排队,保障机器极限压力下的稳定处理能力在使用JDK自带的线程池时,一定要仔细理解构造方法的各个参数的含义,如core pool size、max pool size、keepAliveTime、worker queue等,在理解的基础上通过不断地测试调整这些参数值达到最优效果。

如果单机的处理能力不能满足需求,这个时候需要使用多机多线程的方式。这个时候就需要一些分布式系统的知识了,可以选用一些开源成熟的分布式任务调度系统如xxl-job。

7、JVM优化

个人主要的后端语言是JAVA,对JVM进行优化也能一定程度上的提升JAVA程序的性能。JVM通常能够在软件开发后期进行,如在开发完毕或者是软件开发的某一里程碑阶段,JVM的各项參数将会直接影响JAVA程序的性能。

性能指标

关注以下指标:CPU使用率、CPU load、GC count、GC time、GC日志

查看java进程GC状态:jstat -gcutil {pid} 1000

查看java进程CPU高原因:

1)  获取java进程pid:ps –ef|grep java

2)  分析是哪个线程占用率过高:top -H -p ‘PID’

3)  线程id转换为16进制:printf "%x\n" ‘NID’

4)  Jstack查看线程堆栈:jstack PID | grep ‘NID‘ -C行数 –color

推荐2个java工具:1)show-busy-java-threads 2)arthas

优化方向

比如,JVM的堆大小(Xms、Xmx),垃圾回收策略等。要进行JVM层面的调优,需要对JVM的执行原理有一定的了解,如内存的结构,GC的种类等,然后根据应用程序的特点设置合理的JVM參数,但是GC tuning is the last task to be done.

参考:

https://tech.meituan.com/2016/12/02/performance-tunning.html

https://blog.csdn.net/qq_42894896/article/details/82256770

https://www.cnblogs.com/java-chen-hao/p/10656304.html

原文地址:https://www.cnblogs.com/luxiaoxun/p/11755177.html

时间: 2024-10-22 18:01:12

后端服务性能优化实战篇的相关文章

面向.Net程序员的后端性能优化实战

最近2个月没做什么新项目 完全是对于旧的系统进行性能优化 避免超时 死锁 数据处理能力不够等常见的性能问题 这里不从架构方面出发 毕竟动大手脚成本比较高 那么我们以实例为前提 从细节开始 优化角度 一.业务逻辑优化 二.DB优化 三.数据处理优化 四.锁与性能 五.cpu飙高小结 六.crash现象分析 业务逻辑优化 这一条不具有普遍性 不同的业务不同的场景 如果归纳起来 就是在不影响业务的前提下进行流程精简 1. 废弃冗余逻辑 常见于各种基于数据库的检查 很多同学在维护别人代码的时候 没有深入

Android性能优化——工具篇

Android性能优化是Android开发中经常遇见的一个问题,接下来将对Android性能优化方面的知识点做一个简单的梳理和总结,将从工具和代码两方面进行梳理.所谓工欲善其事必先利其器,本文首先来看一下Android性能优化有哪些得力的工具. TraceView traceview是Android SDK中自带的一个工具,可以对应用中方法调用耗时进行统计分析,是Android性能优化和分析时一个很重要的工具.traceview位于SDK下的tools目录中,使用时可以在cmd窗口运行trace

蚂蚁金服架构师带你深入性能优化一MySql性能优化实战

概要: Mysql的优化,大体可以分为三部分:索引的优化,sql语句的优化,表的优化.本文主要帮助自己整理思路,也可作为一个学习MySQL优化的提纲. 索引的优化 只要列中含有NULL值,就最好不要在此例设置索引,复合索引如果有NULL值,此列在使用时也不会使用索引 尽量使用短索引,如果可以,应该制定一个前缀长度 对于经常在where子句使用的列,最好设置索引,这样会加快查找速度 对于有多个列where或者order by子句的,应该建立复合索引 对于like语句,以%或者'-'开头的不会使用索

android性能优化实战理论篇

本文地址:http://blog.csdn.net/iamws/article/details/51636175 第二篇:理论 通过之前前篇介绍的工具,我们知道了应该怎么样去获取要分析的数据,但是也仅仅局限在于怎么样获取数据,而没有深入数据分析,这一篇主要讲解的是UI刷新这块部分android理论知识,有了这些知识后,对于上面的数据该怎么分析,你就胸有成竹了. ps:本文只是个人理解后的总结,并不会深入源码层次分析,如有错误,还请麻烦各位帮忙指正~ 这篇文章要解决的理论问题如下: 1.什么是内存

Linux性能优化实战:案例篇-DNS 解析时快时慢,我该怎么办?(37)

一.上节回顾 上一节,我带你一起学习了网络性能的评估方法.简单回顾一下,Linux 网络基于 TCP/IP协议栈构建,而在协议栈的不同层,我们所关注的网络性能也不尽相同. 在应用层,我们关注的是应用程序的并发连接数.每秒请求数.处理延迟.错误数等,可以使用 wrk.Jmeter 等工具,模拟用户的负载,得到想要的测试结果. 而在传输层,我们关注的是 TCP.UDP 等传输层协议的工作状况,比如 TCP 连接数.TCP 重传.TCP 错误数等.此时,你可以使用 iperf.netperf 等,来测

扫‘雷’ 纯后端性能优化实战(已合下篇)

最近2个月没做什么新项目 完全是对于旧的系统进行性能优化 避免超时 死锁 数据处理能力不够等常见的性能问题 这里不从架构方面出发 毕竟动大手脚成本比较高 那么我们以实例为前提 从细节开始 优化角度 一.业务逻辑优化 二.DB优化 三.数据处理优化 四.锁与性能 五.cpu飙高小结 六.crash现象分析 业务逻辑优化 这一条不具有普遍性 不同的业务不同的场景 如果归纳起来 就是在不影响业务的前提下进行流程精简 1. 废弃冗余逻辑 常见于各种基于数据库的检查 很多同学在维护别人代码的时候 没有深入

从细节出发 纯后端性能优化实战小结

最近2个月没做什么新项目 完全是对于旧的系统进行性能优化 避免超时 死锁 数据处理能力不够等常见的性能问题 这里不从架构方面出发 毕竟动大手脚成本比较高 那么我们以实例为前提 从细节开始 优化角度 一.业务逻辑优化 二.DB优化 三.数据处理优化 四.锁与性能 五.细节 业务逻辑优化 这一条不具有普遍性 不同的业务不同的场景 如果归纳起来 就是在不影响业务的前提下进行流程精简 1. 废弃冗余逻辑 常见于各种基于数据库的检查 很多同学在维护别人代码的时候 没有深入理解别人的逻辑 也许别人在取数据的

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句