推荐系统相关
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。
在瀑布流式的外显曝光场景下，重排能够减少用户的疲劳度。
这就涉及到推荐系统的设计，流量要经过什么样的链路呢？
接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。
不同的架构之间有一个典型的优缺点需要取舍：链路长度会影响网络传输的最终效率，也会影响推荐系统的性能。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2022-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题 软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支，以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处，去做高风险的维护工作。但是，只要公司正常发展，业务总会越做越大/复杂，所以要维持系统的可维护性，成为了一门很重要的学问。 现实中的系统的高复杂度问题，可以简单表述为“不确定性矛盾”：需求具有高度不确定性，一直都在高速变化；而工程师高度倾向于确定实现（因为高度抽象、反复抽象的成本很高），所以具体的实现难以变更，这两种相反的特性难以调和。 其实我们现在遇到的困境，历史上发生过很多次，比如我们现代的很多软件工程理论，就是从历次的软件危机中诞生的。归根结底，软件之所以叫软件（Software），是因为相...
2019-09-26
架构整洁之道笔记
最早的《The Clean Architecture》诞生于 2012年，这个问题很早就被讨论清楚了。 思维导图： 注意，所有的接口都是在高层声明的：UseCase Input Port 和 UseCase Output port，所以高层可以实现高层的接口，低层也可以实现高层的接口。 注意，sofa的分层就是在一个横向的模块里声明了业务用例的接口和 core-model 的接口，这样源代码级的依赖都集中在抽象上： Use Case Interactor 和 Presenter 应该是可测试的，而 Data Access Interface、View、ORM 应该是 humble object。所以一个应用的低层（外层）应该是被排除掉不做测试的。 附件下载： xmind 关于源代码中的依赖关系的一些澄清： “使用”并不意味着“定义”，而只是引用 dashed outline 代表虚线框，也代表抽象。
2018-01-30
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后，也未必代表数据是完全一致的（Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识？但如果中途数据丢失，则还是会有子节点数据不一致）。 在分布式环境下，多个系统协同工作的效率，受制于系统交叉点的性能。在需要达成分布式共识的场景下，分布式共识算法在保证系统安全性的同时，限制了全系统横向扩展的性能提升。 根据环境的不同，可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库，节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链，可以使用 PBFT。PBFT 算法是依据确定性的投票（可能是漫长的投票，也可能进入死循环）达到确定性一致的算法。 在没有互信的情况下-公有链，可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性，性能比 PBFT 要稍微好点。 最好的共识算法应该模块化，例如 Corda 中的 notary，Hyperledger fabric 中的 solo/k...
2020-06-01
交易系统模型设计
交易系统.xmind
2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集（Data-Intensive）与计算密集（Compute-Intensive）是当今两大负载类型。前者以大数据为代表，后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率；与之对应的是计算密集型应用，CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的（NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架）。 每一种技术都基于一定的设计理念，而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了，因为业界已经有成功的案例，对这些组件做了很好的抽象，我们只要做好拿来主义就行了。 可靠性（Reliability） fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC，即使磁盘的 MTTF 很高，磁盘数量大了以后，每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余（冗余磁盘、冗余电源）。 软件容错是第二种方...
2021-05-07
如何画架构图
前言 有意义且具备一致性（coherence）的架构图有助于为不同的利益相关者（stakeholder）澄清（illustrate）事实，并达成共识-反之，图表杂乱无章。 有意义的图表胜过建模（建模指的是With modelling, you're building up a non-visual model of something (e.g. the software architecture of a software system), and then creating different views (e.g. diagrams) on top of that model. ），在架构沟通上，visualization 胜过千言万语。 一致性要求我们有足够好的指导原则，让我们知道标准的图元是什么。 “架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。 在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，因为它们是从不同的角度描述问题的。 应该在架构图旁边加上图例（legend），沟通者应该懂得图元（key）是什么。key 和 legen...
