北京
一张缩略图20KB，比头像还小，比网站图标还轻。但它是内容的封面，是用户点击或划走的第一依据，承载着全部的第一印象。
当内容量达到数千条，每条同时被数千用户请求——20KB开始疯狂增殖。每秒数千请求，每分钟数GB出站流量，且随集群规模快速膨胀。系统中最小的文件，成了最大的基础设施难题。
我的公司曾用一台服务器扛下所有。无备份，无冗余，单点故障悬于用户打开App时看到的一切之上。结果可想而知：服务器宕机，所有缩略图消失。内容加载，但每张图都是破碎占位符。没有什么比这更快摧毁用户信任。
我们必须重建。新系统需要做到：每秒接收数千上传请求；每条上传立即复制到备份服务器；读取速率达上传5倍且游刃有余；主服务器宕机瞬间自动切换至备份——零停机、零人工、用户永远看不到破损图像。
以下是我们的构建路径。
早期我们定了一条铁律：不做Netflix级别的架构，因为我们没有Netflix的量。过度工程会拖慢速度，徒增永远用不到的复杂度。最佳策略是榨干现有系统。
Redis已在运行。它的Pub/Sub功能看似完美：服务器A上传文件后广播事件，服务器B监听并保存副本。但Pub/Sub有个致命缺陷——订阅者离线时事件永久丢失，无重试、无回放。备份服务器崩溃重启后，对错过的文件一无所知，静默缺失，无报错，无法恢复。
我们转向Redis Streams配合AOF（追加写入，每条事件落盘且能扛崩溃）。与Pub/Sub不同，Streams记住所有事件及每个消费者的位置。备份服务器宕机重启后，精确续接断点，零丢失。
复制解决了，但路由仍是问题。负载均衡器已在位，但它如何知道特定文件存在哪台服务器？主服务器故障时，负载均衡器如何即时切换至备份？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
