作者:焦振清
时间:2017-11-24
这次分享的一个case是各家公司都会出现的问题,依然,在问题初期,没有得到足够的重视,直至这个问题的严重性被提升到一定程度后,大家开始救火,蜂拥向前。我总在想,早知如此,何必当初呢。
问题的起因是一个查询功能没有被进行请求频率限制,如果用户发起的查询操作次数太多的话,会导致数据库CPU使用率飙升,进而影响到这个系统的所有用户(我们不讨论为什么查询请求一定要走数据库)。
接下来,墨菲同学要出场了:
第一次:2017-07-12,用户反馈系统功能异常缓慢,经过定位发现,是因为A用户的查询频率较高以及B用户的一些其他操作一起影响了(注意,这个时候,有根本原因,也有一些噪音,因此大家的重视程度并不高,略带侥幸心理)
第二次:2017-07-19,用户反馈系统功能异常缓慢,经过定位发现,是因为A用户的查询频率较高导致的,因为A用户觉得之前的操作没问题,所以查询压力继续翻倍,因此这次,没有噪音,直接一个人把服务干瘫痪了(注意,我们不讨论说如何优化,是否需要隔离,是否需要加访问频率控制这类防攻击功能,降级等等,我们只聊墨菲同学)
因为对服务的影响较大,因此第二次就引起了重视,大家紧急修复,添加了访问频率控制,读写分离,读请求缓存等措施,从而从根本上杜绝了这类事情再次发生的可能性,事实上,从这之后,再也没有发生过类似问题。
但是,回头我们也需要想想,本来,这个问题,在第一次发生的时候,只要添加一下访问频率控制就完全可以解决问题,何苦非要等第二次问题严重了,才投入这么多人力做优化呢,既然早晚都要做,且早做的成本低,影响小,何苦呢,哎,一身叹息!