聊聊技术探索与实践：一个快手老架构师的碎碎念
大家好，我是老K，坐标杭州，目前在快手干了快6年架构师。从0到1搭过推荐中台、直播信令系统、还有现在主攻的短视频内容理解平台。说白了，就是那种“产品一句话，我掉十斤肉”的角色。
最近被朋友问得最多的问题是：“你们大厂是不是天天搞高大上的新技术？是不是人均LLM+Rust+eBPF？”
我只能苦笑：现实是，90%的时间在修祖传代码、对齐PRD、和运维吵架，剩下10%才轮到技术探索。
但正是那10%，让我觉得这活儿还没干废。
起因：一个“不可能”的需求
事情发生在去年双11前两周（别问为什么快手也搞双11，电商化你懂的）。产品突然提了个需求：要在3秒内完成千万级视频的多模态标签打标，并支持实时增量更新。
我当时第一反应是：“你是不是把我们当成阿里通义千问团队了？”
但转头一看排期——deadline就在11月10号晚上23:59，而那天是周五。
懂的都懂：这意味着周末泡汤，还得搭上测试同学的生日。
更扎心的是，老系统用的还是单机Python脚本 + MySQL，跑10万条就得半小时。别说千万级，十万级都卡成PPT。
那一刻，我真的想砸电脑。
技术选型：不是炫技，是求生
既然要重构，就得动真格的。我和团队开了个“生死会”，定了几个原则：
- 不碰业务逻辑，只做基础设施加速（避免和产品扯皮）
- 必须能灰度、能回滚（运维大哥的底线）
- 尽量复用现有中间件（省得重新申请资源）
于是我们盯上了三个方向：
- 向量计算加速：用FAISS替代手写余弦相似度
- 流批一体处理：Flink + Kafka 替代 cron job
- 特征存储优化：Redis + RocksDB 混合缓存
但最头疼的其实是模型推理部分。原来的PyTorch模型加载一次就要4GB内存，还不能并发。线上机器就32G，光这个就能把资源吃干。
这时候，ChatGPT救了我一命。
我直接丢给它一段报错：
RuntimeError: CUDA out of memory. Tried to allocate 2.10 GiB (GPU 0; 15.78 GiB total capacity)
它反问我：“你试过 torch.compile 和 vLLM 吗？或者考虑 Triton Inference Server？”
说实话，之前我一直觉得AI辅助编程是噱头，但那次之后，我真香了。Claude甚至帮我画了个推理流水线图（虽然不能贴图，但脑补一下）。
最后我们选了 Triton + ONNX Runtime 组合：
- 模型提前转ONNX，减小体积
- Triton自动批处理（dynamic batching）
- GPU显存占用从4G压到1.2G，QPS从8提升到220+
踩坑实录：那些凌晨三点的崩溃瞬间
当然，过程没那么顺利。分享两个血泪教训：
坑1：Flink状态后端配置翻车
为了支持实时增量，我们用Flink做特征聚合。本地跑得好好的，一上生产就OOM。
查了半天，发现是 state.backend: rocksdb 没配 rocksdb.block.cache-size，默认只有8MB。千万级key进来直接爆掉。
# 正确姿势
state.backend: rocksdb
state.rocksdb.localdir: /data/flink/rocksdb
state.rocksdb.options.cache-block-size: 512MB # 关键！
运维看到日志直接@我：“你这是要把SSD写穿？”
坑2：Redis缓存雪崩
我们用Redis缓存热门视频的标签结果。结果某天一个大V发视频，瞬间10w+请求打过来，缓存miss，全压到后端模型服务。
当场雪崩。
解决方案很简单：加随机过期时间 + 本地缓存兜底。
# Python伪代码
def get_tags(video_id):
cache_key = f"tags:{video_id}"
tags = redis.get(cache_key)
if not tags:
# 兜底：先查本地LRU（比如cachetools）
tags = local_cache.get(video_id)
if not tags:
tags = model_infer(video_id)
# 过期时间加随机抖动：300 ± 60秒
redis.setex(cache_key, 300 + random.randint(0, 60), tags)
local_cache[video_id] = tags
return tags
效果对比：数字不会骗人
上线一周后，我们拉了份数据（已脱敏）：
| 指标 | 旧系统 | 新系统 | 提升 |
|---|---|---|---|
| 单视频打标耗时 | 1.2s | 45ms | 26x |
| 千万级全量耗时 | ~8小时 | 22分钟 | 21x |
| P99延迟 | 3.8s | 180ms | 21x |
| GPU利用率 | 15% | 78% | - |
最爽的是，双11当天零故障。产品请我们吃了顿火锅（虽然报销上限200，但心意到了）。
开发心得：技术探索不是闭门造车
回头想想，这次项目能成，靠的不是什么黑科技，而是几点朴素的认知：
问题驱动，不是技术驱动
别一上来就“我们要上Service Mesh！”、“必须用Rust重写！”。先搞清楚瓶颈在哪。我们最初以为是算法慢，结果发现是IO和缓存策略烂。善用AI，但别当甩手掌柜
ChatGPT能给你思路，但不能替你调参、看监控、背锅。它是指南针，不是船。留退路，保命最重要
所有新架构都做了双写+开关控制。一旦出事，5分钟切回老系统。这招在快手内部叫“留后门”，是血泪换来的文化。和SRE/测试做朋友
这次能快速定位Flink问题，全靠SRE提前帮我们埋了Prometheus指标。测试同学甚至写了混沌工程脚本，模拟缓存击穿场景——他们才是幕后英雄。
写在最后
有人说，杭州互联网卷成麻花了，阿里网易字节快手都在抢人。我确实也在看机会（别告诉老板），但跳槽不是目的，成长才是。
而成长，往往就藏在那些“不可能”的项目里——当你被deadline追着跑，被bug逼到墙角，反而会激发出最强的技术直觉。
所以，别怕接烂活。每个屎山背后，都藏着一座金矿，就看你愿不愿意挖。
对了，上周五晚上我又加班到凌晨两点，修一个诡异的Kafka重复消费Bug。
但搞定那一刻，看着监控曲线平稳如西湖水面，突然觉得——
这班，加得值。
作者：老K，快手6年老架构，现居杭州，主业搭系统，副业研究怎么用AI少写代码。欢迎同行交流，但别找我修祖传Java项目，除非请我喝瑞幸。
评论 0