09 | 线上服务：如何在线上提供高并发的推荐服务？

王喆



该思维导图由 AI 生成，仅供参考

你好，我是王喆。今天开始，我们进入线上服务篇的学习。
很多同学提起推荐系统，首先想到的是那些结构“华丽”，发展迅速的推荐模型。但事实上，在一个实际的工业级推荐系统中，训练和实现推荐模型的工作量往往连一半都没有。大量的工作都发生在搭建并维护推荐服务器、模型服务模块，以及特征和模型参数数据库等线上服务部分。
同时，由于线上服务模块是直接服务用户，产生推荐结果的模块，如果一旦发生延迟增加甚至服务宕机的情况，就会产生公司级别的事故。因此毫不夸张地说，线上服务实际上是推荐系统中最关键的一个模块。
线上服务如果写得不好，不仅杂乱无章，而且难以升级维护。因此，为了让你掌握搭建起一个支持深度学习的、稳定可扩展的推荐服务的方法，在这一模块中，我们会依次来讲线上服务器、特征存储、模型服务等模块的知识。
今天，我们先聚焦线上服务器，一起搭建直接产生推荐结果的服务接口。在这个过程中，我们按照先了解、后思考、再实践的顺序，依次解决这 3 个关键问题：
一个工业级的推荐服务器内部究竟都做了哪些事情？
像阿里、字节、腾讯这样级别的公司，它们的推荐系统是怎么承接住每秒百万甚至上千万的推荐请求的？
我们自己该如何搭建一个工业级推荐服务器的雏形呢？

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了搭建高并发推荐服务的关键技术和实践过程。文章首先强调了高并发推荐服务在推荐系统中的重要性，以及阿里、字节、腾讯等大型公司采用的负载均衡、缓存和服务降级机制来支撑整体架构。接着，文章详细介绍了使用Java嵌入式服务器Jetty搭建推荐服务器的过程，包括创建服务器、添加API接口以及实现Servlet服务的代码。作者强调了理解“造火箭”（即工业级推荐服务器的具体功能和高并发推荐服务的主要机制）和实践“拧螺丝”（即具体技术实现）两方面的重要性。最后，文章提出了课后思考问题，引发读者对负载均衡服务器的调度策略进行思考。整体而言，本文通过简洁清晰的语言，深入浅出地介绍了搭建高并发推荐服务的关键技术和实践过程，对于想要了解推荐系统工程实践的读者具有很高的参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深度学习推荐系统实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(17)

最新
精选

smjccj
源地址哈希，或根据服务器计算能力加权随机分配，当出现大量节点利用率很低时，进行资源回收，减少虚拟机，当大部分节点都出现overload情况，进行扩容，增加虚拟机数量。
作者回复: 非常专业的回答，赞。
2020-10-23
4
60
范闲
1.如果硬件配置基本一样且部署服务一样，就采用轮询或者随机的负载均衡策略 2.如果硬件配置不同，可以根据硬件的计算能力做加权的负载均衡策略 3.同样也可以利用源地址hash做策略 4.关于扩容和缩容:可以根据系统负载情况做动态调整。
作者回复: 非常好了，基本就是主流的负载均衡策略。推荐其他同学学习。
2020-11-26
2
34
那时刻
请问老师，按照一些规则预先缓存好几类新用户的推荐列表，等遇到新用户的时候就直接返回，这算是冷启动策略么？
作者回复: 其实是非常好的冷启动策略，业界也有很多是这样做的。再优化一点，可以利用新用户有限的信息，比如ip，注册信息等做一个简单的聚类，为每个人群聚类产生合适的推荐列表提前缓存。
2020-10-29
2
23
Geek_04634b
这个课199我都买，太值钱了，现在什么算法都是浮云，关键是落地
作者回复: 有兴趣的话你可以去看看一些价值4999的训练营内容，然后再评估一下到底应该值多少钱。
2021-01-12
6
13
冻糕
带我入门的师兄说推荐服务理论上限是100ms延迟，但实际上只会给你最多85ms的时间，超过就要必须优化。其中多路召回加重复过滤上限25ms，排序上限45ms 业务规则加生成json 上限10到15ms，请问老师这个延迟数据是否是业界通用的勒？
作者回复: 你师兄说的基本是业界通用指标。
2021-04-14
2
11
shenhuaze
王老师，如果推荐服务选择java和jetty，那么如果要上线基于tensorflow或者pytorch训练的深度学习模型，是需要自己用java改写预测的代码吗？还是有什么现成的解决方案？
作者回复: 过几天会谈model serving的几种方式。一般选择请求tensorflow serving，或者embedding上线的方式。到时候我们可以再详细讨论。
2020-10-25
5
9
雪焰🐻🥑
王老师好，请问对于：“在一个成熟的工业级推荐系统中，合理的缓存策略甚至能够阻挡掉 90% 以上的推荐请求，大大减小推荐服务器的计算压力”，我理解每个用户的请求，在不同的时间，地点，context下是不一样的，这样千差万别的请求，数量级应该很大，不知道是如何把大部分都缓存起来的呢？谢谢
作者回复: 缓存服务一般都要指定ttl，就是过期时间，ttl要根据缓存的可用大小进行设定。如果每次请求的变量确实完全不一样，就不用缓存了，因为没有意义。但在实际的应用中总是有优化的空间，比如电商网站，在没有产生新的历史行为的时候你没必要每次请求都产生不同的结果，就可以利用缓存来挡掉重复的请求。
2020-10-24
4
8
Geek_8197bf
请问老师，工业界推荐算法的实现都是Java和C++吗？Python流行吗？我只会Python，在犹豫要不要做推荐
作者回复: python是离线部分的主流，但线上服务一般会用C++或java实现
2021-05-14
2
4
sljoai
老师您好，本文中提供的服务降级方案是从业务功能上来说的，降低服务能力，那系统是如何感知到系统压力，同时反馈到实际服务能力的选择上的呢？另外，像Istio、SpringCloud、Dubbo这种服务框架中也包含服务降级的方案，与您文中提到服务降级方案相比较，有什么异同呢？这一块比较疑惑，希望老师能解答一下，谢谢！
作者回复: 现在开源的监控工具，包括成熟的监控SaaS解决方案都很多，比如cAdvisor，datadog等等。总的来说成熟的公司都会建立一套成熟的监控体系，包括服务器的延迟、cpu、内存的占有率等等，一旦发现异常会立即通过预警或警告的方式反馈服务器，然后服务器根据警告作出相应的服务降级操作，或其他操作。你说的Istio，SpringCloud等是一些微服务的管理和实现框架，更多是从架构层面上考虑，而不是从推荐服务内部逻辑的层面考虑。二者并不矛盾，可以并存。
2020-10-24

4
笑笑是个好孩子
这里的缓存和把召回到的结果保存到abase之类的k-v存储中是一样的吗
作者回复: 一般来说服务器各节点内部还有in memory缓存，k-v store一般会去存储公用的模型和数据
2021-06-23

3

收起评论