大促稳定性建设

最近做了一些技改，由于本次618大促我作为稳定性负责人，梳理了大量系统稳定性相关的功能，平时疲于业务的迭代很多系统性的问题在大促前才梳理出来，本问也沉淀一下关于稳定性这块自己的心得。

订单量的增加可能导致一些并发的问题，这块需要做好并发的控制，单机可以使用JUC提供的锁控制，现在集群一般采取redis等高可用的分布式缓存去做分布式锁，但是一般采取DB做分布式锁可靠性更高。
DB的优化也是重中之重，本次大促出现一个问题也是因为未被识别慢SQL导致。
应用负载，需要考虑GC的情况，大促期间会不会频繁GC或则生成大对象，这个需要平时的代码规范，大促前的全链路压测也能够提前暴露。
磁盘需要看是否有大日志，IO性能如何。

大促不同于同时的运营，需要考虑的事情也要从一切保证当天运行的稳定性。甚至提前半个月就要进行封网措施保证系统不引入新的问题，能够尽早发现线上bug。大促前只允许稳定性相关的需求进行发布，产品需求封版。

稳定性的准备主要也需要考虑这些部分。

• DB
  一般早期的应用都是单库，各种功能与多个应用都直连一个DB，这样不可避免的导致一些非核心业务给DB造成巨大的压力，导致核心链路受到影响，这个时候一般是采取读写分离的思想，把非核心流量打到备库，主库只做核心查询与写入操作，可