电商转化率低？90%用户行为数据在缓存里沉睡

　　去年十一那阵子，运维小王半夜给我发消息，说缓存集群的监控曲线跟心电图似的，一阵一阵的突刺。我原以为是哪个促销活动搞的流量浪涌，结果爬起来一看——好家伙，用户行为数据的写入量比平时高了三倍，可转化率连平时一半都不到。手机一直在震，工单系统里全是业务方催着查原因的，泡面凉了都没顾上吃。

　　我盯着监控看了半小时，突然想起上周业务方说要上线“智能推荐”功能，说要用缓存里的用户行为数据做实时分析。当时我还提醒过他们：“缓存不是数据库，别把所有数据都往里塞，尤其是未处理的原始日志。”结果他们说“没事，我们只存最近三天的，过期自动删”。现在想想，这哪是存三天，分明是把缓存当垃圾桶了——用户点一次商品详情页，就往缓存里塞一条“view_product_12345”的记录；加购一次，再塞一条“add_cart_12345”；甚至鼠标悬停都算一次“hover_product_12345”。这些数据跟转化率有个屁关系？可它们就那么堆在缓存里，把真正有用的会话状态、库存信息挤得没地方存。

　　第二天一早，我冲到业务方办公室，指着监控曲线说：“你们看，缓存命中率从95%掉到70%，这意味着什么？意味着每三个请求里就有一个要回源查数据库，数据库扛得住吗？”业务方那个产品经理还嘴硬：“我们只存了关键行为数据，没多少的。”我当场调出缓存键的统计列表——光“view_product_”开头的键就有两百多万个，“add_cart_”的也有几十万。他看完不说话了，低头玩手机，手机屏幕亮得刺眼。

　　其实这事儿早有苗头。半年前我就发现缓存里存了不少“user_click_banner_1”“user_scroll_page_2”这种数据，当时问过业务方，他们说“这是为了分析用户兴趣，优化广告投放”。我提醒他们：“这些数据应该存到数据分析平台，缓存不是干这个的。”他们说“数据分析平台太慢，缓存快”。我原以为他们只是临时用用，结果越存越多，最后连用户设备信息、浏览器版本都往里塞——说是为了“精准推荐”，可推荐算法根本没跑起来，数据全在缓存里沉睡。

　　那天下午，我和运维小王花了四小时清理缓存。我们先把所有带“view_”“add_”“hover_”前缀的键全删了，光这些就占了缓存总容量的40%。删的时候手都在抖——万一删错了关键数据怎么办？可留着更危险，缓存已经快满了，再不删就要开始淘汰有用的会话状态了。删完一看，缓存命中率回升到90%，数据库的查询压力降了一半，可转化率还是没起来。业务方又跳出来说：“是不是缓存清理影响了推荐算法？”我差点没骂出来：“推荐算法根本没跑起来！你们存了这么多数据，有几次真正用过？”

　　后来我才知道，业务方之所以这么干，是因为他们觉得“数据存得越多，分析越准”。可他们没想过，缓存的设计初衷是快速读写，不是长期存储。那些未处理的原始日志，在缓存里存三天和存三年没区别——反正没人分析，没人用。我原以为他们只是不懂技术，结果发现是优胜劣汰的逻辑在作怪：在电商行业，转化率低的公司活不下去，可转化率低的原因未必是产品不好，也可能是数据用错了地方。业务方为了“提升转化率”，拼命往缓存里塞数据，结果反而拖慢了系统，降低了真正的转化率——这不就是自己把自己玩死吗？

文章配图，仅供参考

　　下一步我打算把缓存的监控指标和业务方的KPI挂钩，转化率低的时候自动清理无关数据。可业务方肯定不同意，他们会说“这是技术干预业务”。其实我也懒得管了——反正缓存是我的，系统崩了也是我背锅。窗外天亮了，泡面还没吃，手机又震了——运维小王说，缓存里又出现了一批带“user_exit_page_”前缀的键，数量还在涨。我叹了口气，起身去泡第二包面——这事儿，防不住的。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!