优化整理
2021-10-31 21:57:52 0 举报AI智能生成
各种优化整理（持续中）
作者其他创作
大纲/内容
查看是否由于代码写的不合理
for循环次数过多
很多无畏的条件判断
相同逻辑重复多次
代码
表示从池里获取连接的等待时间
可以设置一个比较短的时间，否则会因为长时间等待获取连接，在高并发场景下，导致连接池瞬间耗尽，大量的请求卡死在这里等待获取连接，进而导致tomcat里没有可用的线程（造成服务的假死）
maxWait
高并发场景下，万一遇到网络问题，可能导致你跟数据库的socket连接异常无法通信，此时socket可能一直卡死等待某个请求的响应，然后其他请求无法获取连接，只能重启系统重新获取
设置超时时间后，可用让网络异常之后，连接自动超时断开
两个参数分别代表建立tcp连接的超时时间，以及发送请求后等待响应的超时时间
connectionTimeout和socketTimeout
最大连接池数量，一般设置20就够了，如果有高并发场景，可用适当增加3-5倍，太多的话会导致cpu负载很难高，导致性能降低
maxActive
更应该优化每个请求的性能，别让一个请求占用连接太长的时间
数据库连接池
尽量不要在一个tomcat下创建多个虚拟主机，而是每个站点一个实例（即启动多个tomcat）因为tomcat是多线程，共享内存，任何一个虚拟主机中的应用出现崩溃，都会影响所有应用程序
压缩会增加tomcat负担，最好采用nginx + tomcat，将压缩交给nginx
当客户端接收请求，进行三次握手创建连接后把连接放入accept队列
acceptCount
acceptor线程读取accept队列中的连接，交给线程池处理请求，当处理的连接数超过maxConnections，读取accept队列的线程会阻塞
maxConnections
处理连接请求的最大线程数
不能设置过大，因为jvm每个线程会占用1M空间，应结合虚拟机配置设置该值，并发数量过大，可以设置tomcat集群，通过nginx分发请求
maxThreads
参数设置
tomcat
查看慢查询日志，然后用explain、profile等逐步调优，最后经过测试达到效果后上线
mysql为例
sql调优
定期跟踪一些指标数据是否达到瓶颈，达到时就要考虑做如下优化
读写分离
多从库负载均衡
水平和垂直分库分表
架构层面调优
结合当前使用连接池的原理，具体的连接池监控数据和当前业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数
连接池优化
数据库
针对某些客户端请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关系或者不需要立即拿到这些事情的处理结果
使用场景
缩短接口响应时间
避免线程长时间处于运行状态，会引起服务线程池的可用线程长时间不够用
线程长时间处于运行状态，可能会引起系统性能下降
作用
额外开辟线程，在IO线程（处理请求响应）之外的线程来处理相应的任务，如果任务设计的数据量非常大，可用引入阻塞队列作进一步优化
使用消息队列
常见方法
异步
如果业务数据不需要和其他数据作关联，不需要事务或者外键之类的支持，而且有可能写入会异常频繁
比如记录异常日志，如果应用系统发生严重故障的时候，可能会短时间产生大量exception数据，如果选择关系型数据库，会造成数据库的瞬间写压力
NoSQL
短时间内相同数据重复查询多次且数据更新不频繁
高并发查询热点数据
需要一些策略支持，考虑ehcache
普通使用场景，考虑hashmap
多线程并发，考虑concurrenthashmap
数据量小，并且不会频繁增长又请求，可以选择本地缓存
其他请求考虑缓存服务（类似redis）
选型考虑
接收变更消息，准实时更新
对第一个策略的补充
设置过期时间，过期后从db加载
什么时候更新缓存
给缓存服务，选择合适的缓存逐出算法，比如常见的LRU
针对当前设置的容量，设置适当的警戒值，比如10G的缓存，当缓存数据达到8G的时候，就i开始发出报警，提交排查问题或扩容
给一些没有必要长期保存的key，尽量设置过期时间
缓存是否会满，缓存满了怎么办
根据业务场景判断，是否允许丢失，如果不允许，就需要带持久化功能的缓存服务来支持
如果要严格不允许数据丢失，则要避免使用缓存
缓存是否允许丢失，丢失了怎么办
缓存被击穿问题
设计关键的
缓存
优化整理
0 条评论
回复 删除
下一页
