移动互联时代推送内容秒滑背后的数据安全困局

　　去年五月那破事儿，现在想起来还窝火——业务方非要搞“推送内容秒滑”的交互，说是要提升用户体验，结果把数据安全搅得一团糟。那天下午三点多，监控突然爆红，慢查询队列堆了三千多条，我原以为又是哪个开发手抖写了全表扫描，结果一看日志，好家伙，是推送系统的埋点表炸了。

　　那表结构简单得离谱：用户ID、内容ID、滑动时间戳，连个索引都没加。业务方说“要极致性能”，开发就真把索引全删了——说是“减少写入开销”。我盯着屏幕上的行数跳了十分钟，风扇一直在转，热得我衬衫都湿透了，运维小王路过问了句“好了没”，我头都没抬：“等慢查询清完再说。”

文章配图，仅供参考

　　好个屁！事务一开，锁就来了。埋点表没索引，全表扫描加行锁，主库CPU直接飚到90%。更绝的是，推荐系统的慢查询和埋点表的写入撞在了一起，主从延迟从两秒涨到二十秒。等慢查询清完，外卖都凉了，窗外天也黑了——我盯着日志里的“Lock wait timeout exceeded”，心里直骂娘：这他妈叫“秒滑”？这叫“秒卡”还差不多。

　　后来查备份，发现更离谱的事。为了“提升写入性能”，开发把binlog格式改成了ROW，结果主从同步时，埋点表的数据量比主库多了三分之一——因为滑动行为会触发多次推荐，每次推荐都会生成新的埋点记录，而ROW格式会把每条记录的完整变更都传一遍。我原以为从库只是延迟，结果发现它根本没同步完，数据一致性早就烂了。

　　跟开发吵了一架。他们说“用户根本不会注意到两秒的延迟”，我说“但他们会注意到推荐的内容和滑动的记录对不上”。他们说“这是产品需求”，我说“产品需求不能违反数据安全的基本原则”。最后领导拍板：“先保证上线，数据问题后面再优化。”我差点把键盘摔了——优化？这表结构都烂成这样了，优化个屁！

　　后来没办法，只能临时加了个索引，把事务拆成两个单独的请求，推荐系统的慢查询改用异步队列。主从延迟降到了五秒以内，但埋点表的数据还是对不上——因为异步队列处理时有延迟，部分滑动行为没被及时记录。业务方说“这是小概率事件，不影响用户体验”，我盯着监控里每天几千条的“数据不一致”报警，心想：这他妈叫小概率？

　　现在回头看，这事儿能站得住的地方，可能就剩“优胜劣汰”了。移动互联时代，用户对交互的敏感度越来越高，推送内容秒滑这种需求，本质上是把数据安全的成本转嫁给了技术团队——业务方要极致性能，开发要快速上线，最后出问题的全是数据。我原以为索引、事务、主从这些基础东西，大家至少能达成共识，结果发现，在“用户体验”面前，数据安全连个屁都不是。

　　上周备份恢复演练，又出了幺蛾子。埋点表的备份文件比主库大了两倍，恢复时卡了半小时——因为ROW格式的binlog占空间太大，备份策略没调好。运维小王说“下次改用STATEMENT格式”，我说“STATEMENT会丢数据，你忘了上次的教训了？”他挠挠头：“那怎么办？”我叹了口气：“先保证能恢复，再考虑性能吧。”

　　现在这破系统还在跑，慢查询偶尔还会爆，主从延迟偶尔会涨。我偶尔会想，要是当初坚持不删索引，或者把事务拆得更彻底，会不会不一样？但转念一想，业务方要的是“秒滑”，开发要的是“不背锅”，领导要的是“别出事故”——数据安全？谁在乎呢？

　　下一步打算把埋点表的日志单独拆出来，用消息队列处理，减少对主库的依赖。但领导说“先保证推荐系统的性能”，开发说“消息队列会增加延迟”。我笑了笑，没说话——反正出问题的是他们，又不是我。风扇还在转，屏幕上的行数还在跳，外卖又凉了，窗外天又黑了。这破事儿，什么时候是个头啊？

（编辑：站长网）

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