凡事都在事上磨,这样才能精进,成长进步提高! ------ 博客园首页

分布式系统性能注意点

• Top1

循环sql(批量查询,批量新增,批量修改)、redis(合理数据类型和使用管道)、dubbo、http请求等操作。

解析:以循环dubbo调用为例,dubbo调用需要走局域网络发送数据,唤起目标服务的dubbo线程,占用数据库连接,最后接收数据这一漫长的过程。如果循环多次调用,会有巨大的性能开销。根据前面优化的经验,如:调用主数据请求100条商品信息优化成批量后,性能将会有90%以上的提升。如果你代码中没有top1案例的情况,那么恭喜你,你避免了60%以上的性能问题。

• Top2

sql查询时,控制返回字段和返回记录数

解析:目前erp很多数据库表有超过60个的字段,如果一个sql 全字段查询几百甚至上千条记录。这会占用大量的io 和 内存,甚至触发GC,导致cpu过高导致宕机。之前有过 全字段查询两千多条记录而宕机的记录。当然也有没有判断查询条件,导致查询全表数据而宕机的记录。还有哥们查询一个几千记录的list,只是为了判断一下size是否为零。 [○・`Д´・ ○]

• Top3

合理使用线程池,尽量用消息队列代替

解析:首先要说的是要用好多线程很难。使用多线程就是为了充分利用cpu的资源,提高程序执行效率。就是说,整个任务的执行时长会变短,但当执行时的cpu使用率会增高,如果核心线程数配置过大,甚至会导致cpu耗尽宕机。又或者执行多线程任务时,cpu维持在70~80%,这个时候又来了一个请求,并且存在top1,top2所描述的问题,那也能把这台机器怼挂。二代ERP是一个分布式系统,应该要充分利用集群的优势。如果有一个大任务要执行,尽量用mq拆分成小任务执行,避免单机cpu过高。

这里聊聊为什么要用mq代替多线程。前面库存模块有个记账业务,使用的是多线程执行。业务量比较大,每天有几十万的记账业务需要执行。库存把记账任务通过dubbo调用分发到不同中台的线程池异步执行。但是会存在分布不均,有的机器上分配了几万笔记账,有的则只有几百。当分配多的时候,任务需要放入堵塞队列等待执行,堵塞队列过大也会占用内存。当机器重启时,正在执行和在堵塞队列的任务还会丢失。而mq分配基本达到了绝对均匀,而有高可用保证消息不丢失的机制。如:某些业务想要用多线程,请联系我和组长讨论。

注:1.分发任务的线程池核心数,不能大于中台机器数x2; 2.执行任务线程池线程池核心数不能大于2;3.mq消费线程数,日消息大于10w的业务设置为2,其他都设置为1;

• Top4

慢sql

解析:数据库使用规范

• Top5

算法

解析:这个只是提一下,一般业务也不会用到什么算法。顶多是用个遍历什么的,不要多使用多层遍历就行了,不然时间复杂度太高,消耗性能。

• 如果你掌握了以上几个案例,那你基本解决了咱项目的95%以上的性能问题。看上去也并不难吧,现在就着手动起来吧,排查一个坑,便少一个坑,少一份事故风险。

因为相信,所以看见.
posted @ 2020-03-16 11:04  zeenzhou  阅读(196)  评论(0编辑  收藏  举报