高端建站收费标准,宣传设计网站,河北建设网站企业锁在哪下载,wordpress建站案例性能优化思维
整体思维
木桶效应#xff1a;系统的性能符合木桶效应#xff08;一个木桶能装多少水#xff0c;取决于木桶中最短的那块木板#xff09;#xff0c;所以性能优化需要从多个方面去考虑#xff0c;如架构优化、业务优化、前端优化、中间件调优、网关优化、…性能优化思维
整体思维
木桶效应系统的性能符合木桶效应一个木桶能装多少水取决于木桶中最短的那块木板所以性能优化需要从多个方面去考虑如架构优化、业务优化、前端优化、中间件调优、网关优化、JVM优化、数据库优化、代码优化、容器/硬件优化等优化分类 架构优化从系统整体架构考虑如读写分离、集群部署、引入缓存/搜索/消息中间件、中台架构、分库分表等参数优化从系统组件方面考虑如JVM、服务器、数据库、中间件、网关、容器等组件的参数调整代码优化从代码方面考虑如代码中采用更优秀的算法思想/设计模式、SQL优化、对中间件的操作优化等
单个服务层面
在程序中业务的执行实体都是线程所以程序的性能一般与线程挂钩 CPU、内存、磁盘等硬件资源线程最终会由CPU进行调度时间片轮训执行且在线程的执行过程也必然需要对数据进行操作绝大部分的业务本质都是对数据的CURD最终都是与内存、磁盘打交道 关联线程越多需要的CPU调度能力也就越强需要的内存也越大磁盘IO速率也会要求越快当三者之间任意一个达到了瓶颈程序中的线程数量也会达到极限达到极限后系统的性能会成抛物线式下滑从而可能导致系统整体性能下降乃至瘫痪 所以一般不能让CPU、内存、磁盘等资源的使用率达到95%最大利用率控制在80-85%左右为最佳状态。 线程工作模型程序设计中主要存在三种线程处理模型BIO、NIO、AIO可以参考 BIO阻塞IO模型BIO是最传统的一对一处理模型也就是一个客户端请求分配一条线程处理NIO非阻塞IO模型NIO的最佳实践为reactor模型AIO异步IO模型AIO落地实现proactor模型
架构层面
优秀且合适的架构胜过多次调优一个使用TomcatMySQL部署的系统无论如何调优都无法处理万级并发架构需要符合实际业务没有完美的架构只有最合适的架构从现有环境及实际业务出发选用最为合适的技术体系这才是我们应该做的事情。如 项目业务中读写参半单节点难以承载压力可以考虑项目集群、双主热备值等项目业务中写大于读可以考虑引入消息中间件、DB分库、项目集群等项目业务中读大于写可以考虑引入缓存/搜索中间件、动静分离、读写分离等 架构可以进一步优化当系统原有架构遇到性能瓶颈时可以考虑进一步做架构优化如设计多级分布式缓存、缓存中间件做集群、消息中间件做集群、Java程序做集群、数据库做分库分表、搜索中间件做集群等随着引入的技术越多系统会越庞大需要考虑的问题也会更加棘手但带来的性能提升也是显著的
预防大于解决
当问题在出现时再想办法解决这是一种下下策防范于未然才是最佳方案项目初期在项目初期我们应该对未来的流量压力、数据大小等进行预测提前根据业务和设计出合适的架构确保上线后可以承载业务的正常压力和增长不要“卡点”设计也不能过度设计造成性能过剩项目上线后计划赶不上变化项目初期的预测难免会出现偏差一套完善的监控系统在性能瓶颈来临前设好警报线确保能够在真正的性能瓶颈到来之前解决问题
性能调优的核心步骤
通常而言性能优化的步骤可分为如下几步
发现性能瓶颈如有监控系统那它会主动发出警报如若没有那出现瓶颈时应用肯定会出问题如无响应、响应缓慢、频繁宕机等。排查瓶颈原因排查瓶颈是由于故障问题导致的还是真的存在性能瓶颈。定位瓶颈位置往往一个系统都会由多个层面协同工作然后对外提供服务当发现性能瓶颈时应当确定瓶颈的范围如网络带宽瓶颈、Java应用瓶颈、数据库瓶颈等。解决性能瓶颈定位到具体的瓶颈后对症下药从结构、配置、操作等方面出发着手解决瓶颈问题。
Mysql性能优化
一般分为五个维度
客户端与连接层优化
调整客户端DB连接池参数和DB连接层参数
客户端的连接池大小设置可以参考PostgreSQL的计算公式最大连接数 (CPU核心数 x 2) 有效磁盘数SSD固态硬盘数量 为什么不限制服务端连接数MySQL实例一般情况下只为单个项目提供服务应用程序的连接数做了限制自然也就限制了服务端的连接数正常来说MySQL的最大连接数应大于客户端连接池的最大连接数存在通过终端工具远程连接MySQL等情况如果设置一致就很有可能导致MySQL连接数爆满对于最佳连接数的计算首先要把CPU核数放首位考虑紧接着是磁盘最后是网络带宽因为带宽会影响SQL执行时间综合考虑后才能计算出最合适的连接数大小 偶发高峰类业务的连接数配置在某些时间段或者活动开始时流量会高于平时流量可以将常驻连接数配成CPU核数1同时缩短连接的存活时间及时释放空闲的数据库连接mysql最大连接数设置set max_connections n;
Mysql参数优化
设置方式启动之后通过set global xxx xxx的方式调整但最好还是直接修改my.ini/my.conf配置文件InnoDB缓冲区配置innodb_buffer_pool_size一般为内存的70%80% 实例空间当InnoDB的缓冲区空间大于1GB时会自动划分多个实例空间可以在多线程并发执行时减少并发冲突MySQL官方的建议是每个缓冲区实例须大于1GB,通过innodb_buffer_pool_instances设置 工作线程缓冲区配置最好根据机器内存设置为一到两倍MB大小 sort_buffer_size排序缓冲区大小影响group by、order by...等排序操作。 max_length_for_sort_data如果排序字段值的最大长度小于该值则会将所有要排序的字段值载入内存排序但如果大于该值时则会一批一批的加载排序字段值进内存然后一边加载一边做排序 read_buffer_size读取缓冲区大小影响select...查询操作的性能。join_buffer_size联查缓冲区大小影响join多表联查的性能。 调整临时表空间tmp_table_size、max_heap_table_size两个参数主要是限制临时表可用的内存空间当创建的临时表空间占用超过tmp_table_size时就会将其他新创建的临时表转到磁盘中创建 参数大小可以根据show global status like created_tmp%;统计信息决定Created_tmp_disk_tables / Created_tmp_tables * 100% 120% 调整空闲线程的存活时间 查看数据库连接峰值show global status like Max_used_connections;空闲连接的超时时间wait_timeout、interactive_timeout默认八小时也就是一个连接断开后默认也会将对应的工作线程缓存八小时后再销毁这里我们可以手动调整成30min~1h左右可以让无用的连接能及时释放减少资源的占用。
编码层面优化 编写sql时需考虑sql是否走索引可以参考索引使用 查询时尽量按需取字段避免使用* 当使用*时解析器需要先去解析出当前要查询的表上*表示哪些字段因此会额外增加解析成本InnoDB会将查询的结果放入缓存中查询的字段越多结果集也就越大占用的内存也会越大所存储的其他数据也就越少当其他SQL操作时在内存中找不到数据又会去触发磁盘IO最终导致MySQL整体性能下降 尽量将大事物拆分成小事物 当事物较大且包含写事物时会导致一部分数据长时间锁定从而可能引起大量事物出现阻塞大事务也会导致日志写入时出现阻塞这种情况下会强制触发刷盘机制大事务的日志需要阻塞到有足够的空间时才能继续写入日志到缓冲区这也可能会引起线上出现阻塞可通过show status like innodb_log_waits;查看是否有大事务由于redo_log_buffer不足而在等待写入日志。 尽量避免深分页的情况select * from test limit 100000,10在MySQL的实际执行过程中首先会查询出100010条数据然后丢弃掉前面的10W条数据将最后的10条数据返回 解决办法基于递增连续字段 -- 第一页
select * from test where 有序字段 1 limit 10;
-- 第二页
select * from test where 有序字段 11 limit 10;避免循环调用sql新增和更新最好采用批量操作查询可以先将所需数据查询出来建立映射关系
多表连接查询 避免三表以上的连表查询且要以小表驱动大表原因是连表查询的数据量是各表数据的笛卡尔积会随着表数据增加累乘增加 关联算法MySQL8.0之前的关联算法为Nest Loop Join嵌套循环连接算法该算法会依照驱动表的结果集作为循环基础数据然后通过该结果集中一条条数据作为过滤条件去下一个表中查询数据最后合并结果得到最终数据集 优化器的选择逻辑如果指定了连接条件满足查询条件的小数据表作为驱动表。如果未指定连接条件数据总行数少的表作为驱动表。 优化器不一定能够正确选择最好在编写sql时考虑好假设有a1000条数据、b10条数据两张表select * from a as t1 left join b as t2 on t1.id t2.id;会循环1000次查询数据而select * from b as t1 left join a as t2 on t1.id t2.id;只需要循环十次 // 伪逻辑
for(数据 x : 驱动表){for(数据 y : 被驱动表){if (x y){// 如果符合连接条件则记录到连接查询的结果集中.....}}
}哈希连接(Hash Join) Mysql8.0新增对连表时存在等值连接条件且未命中索引的情况下的连接查询优化 // 伪代码
// 构建阶段将小表的每行数据根据哈希值放入内存哈希表中
Map hashTable new HashMap();
for(数据 x : 构建表){hashTable.put(x);
}// 探测阶段遍历大表的每行数据与内存哈希表做连接匹配
for(数据 y : 探测表){if (hashTable.get(y) ! null){// 如果哈希处理后能够在内存哈希表中存在// 则表示这条数据符合连接条件则记录到连接查询的结果集中.....}
}分为两个阶段 构建阶段选择一张小表为构建表然后基于连接字段做哈希处理接着将生成的哈希值放入内存中构建出一张哈希表探测阶段遍历大表的每一行数据然后对连接字段做哈希处理通过生成的哈希值与内存哈希表做比较将符合条件的数据放入结果集 相对于嵌套循环性能的提升 对于大表只需要遍历一次而嵌套循环需要遍历N次在探测阶段时只需要先对数据做一次哈希处理复杂度为O(1) 而循环连接为O(n) 存在的问题 内存中的join_buffer_size的大小可能无法完全载入哈希表解决办法 分批处理在构建阶段将构建表的数据进行拆分在探测阶段每次载入一部分到内存中这样会导致遍历次数增多磁盘内存混合处理将内存中放不下的数据放入磁盘在探测阶段遍历大表判断时从磁盘依次读入处理好的哈希值进行判断 Mysql采用的是磁盘内存混合处理的方式 使用限制 仅支持内连接的多表连接查询必须要去等值连接查询条件连接字段可走索引的情况下默认依旧会采用循环连接算法 默认开启可通过set optimizer_switchhash_joinoff;命令控制 反连接(Anti Join) Mysql8.0新增对与一些反范围查询操作的优化 优化场景 NOT IN (SELECT … FROM …)NOT EXISTS (SELECT … FROM …)IN (SELECT … FROM …) IS NOT TRUEEXISTS (SELECT … FROM …) IS NOT TRUEIN (SELECT … FROM …) IS FALSEEXISTS (SELECT … FROM …) IS FALSE
Mysql结构优化
表结构优化字段数量不能过多、主键最好自增、根据业务建立中间表等字段结构优化在保证足够使用的范围内选择最小数据类型尽量避免NULL值等索引结构优化参考之前的索引使用
整体架构优化
引入缓存中间件解决读压力 优点在设置合理的情况下可以为Mysql分担70%以上的读压力缺点系统变复杂需要考虑缓存击穿、缓存穿透、缓存雪崩、数据一致性等问题 引入消息中间件解决写压力 优点利用了MQ流量削峰的能力使请求平滑的到达数据库缺点数据库数据存在一定的延时 主从读写分离适用于读多写少业务提高mysql自身抗压能力 优点通过搭建集群提高了mysql的抗压能力缺点主节点和从节点之间存在数据不一致的情况 双主双写热备适用于写多读少的情况 需要考虑自增ID问题 分库分表规避存储容量的上限木桶效应
