memcache失效导致db crash的解决方案

在高并发下，很容易出现memcache失效导致短时间内造成大量的DB IO，如果语句耗时少大，极有可能导致数据库崩溃，严重影响业务。

最近实现一个搜索功能，需要统计热搜词。设计思路是将用户搜索词入库，然后用sql统计出搜索频次高的词，经过敏感词过滤后得到最终的热词。后面统计闲时一分钟大概有200多次搜索，一天下来搜索量也不少，日积月累数据库会非常大，所以后来又写了定时清理旧数据的脚本。

在统计热词的过程中，由于sql语句用到了sum()和group by sum，导致单条sql查询速度最短1.5秒左右，完全无法接受。考虑到热词并非实时，所以加入了缓存机制。用户搜索时先从缓存拉数据，如果没有再读库。那么问题来了，这个sql执行需要1秒，1秒内有多次搜索，那db的压力巨大，事实情况也证明，这么写的确把数据库搞死了。。。

解决的方法有很多，这里用到的是crontab定时写缓存，比如每60分钟拉一次缓存，缓存失效时间是70分钟，这样缓存和php的业务逻辑是独立的，不会存在短时间内多次搜索导致缓存失效时大量DB IO导致数据库崩溃的问题。

此外还可以做双层缓存，即一次读DB缓存两份，B缓存失效时间比A长，业务先从A度，没有再从B读，此时B里肯定是有数据的，同时要调起DB更新A、B缓存的数据。但我感觉这样做显得有点太麻烦。

还有一种方法是设计思路的改变，热词统计的做法也有很多，可以考虑将用户搜索存入mc，相同的词计数+1，大于阀值再入库，这样保证入库的都是热词，且数量不会太多。但这是纯热词的做法。假如后期做产品分析的时候，想统计出用户搜索了但我们没有实现的内容，用于改善产品体验的时候，就会因为数据量太少，无法做出可靠分析。毕竟无法预知产品会在什么时候提出什么别致的需求，所以即使有些点产品没有要求的，我们在程序设计的时候尽量能提前埋好的就埋上，免得以后还要挖坑，不要写死。