推荐系统相关
Created|Updated
|Word Count:177|Reading Time:1mins|Post Views:
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。
在瀑布流式的外显曝光场景下,重排能够减少用户的疲劳度。
这就涉及到推荐系统的设计,流量要经过什么样的链路呢?
接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。
不同的架构之间有一个典型的优缺点需要取舍:链路长度会影响网络传输的最终效率,也会影响推荐系统的性能。
Author: magicliang
Link: https://magicliang.github.io/2023/02/13/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F%E7%9B%B8%E5%85%B3/
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles

2025-07-15
系统的弹性
背景介绍 1999年,Dan Kegel 在互联网上发表了一篇文章,首次将 C10K 问题带入软件工程师的视野。在那个互联网勃兴的年代,计算机的运算处理能力,ISP 能够提供的带宽和网速都还十分有限,用户的数量也很少(那时候一个网站几百个人是很正常的事)。Dan Kegel 却已经敏锐地注意到极端的场景下资源紧张的问题。按照他的观察,某些大型的网络站点需要面对高达10000个客户端的并行请求。以当时的通行系统架构,单机服务器并不足以处理这个这个问题(当时绝大部分系统也没有那么大的流量,所以大部分人也没意识到这个问题)。因此,系统设计者必须为 C10K 问题做好准备。在那篇文章之中, Dan Kegel 提出了使用非阻塞异步 IO 模型,和使用各种内核系统调用黑魔法来提高系统 IO 性能的方式,来提高单机的并行处理能力。不得不说,这篇文章在当时很有先驱意义,它使得大规模网络系统的流量问题浮上了水面,也让人们意识到了系统容量建模和扩容提升性能的重要性。在它的启发下,C10K 问题出现了很多变种,从并发 C10K clients,到并发 C10K connections,到 C10K ...

2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启,都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的,然后在上游的服务上做好 failover,然后增加 standby server,让 sticky 数据 transmit 到 standby 机器上,让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下,除了发布新的 feature 升级以外,都应该尽量用热配置来避免重启。

2025-09-13
分布式事务
问题定义 对经典的电商场景而言:下单是个插入操作,扣减金额和库存是个更新操作,操作的模型不同,如果进行分布式的服务拆分,则可能无法在一个本地事务里操作几个模型,涉及跨库事务。 CAP 定义 根据 Eric Brewer 提出的 CAP 理论: Consistency:All Nodes see the same data at the same time。所有节点看到同一份最新数据(线性一致性)。 Availability:Reads and writes always succeed。非故障节点必须在合理时间内响应。 Partition tolerance:System continues to operate despite arbitrary message loss or failure of part of the system。网络分区时系统继续运行。 由此诞生三种设计约束和取舍方向: CA:放弃P,仅适用于单点系统,非分布式,如 MySQL主从同步。 AP:放弃强一致性,保证高可用。Cassandra,DynamoDB。Gossip协议可实现最终一致性。 CP...

2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集(Data-Intensive)与计算密集(Compute-Intensive)是当今两大负载类型。前者以大数据为代表,后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率;与之对应的是计算密集型应用,CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的(NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架)。 每一种技术都基于一定的设计理念,而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了,因为业界已经有成功的案例,对这些组件做了很好的抽象,我们只要做好拿来主义就行了。 可靠性(Reliability) fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC,即使磁盘的 MTTF 很高,磁盘数量大了以后,每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余(冗余磁盘、冗余电源)。 软件容错是第二种方...

2020-09-02
异地多活与单元化
背景介绍 名词解释 ldc logical data center idc internet data center ldc 是 idc 的进化版,是一种单元化部署方案。 扩展模式 vs 镜像模式 扩展模式是把服务/数据库分拆,然后部署到不同的机房里面,相当于放大了一个物理机房。 镜像模式是每个机房里部署的服务都是一样的,每个机房承担一定流量。 镜像模式的容灾效果更好,难度在如何切分流量上。容灾还要考虑机房级容灾、部署地容灾的问题。多地部署带来距离,距离带来延时,延时带来 replica 的风险。 单元化部署 所谓 cell,是一个能完成所有业务操作的自包含集合(每个单元,都是其他单元的镜像)。一般的 soa 架构,服务是分层的,而且每一层的任一节点都可以被其他机房调用。而单元化部署的结果是,本单元的上层节点,只会调用本单元的下层节点。它具有一个站点全部的功能,但不具有一个站点全部的流量。 这种单元化部署实际上就要求底层的数据也要做 sharding。单元化的结果是,数据库连接可以更好地被复用-多个单元互相跨 db 连接,其实很浪费资源。 单元化是按核心数据维度,对业务系统的部署...

2022-01-19
Gergely Orosz 文章翻译-软件架构被高估,简明设计被低估
原文链接:《Software Architecture is Overrated, Clear and Simple Design is Underrated》





