我们的售货机系统是每天有几个时间段请求会成倍的增加。像每天中午11点-12点半。晚上的5点半到6点还有晚上21点到24点。
 这几个时间段的订单量是比较大的。

 我们第一次碰到的问题是机器代理商反馈有客户购买了，但是出货很慢。并且还发现了系统出现了大量的订单退款。我们开始从日志方面看，发现了好像系统的处理速度变慢了。并且这些退款的订单都是出货了的。这样的话，系统就亏大了。并且随着高峰的到来，系统开始报mysql的连接数用完了。导致数据库写入和更新操作都没法做。我们立刻把生产系统停掉。老板也是致电我们，搞不好就滚蛋。然后我们连夜对机器下单这块的业务做优化, 减少访问mysql的压力。并且把消息处理类中用到的连接池的大小给扩大一倍。
 就这样消停了几天。

但是由于系统内设备不断增加，隔了大概一周左右，晚上10点左右又来投诉说这个问题，我们犹如惊弓之鸟，立马打开日志查看。还是这个问题。

而且以前忽略了微信的支付回调如果处理不及时，微信会向回调地址重复发送订单结果的通知。这个是导致系统崩盘的重要的点之一。

关键这次发现了最重要的问题：系统在处理终端设备订单的微信支付宝的回调在做异步处理的时候，由于回调部分没有做并发处理。
导致数据库的表被锁住，引发的回调部分业务要处理堆积，系统处理不过来。恶性循环，消息越多，越处理不过来。越处理不过来，支付回调部分越堆积。导致我们的机器又出货，又退款。

最终我们花了一夜时间把微信支付回调做了多线程处理。系统才稳定了下来。

第二天把支付宝的回调处理部分也做了多线程处理。一段时间内没有问题。

现在系统加了redis做缓存。但是缓存刚上线也是有不少问题的。但是我们慢慢解决了。

目前的系统算是比较稳定了。

阿里云的双核4G服务器 支撑我们系统的600多台设备。

老师文章中提到的方案对我们后面工作不论是在这个公司，还是以后都是有很大启发的。