上一篇拆了推荐 Feed 的架构，这篇换个讲法：造一个用户，给他一晚上的真实行为数据，从《数学之美》的余弦定理出发，经过 Netflix 的三层分工和 TikTok 的工程极致，跟着他走完召回、粗排、精排、重排四层漏斗——每一步输入什么、输出什么、分数怎么变。

我在一个海外 C 端 IPTV 产品上做 Java 架构的实战总结：高并发、高可用、高性能、零信任安全、攻击防御与缓存一致性，其间落地了 Hystrix、EVCache 等 Netflix 开源组件与工程实践。

Spark 是批处理血统的分布式计算引擎，Flink 是流处理血统的——血统决定了延迟模型、状态管理和生态主场。本文讲清两者的基础概念并附 Java API 示例（Spark ETL/ALS 训练、Flink 事件时间窗口/状态 TTL），以一家类 Netflix 的视频公司为背景给出具体用例，以及算力规格估算、监控指标、故障恢复剧本和两家的避坑清单。

拆解微博、X 式推荐流背后的完整架构：用户偏好如何用交互矩阵和 embedding 算出来，召回/粗排/精排/重排四层漏斗各自的技术路径与离线在线分工（主力是十年前的深度学习栈，不是大模型），无限下拉靠游标分页、已曝光去重和候选池分层兜底。

Netflix 同时跑着两个 Flink 自动扩缩容器：2019 年自研的’外部观察者’和社区开源的’内部推理者’。读 Netflix 技术博客《A Tale of Two Flink Autoscalers》的学习笔记：为什么看容器指标的扩缩容有天花板，True Processing Rate 怎么逐顶点算并行度，以及把开源算法落到三万个作业上时补的三个工程缺口。

Netflix 技术博客服务拓扑系列的第二篇，讲怎么做而不是做了什么：为了实时服务依赖地图，他们用流式优先架构替掉批处理，靠反应式流背压扛住每秒百万级流记录，用三级分布式聚合管线解决网络中间件解析和热点节点两个看似无关的问题，并实现了拓扑的时间旅行查询。全文最有价值的不是架构图，而是 V1 上生产后连环暴露的九个瓶颈，以及一条贯穿始终的方法论：测量驱动，一次只修一个瓶颈，规模会定性改变一切结论。

读 Netflix 技术博客《From Silos to Service Topology》的工程向笔记：Netflix 分析了四年的工程师求助记录，发现最高频的问题全是依赖问题（上下游是谁、爆炸半径多大、故障源在哪），于是用三路互补的数据源（eBPF 网络流、IPC 指标、分布式追踪）各自建图、物理隔离、并行查询后合并，再经 Kafka + Pekko Streams 三级聚合管线实时入库，最终对外暴露亚秒级查询的 gRPC API 和可视化界面；核心启示是「单一数据源永远讲不全依赖关系」和「小时级陈旧的拓扑图是考古不是可观测性」。

复盘我主导的巴西 IPTV 视频点播系统的领域驱动设计实践，包括领域划分、聚合根设计、领域事件和多次产品迭代中的架构演进。

介绍我开发的小型电商系统 starmall（六爻星辰）：uni-app 微信小程序前端 + SpringBoot 后端（基于 CRMEB 二次开发），支持商品购买、真实微信支付、老师时段预约、择吉日查询、WebSocket 长连接聊天等功能。本文深入解析后端能力全景、下单幂等、原子扣库存防超卖、支付回调防重、Redis 队列代替 MQ 等核心技术实现。

结合 RocketMQ 基础与工程实践，系统对比 RabbitMQ、Kafka、RocketMQ、Redis MQ 的核心模型、推拉模式、长连接机制、适用场景，并整理使用注意点、异常处理与业务异常兜底策略。

结合《RocketMQ 实战与核心原理》《RocketMQ 技术内幕》及社区实践，系统梳理 RocketMQ 与 RabbitMQ、Kafka 的选型对比与底层原理差异，以及推拉通知模式权衡、异常处理、高并发支撑与常见避坑指南。