常见性能优化策略的总结( 三 )


多线程和分布式
场景
离线任务、异步任务、大数据任务、长时间任务**的运行,如果使用得当,可以达到加速的效果 。
注意:在线响应时间高的时候,尽量少用多线程,尤其是服务线程需要等待任务线程的时候(很多重大事故都与此息息相关) 。如果一定要使用,可以给线程设置一个最大等待时间 。
常见做法
如果单机的处理能力能够满足实际业务的需要,那么尽量使用单机多线程的处理方式,降低复杂度;否则,需要使用多机多线程的方式 。
对于单机多线程,可以引入线程池的机制,它有两个作用:
如果单机处理能力不能满足要求,此时应采用多机多线程的方式 。这个时候需要一些分布式系统的知识 。首先,必须引入一个单独的节点作为调度器,其他机器节点作为执行器节点 。调度器负责拆分任务,将任务分发到合适的执行器节点;执行器节点以多线程方式(可能是单线程)执行任务 。这时候,我们整个任务系统已经从一键式进化为集群系统,不同的机器节点扮演着不同的角色,各司其职,相互交互 。这时,除了多线程、线程池等机制外,RPC、心跳等网络通信调用等机制也必不可少 。后续我会想出一个简单的分布式调度框架 。
测量系统(监控、警报、服务依赖管理)
测量系统严格来说不属于性能优化的范畴,但这方面与性能优化息息相关,可以说为性能优化提供了强有力的数据参考和支持 。没有衡量系统,基本上无法定位系统的问题,也无法有效衡量优化的效果 。很多人不关注这方面,但我认为这是系统稳定性和性能保障的基石 。
关键流程
如果要设计系统,一般需要设计哪些关键流程?
①确定指标
②收集数据
③ 计算数据并存储结果
④ 演示与分析
需要监控和提醒哪些指标?需要注意哪些?
根据需要,主要需要两个指标:
接口性能是相关的,包括单个接口和所有的QPS、响应时间、调用量(统计时间维度越详细越好;最好可以从节点或者服务集群的角度来查看相关数据) 。它还涉及服务依赖关系的管理 。这时候就需要对单机节点使用服务依赖管理系统,包括CPU使用率、Load值、内存使用率、网卡流量等 。如果节点是一些特殊类型的服务(如 MySQL、Redis、Tair),还可以监控这些服务特有的一些关键指标 。
数据收集方法
通常采用异步上报的方式 。具体方法有两种:第一种是发送到本地Flume端口,Flume进程收集远程集群或Storm集群进行操作;第二种方法是直接在本地执行操作后,使用异步和本地队列发送到监控服务器 。
数据计算
可以使用离线计算(/Hive)或实时/准实时计算(Storm/Spark),计算结果可以存储在MySQL或HBase中;在某些情况下,可以直接采集并发送到监控服务器,无需计算 。.
显示和分析
提供统一的展示和分析平台,需要有报表(列表/图表)的监控和报警功能 。
真实案例研究
案例一:业务与控制区域关系刷新工作
背景
这是一个每小时定期运行的作业,用于刷新商家与控制区域之间的关系 。具体规则是根据商户的分布范围(多个)与控制区域是否有交集 。如果有路口,则将商户置于此控制区域范围内 。
业务需求
此过程需要尽可能短,最好在 20 分钟内 。
优化过程
原代码的主要处理流程为:
获取所有商店的送货区域和控制区域的列表 。遍历控制区域列表,针对每个控制区域:
一个 。遍历商家的配送范围列表,找到与该控制区域相交的配送范围列表 。