梦萦国庆
2016年的国庆节，部门业务出现离奇的SQL：
每天，当人们从睡梦中醒来又再一次进入梦乡时，短短的12小时，数据库查询次数高达千万。
当时，部门订单量不破1000，何来千万级别的select？
经过一个时辰的调查走访，邱永臣发现了幕后黑手，它不是代码，不是BUG，而是公司内部的订单中心。
原来，在APP改版后，为了适应PM的需求，在用户切换到『我的』tab的瞬间，订单中心便是耗费巨大的时间和资源，轮询全公司上下20个业务部门的服务，调查该用户在各部门的订单，进而计算出总订单数量。
此案怎破？
手段一
向订单中心反馈，要求改『订单中心轮询』为『业务主动推送』。对方果断拒绝，原因：涉众过多，一时半会无法更改。细想之下，也是，似乎有点道理。
手段二
部门内全部放开RPC，只拦截SQL。压力从SQL身上挪开，转到何方？我们想到了KV缓存。部门内的用户挪移至KV缓存，订单中心的轮询到达时，首先让缓存承压，若该用户真属于我部门，放行SQL，从数据库中拿订单信息，不然，别怪我们心狠，拦截该SQL。
做了优化后，SQL从每天的2500W将至50W，而缓存则由0暴增至6000W。
完美结局
从此，凭借巅峰时期QPS承受30W的KV，无论那订单中心再请求，数据库也不会受丝毫影响。