原来如此 我也是浅薄的了解一下：

提到缓存。大概就是想到房间是需要 Cache 的、大主播应该还需要缓存预热 。突发事件还需要缓存动态扩容（一致性 Hash）。

然后都远没有考虑到视频这些加工、分发、带宽瓶颈 这些场景。0.0 粗浅的评判一番。也期待贤弟能把这些智慧的结晶 Show 出来。让智慧的光芒灼伤一下我的眼睛 - -

楼主最近关注直播本身了么 。基本都是缓存 + 长连接 + SRE 的运用了

当然、厉害的还有自己的协议用来压缩带宽

坐标是硬伤

Remote Jobs?

Downtown Core 周边的物价贵的一匹哦

Java 是必选项么

水桥还是有意思 。你说的 Preloader 其实就是用 in 查询解决。记得加 Index 不然巨慢

楼主可以参看我的方法：

https://github.com/one-hole/spider-consumer

https://github.com/w-zengtao/rb-spider

程序有个入口，RubyGems 帮你管理依赖 。以上

1. 入网 和 出网 分清楚、有些 API 或者 服务，是可以减少数据量、或者说降低峰值的量。
2. 内部通信协议尽量不要走 HTTP + JSON 。gRPC + Protobuf 这样的组合能省不少上行带宽
3. 可以把耗流量的「业务」抽离出来成为独立的服务。买新的机器来部署独立的服务可以使得带宽能「物尽其用」，也方便动态扩容
4. 可以看看峰值问题是「业务触发」（被动）的，还是说「主动触发」（比如定时任务），如果是后者可以用 MQ 消峰

13-20K 。宁愿在深圳干地产中介 干了一票大的顶得上几十个月了