性能优化之路(一).docxVIP

功能优化之路(一) 2021-04-14 一、前言 ????????我们以前看到的很多架构变迁或者演进方面的文章大多都是针对架构方面的引见，很少有针对代码级别的功能优化引见，这就好比盖楼一样，楼房的基础架子搭的很好，但是盖房的工人不够专业，有很多需要留意的地方忽视了，那么在往里面填砖加瓦的时候出了问题，后果就是房子经常漏雨，墙上有裂缝等各种问题消灭，虽然不至于楼房塌陷，但楼房也已经变成了危楼。那么今日我们就将针对一些代码细节方面的东西进行引见，欢迎大家吐槽以及提建议。 二、服务器环境? 服务器配置：4核CPU 8G内存 共4台?MQ：RabbitMQ?数据库：DB2?SOA框架：公司内部封装的Dubbo?缓存框架：Redis，Memcached?统一配置管理系统：公司内部开发的系统 三、问题描述 1、单台40TPS，加到4台服务器能到60TPS，扩展性几乎没有。?2、在实际生产环境中，经常消灭数据库死锁导致整个服务中缀不行用。?3、数据库事务乱用，导致事务占用时间太长。?4、在实际生产环境中，服务器经常消灭内存溢出和CPU时间被占满。?5、程序开发的过程中，考虑不全面，容错很差，经常由于一个小bug而导致服务不行用。?6、程序中没有打印关键日志，或者打印了日志，信息却是无用信息没有任何参考价值。?7、配相信息和变动不大的信息照旧会从数据库中频繁读取，导致数据库IO很大。?8、项目拆分不彻底，一个tomcat中会布署多个项目WAR包。?9、由于基础平台的bug，或者功能缺陷导致程序可用性降低。?10、程序接口中没有限流策略，导致很多vip商户直接拿我们的生产环境进行压测，直接影响真正的服务可用性。?11、没有毛病降级策略，项目出了问题后处理的时间较长，或者直接粗暴的回滚项目，但是不肯定能处理问题。?12、没有合适的监控系统，不能准实时或者提前发觉项目瓶颈。 四、优化处理方案 1、数据库死锁优化处理?我们从其次条开头分析，先看一个基本例子呈现数据库死锁的发生：? 在上述事例中，会话B会抛出死锁特别，死锁的缘由就是A和B二个会话相互等待。 分析：消灭这种问题就是我们在项目中混杂了大量的事务+for update语句，针对数据库锁来说有下面三种基本锁：? 当for update语句和gap lock和next-key lock锁相混合使用，又没有留意用法的时候，就格外简约消灭死锁的情况。 那我们用大量的锁的目的是什么，经过业务分析发觉，其实就是为了防重，同一时辰有可能会有多笔领取单发到相应系统中，而防重措施是通过在某条记录上加锁的方式来进行。 针对以上问题完全没有必要使用悲观锁的方式来进行防重，不只对数据库本身形成极大的压力，同时也会把对于项目扩展性来说也是很大的扩展瓶颈，我们接受了三种方法来处理以上问题：?* 使用Redis来做分布式锁，Redis接受多个来进行分片，其中一个Redis挂了也没关系，重新争抢就可以了。 使用主键防重方法，在方法的入口处使用防重表，能够拦截全部反复的订单，当反复插入时数据库会报一个反复错，程序直接前往。 使用版本号的机制来防重。?以上三种方式都必需要有过期时间，当锁定某一资源超时的时候，能够释放资源让竞争重新开头。 2、数据库事务占用时间过长?伪代码示例： public void test() { ? ?Transaction.begin ?//事务开启 ? ?try { ? ? ? ?dao.insert //插入一行记录 ? ? ? ?httpClient.queryRemoteResult() ?//恳求访问 ? ? ? ?dao.update //更新一行记录 ? ? ? ?Tmit() ?//事务提交 ? ?} catch(Exception e) { ? ? ? ? ?Transaction.rollFor //事务回滚 ? ?} } 项目中类似这样的程序有很多，经常把类似httpClient，或者有可能会形成长时间超时的操作混在事务代码中，不只会形成事务执行时间超长，而且也会严峻降低并发力量。 那么我们在用事务的时候，遵照的准绳是快进快出，事务代码要尽量小。针对以上伪代码，我们要用httpClient这一行拆分出来，避开同事务性的代码混在一起，这不是一个好习惯。 3、CPU时间被占满分析?下面以我之前分析的一个案例作为问题的起始点，首先看下面的图：? 项目在压测的过程中，cpu一直居高不下，那么通过分析得出如下分析： 数据库连接池影响 我们针对线上的环境进行模仿，尽量真实的在测试环境中再现，接受数据库连接池为我们默认的C3P0。 那么当压测到二万批，100个用户同时访问的时候，并发量突然降为零！报错如下：?