最近，为应对日益增长的业务要求，一直忙于进行系统优化。前几天，系统终于上线，正式开始运行了，我这才有时间来总结一下。
背景
我负责的这个系统是公司的收银系统，公司所有需要进行支付的业务都会接入这个系统。由于历史原因，之前的收银系统一直和其他的业务部署在同一台机器上，这就导致业务系统和收银系统经常出现相互影响的情况。比如之前有一次，一个业务做活动，订单量暴增，大量支付请求发送到收银系统，一时间收银系统所在机器CPU使用率上升到90%多，结果导致同台机器上的其他业务也无法正常使用了，最后不得以只能通过扩容才暂时解决了这个问题。
优化
1、迁移收银台，独立部署
虽然，上面我们通过扩容暂时解决了问题，但治标不治本，而且还浪费资源，因为订单暴增，CPU使用率突然上升的根本是因为收银系统要处理的请求突然增加。因此，要彻底解决这个问题，我们需要迁移收银系统，要将其与业务系统分开，独立部署。
2、数据库使用多实例
我们将收银系统与业务系统分开独立部署后，收银系统和业务系统不再相互干扰了，但是我们运行了一段时间后，又发现新的收银系统面临了一个新的问题——系统QPS太低。通过压测发现，在数据库单实例的情况下，即使增加WEB机器，最大的QPS也只能达到3443/s，能处理的订单数最多也只有860单/s，这对于业务2000单/s的要求显然是无法满足的。
为解决这个问题，我们选择使用MySQL多实例，我们想通过提升MySQL的QPS，来提升收银系统处理订单的能力。我们从2个实例开始，先后测试了在相同数量的WEB机器下4个、6个、8个、10个、12个MySQL实例的性能情况。通过对比发现，在刚开始，随着MySQL实例的增加收银系统处理订单的能力在不断增加，当MySQL实例数量为6的时候，订单处理量超过2000/s；当MySQL实例数量为10的时候，性能达到最佳。
基于上面的测试结果以及业务的要求，为充分利用资源，我们最后采用自动扩容的方案，即默认设置6个实例
- 当CPU连续超过70%，每6分钟（2m+2m+2m=6m）左右会逐步触发扩容加机器，当加到最大实例数（10台）就不会再扩容了。
- 当CPU连续低于50%，每6分钟（2m+2m+2m=6m）左右会逐步触发扩容减机器，当减到最小实例数（6台）就不会再回收了。
通过上面一系列操作，最后收银系统终于完成了将QPS从300提升到6000的目标。