优化啊优化1

2015-09-21 刚入职一家新公司，从一家规模稍小的公司过来，个人的第三段创业历程，刚好和前两次拼接起来，就是一个公司从开始到C轮的全过程（前两次都马马虎虎，到底有多马虎？）。对这次还是旅程还是很期待的。

创业是个很不规律的过程，一切都是指数性的增长，在任何一个点都很难预测之后的情况。就像有经验的PV会告诉你，这几件事搞定了，之后的局面会怎么样。当真的趟过去以后才发现他娘的之前的设想简直就是个金锄头的笑话。

这一点在业务量上边就可以提现出来。前些天数据库CPU还非常平稳，突然激增到50%左右，再不采取行动的后果就是客户跑来骂娘。第一次加缓存就是这个背景下搞得。这一次是在15年5月份，我还没有参与。奇哥带着山鸡哥小赛研究了几天终于差不过搞出一个缓存的方案。缓存选用了redis，实现细节上是利用了redis内置的union方法来将几个集合取交集，最终将符合条件的信息筛出来。

起初设计这个方案的时候，大家都觉得问题不大，毕竟是redis内置的策略，能慢到哪去呢？
“再缓缓，测稳了再上”，奇哥皱了皱眉，观察数据库CPU的情况。
就这么测了几天，业务的上涨终于让DB快扛不住了，每天查询速度超慢。客服压力巨大。
“测得怎么样，今天上吧”，奇哥叹了口气。于是当晚就部署上线，一切顺利。大家早回家。

“您好，您是XX的人吗？”早上6点，一个司机打电话给行政马姐，马姐揉了揉眼，“是的，您好”，“你确定吗？”那人问“是的，我是XX公司的”，马姐不解的回答“xxx，xx配不上货了”。。。（这个故事马姐经常讲给我们听，又是无奈又是喜悦。）

马姐赶紧给奇哥打电话，其他几个人也迅速就位。搜索页面长期无响应，仔细分析了一下，奇哥恍然大悟，所谓的原生union操作，就是两层循环嵌套，时间复杂度为m*n。我们有那么多信息，搞起来redis肯定扛不住。
讨论了半天，最后临时通过了一个可用的办法，根据不同的搜索条件冗余多个集合，把符合条件的信息往每个集合里都放一份，这样查询的时候就可以直接从集合里边搜索。
一切就绪，开始行动，连续三天两夜，终于大致完工，早上六点，紧急上线。坚持到10点钟，波峰已过，算是扛下来了。大家终于满意的回去睡觉。

以上内容本人并没有亲身经历，只是来了之后听奇哥说起，心潮澎湃。总结下来，大概有这些经验：key-value缓存这样的东西，最好只使用它的get方法，那些花哨的集合运算并不实用。其实在mysql里边也是一样，不要让数据库本身去参与过多的运算。总结下来，对于存储工具，只有IO才是最合理的瓶颈。