架构师
公众号文集
12个想法
论代码级性能优化变迁之路(二)
>> 5、缓存优化方案
针对配置信息和变动不大的信息可以放到缓存中，提高并发能力也能够降低IO缓存，具体缓存优化策略可以参考我之前写的：
>> 所谓容错是指在故障存在的情况下计算机系统不失效，仍然能够正常工作的特性。
>> 通过引入了MQ队列，使每台应用服务器的Ehcache同步侦听MQ消息，这样在一定程度上可以达到准同步更新数据，通过MQ推送或者拉取的方式，但是因为不同服务器之间的网络速度的原因，所以也不能完全达到强一致性。基于此原理使用Zookeeper等分布式协调通知组件也是如此。
>> 8、因基础平台组件功能不完善导致性能下降
>> 首先我们先不说这段代码的格式如何如何，先看功能实现，使用Future来做超时控制，这是为何呢？原因其实是在我们调用的Dubbo接口上面，因为是Dubbo已经经过二次封装，结果把自带的timeout给淹沫了，程序员只能通过这种方式来控制超时，可以看到这种用法非常差劲，对程序性能造成一定的影响。
>> 10、关于索引的优化
组合索引的原则是偏左原则，所以在使用的时候需要多加注意
索引的数量不需要过多的添加，在添加的时候要考虑聚集索引和辅助索引，这二者的性能是有区别的
索引不会包含有NULL值的列
只要列中包含有NULL值都将
>> 我们拆分长耗时方法的一般技巧是：
寻找业务的冗余点，代码中有很多重复性的代码，可以适当简化。
检查库表索引是否合理加入。
利用单元测试或者压力测试长耗时的操作进行算法级别优化，比如从库中大批量读取数据，或者长时间循环操作，或者死循环操作等等。
寻找业务的拆分点，根据业务需求拆分同步操作为异步，比如可以使用消息队列或者多线程异步化。
论代码级性能优化变迁之路(一)
>> 11、没有故障降级策略，项目出了问题后解决的时间较长，或者直接粗暴的回滚项目，但是不一定能解决问题。
12、没有合适的监控系统，不能准实时或者提前发现项目瓶颈。
>> 针对以上问题完全没有必要使用悲观锁的方式来进行防重，不仅对数据库本身造成极大的压力，同时也会把对于项目扩展性来说也是很大的扩展瓶颈，我们采用了三种方法来解决以上问题：
使用Redis来做分布式锁，Redis采用多个来进行分片，其中一个Redis挂了也没关系，重新争抢就可以了。
使用主键防重方法，在方法的入口处使用防重表，能够拦截所有重复的订单，当重复插入时数据库会报一个重复错，程序直接返回。
使用版本号的机制来防重。
以上三种方式都必须要有过期时间，当锁定某一资源超时的时候，能够释放资源让竞争重新开始。
>> 那么我们在用事务的时候，遵循的原则是快进快出，事务代码要尽量小。针对以上伪代码，我们要用httpClient这一行拆分出来，避免同事务性的代码混在一起，这不是一个好习惯。
>> 在并发的情况下，无限制的申请线程资源造成性能严重下降，在图表中显抛物线形状的元凶就是它！！！那么采用这种方式最大可以产生多少个线程呢？？答案是：Integer的最大值！
>> 注：因为服务器的CPU只有4核，有的服务器甚至只有2核，所以在应用程序中大量使用线程的话，反而会造成性能影响，针对这样的问题，我们将所有异步任务全部拆出应用项目，以任务的方式发送到专门的任务处理器处理，处理完成回调应用程序器。后端定时任务会定时扫描任务表，定时将超时未处理的异步任务再次发送到任务处理器进行处理。
