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