根因分析

译者按 核心就一句：Kafka 不是靠什么神仙算法，就是“追加写日志 + 线性 IO”，只要记住这一点，后面所有调优和架构选型都有谱了。 国内中小厂如果日吞吐还在 GB 级以下，直接上集群多半是给自己找事——那套分布式复杂度、7×24 值守和磁盘规划，先把运维干掉半条命；这种量级其实用托管 Kafka 或普通 MQ 更香。 如果非要 K3s/K8s 私有云自建，心里得有数：网络和存储才是爸爸，PVC 的延迟和跨节点带宽一旦拉胯，Kafka 副本追不上、ISR 缩水都是白给的事故。 分层存储那套 S3/MinIO 冷热分离，在中小环境别抱太大希望，私有云对象存储的带宽和成本根本给不到它发挥的前提，老老实实按“日写入量 × 保留天数”容量买磁盘更实在。 落地建议先做减法：集群规划、分区数、监控（ISR、消费 lag）这几样砸实了，再考虑 Cruise Control、KRaft 这些高级特性，否则大厂最佳实践到你这儿全变成事故预案。 Apache Kafka 架构入门：从日志到生态 本文为技术翻译稿，内容基于 Apache Kafka Committer Stanislav Kozlovski 的文章精简优化。 Apache Kafka 是目前最流行的开源分布式流处理平台，已成为实时数据流事实标准。本文从底层日志结构出发，讲清 Kafka 的核心机制、性能优化、容错设计，以及周边生态组件。 核心：日志（Log） Kafka 中数据存储在 Topic 中，而 Topic 的基础是 Log——一个简单的有序数据结构，按顺序追加记录。 Log 具有两个关键特性： 不可变性：已写入的记录不会被修改 O(1) 读写：只要从尾部写入、从头部或尾部读取，访问速度不会随着日志增大而变慢 选择 Log 作为核心结构的根本原因，是它针对机械硬盘（HDD）做了优化。HDD 最擅长线性读写，而 Log 的操作模式恰好就是线性读写。这使 Kafka 能以极低成本存储大量数据，同时保持高性能。 性能优化 一个调优良好的 Kafka 集群，瓶颈通常在网络层面，吞吐可达每秒数 GB。性能来自多个层面的优化： ...

译者按 核心结论一句话：Hotstar 把表情服务从第三方迁到自建，靠“客户端异步缓冲 + Kafka + Spark 微批聚合 + PubSub 实时推送”这条流水线，用异步和批量换吞吐，扛住了单场赛事 50 亿次提交。 落地到国内中小厂得打个问号：这套架构暗含你已经有成熟的 Kafka 数据平台和 Spark 集群，K3s/K8s 下自己裸跑这两样运维成本直接劝退，常规场景用云上托管 Kafka 加 Redis 聚合完全够用，别照搬。 踩坑提醒一句：生产端“500ms 或 2 万条触发批量写入”的缓冲设计，突发流量下本地缓冲积压容易引发内存水位上涨，记得给进程加内存监控和积压告警；另外在 K8s 里跑 2 秒粒度的 Spark 微批，务必提前压测并预留 CPU 余量，否则 HPA 扩缩容根本追不上比赛开场那波尖峰。 Hotstar 表情符号系统的架构实践 原作者：Dedeepya Bonthu，转载自其 Medium 文章 在体育场馆中，观众用欢呼、标语来释放情绪，而电视屏幕前的观众则通过表情符号快速表达自我。当数百万用户同时发送表情时，这就变成了一个技术难题——Hotstar 在互动社交信息流中成功解决了它。 本文从技术视角剖析 Hotstar「Sports Bar」中的表情符号（Emojis）功能：如何实时收集用户信号、压缩为情绪流并动态展示，尤其是在赛事期间面对数十亿次提交的压力。 最初我们使用第三方服务，但性能、稳定性与成本均不理想，最终决定将该核心服务自建。以下为整体架构、关键设计原则及落地影响。 整体架构 架构图略（见原文）。 关键设计原则 可扩展性 系统需支持横向扩展以应对流量增长。通过负载均衡和自动伸缩配置实现资源的动态扩缩容。 分解 系统拆分为多个独立组件，各自承担明确任务，既便于独立扩展，也降低耦合。 异步 异步处理不阻塞资源，从而支持更高并发。这一点将在后文详述。 实现细节 客户端请求处理 客户端通过 HTTP API 提交用户的表情选择。为避免占用连接，API 的重复处理必须离线完成——将数据写入消息队列供下游消费。 消息队列是应用间异步通信的常见机制。对比多种 MQ 后，我们选择了 Kafka：高吞吐、高可用、低延迟，且支持消费组。自运维 Kafka 成本较高，好在 Hotstar 已有基于 Kafka 的数据平台 Knol，完全满足我们的需求。 ...