系统性能优化解决方案.pdfVIP

系统性能优化解决方案 1 环境背景： 1. 单台 40TPS ，加到 4 台服务器能到 60TPS ，扩展性几乎没有。 2. 在实际生产环境中，经常出现数据库死锁导致整个服务中断不可用。 3. 数据库事务乱用，导致事务占用时间太长。 4. 在实际生产环境中，服务器经常出现内存溢出和 CPU 时间被占满。 5. 程序开发的过程中，考虑不全面，容错很差，经常因为一个小 bug 而导致服务不可用。 6. 程序中没有打印关键日志，或者打印了日志，信息却是无用信息没有任何参考价值。 7. 配置信息和变动不大的信息依然会从数据库中频繁读取，导致数据库 IO 很大。 8. 项目拆分不彻底，一个 tomcat 中会布署多个项目 WAR 包。 9. 因为基础平台的 bug ，或者功能缺陷导致程序可用性降低。 10. 程序接口中没有限流策略，导致很多 vip 商户直接拿我们的生产环境进行压测，直接影响真 正的服务可用性。 11. 没有故障降级策略， 项目出了问题后解决的时间较长， 或者直接粗暴的回滚项目， 但是不一定 能解决问题。 12. 没有合适的监控系统，不能准实时或者提前发现项目瓶颈。 优化解决方案 缓存优化方案 针对配置信息和变动不大的信息可以放到缓存中，提高并发能力也能够降低 IO 缓存。 程序容错优化方案 在这一块我要先举一个程序的例子说明一下什么才是容错，先看程序： 2 注： 那么如果 service 层的方法调用 dao 层的方法， 一旦数据插入失败， 那么这种异常处理的方式是容 错吗？ 把异常给吃掉了，在 service 层调用的时候，虽然没有打印报错信息，但是这能是容错吗？ 所谓容错是指在故障存在的情况下计算机系统不失效，仍然能够正常工作的特性 。 我们拿使用缓存来作为一个案例讲解，先看一个图： 这是一个最简单的图，应用服务定期从 redis 中获取配置信息，可能会有朋友认为这样已经很稳定 了，但是如果 Redis 出现问题呢？可能会有朋友说， Redis 会是集群，分片或者主从，确保不会出 现问题。其实我是这样的认为的，虽然应用服务程序尽量的保持轻量级是不错的，但是不能因此而把 3 希望全部寄托在中间组件上面，换句话说，如果此时的 Redis 是单点，那么后果会是什么样的，那 么随着大量的并发请求到来的时候，程序中会报大量的错误，同时正常的流程也不能进行下去了业务 也可能由此而中断。 那么在此种场景下我的解决方案是，要把缓存的使用分级别，有的缓存同步要求时效性非常高，比如 支付限额配置，在后台修改完成以后前台立刻就能够获得感知，并且能够成功切换，这种情况只能实 时的从 Redis 中获取最新数据，但是每次获取完最新的数据后都可以同步更新本地缓存，当单点的 Redis 挂掉后， 应用程序至少还能从本地读取信息而不至于服务瞬间挂掉。 有的缓存对时效性要求不 高，允许有一定延迟，那么在这种情况下我采用的方案是，利用本地缓存和远程缓存相结合的方式， 如下图所示： 方案一： 4 这种方式通过应用服务器的 Ehcache 定时轮询 Redis 缓存服务器更同步更新本地缓存，缺点是因 为每台服务器定