记录使用ecshop宕机并恢复的整个过程，看看ecshop这个垃圾的缺陷

背景介绍：

2017年9月，公司安排我们研发部搞一个中秋礼品抢购的功能，参与抢购的同事六七千名，我通知其他同事要搞下压力测试，然而功能急急忙忙上线，埋下了宕机的隐患，这是一次血的教训，当然也是一次宝贵的经验。

整个过程：

早上7点，起床打开手机，企业微信就有同事发来消息说网站访问缓慢，我并未在意，觉得是同事的网络有问题；

早上8点多在公交上，突然发现群里反馈信息的人越来越多，我赶紧打开手机，网站已经没了响应，直接报错，我打开电脑，连上手机4g，发现已经连不上阿里云服务器，服务器已经宕机或者过载状态中。（抢购活动9点才开始，同事在上班路上纷纷打开手机访问抢购页面，服务器被挤爆宕机，fpm-php线程数设置的是动态加载，已连接的线程未释放，cpu负载过高，总结应该是这个问题）

早上9点多到了公司后，抢购时间已经开始了，页面又打不开，集体领导各种电话打到办公室催促，运维同事重启了阿里云，然而重启过后一会，网站又立刻变卡，php线程数又暴增，运维只能不停的重启fpm-php与mysql

早上9点半多重启fpm-php一会，页面就会报memcache连接数过多的问题，赶紧让运维将memcache连接数设置到2000（实际上来说是有慢查询，memcache连接不能及时释放），然后设置到2000后，memcahche的问题没有再报，但访问还是异常卡

早上快10点时，通过mysql慢日志与php慢日志发现抢购页面入口那里有异常耗时的查询，紧急将相关功能临时注释（实际上是前几天上线的功能，开发人员未进行缓存处理），同时相关表由myisam 改为innodb （ecshop表都是myisam引擎，update操作锁表，访问量多起来响应耗时，mysql与php连接会不能及时响应，越来越多拖垮服务器），处理完后，页面访问速度已经明显好转，但仍然不是很流畅

早上10点多时，陆续有人发来shop_config.php的报错，紧急查看代码后发现，代码中对shop_config.php进行频繁的读删操作，当用户访问量多时，就会存在读不到文件的情况，连忙把shop_config.php的更新逻辑注释，然后网站访问就变得流畅起来。

总结：

整个异常排查处理历时大约一个半小时，总结起来就是不能慌，要一步一步排查问题。

总结一下以下几点要注意：

1、ecshop里对shop_config.php的频繁读删要优化

2、ecshop的部分表存储引擎要改为innodb (goods,order,users等)

3、nginx，php，mysql连接要设置合理超时时间，避免线程无限增长拖垮服务器

4、搞活动之前压力测试要做到位

5、出现问题别慌，需要更加细心