记得第一次把商品上架模块和直播间运营模块合并进同一套系统时，订单超卖、直播延迟和商品卡顿几乎把我们逼到墙角。那段经历让我意识到：直播带货不是把两个场景堆在一起就完事，关键在于如何把流媒体链路、实时互动和库存一致性变成可观测、可回滚的工程。

      在技术选型上，我倾向于边缘分发 + 中台微服务架构：视频入口用RTMP采集，服务端用SRS或Nginx-RTMP做推流接入，实时观看采用WebRTC做低延迟通道、HLS用于长尾兼容；转码用FFmpeg做多码率切片，借助CDN做全球分发。实操提醒：初期别只看延迟指标，要同时盯帧丢失率和播放启动时间，调优时优先排查网络丢包与TURN配置。

      商品上架和库存同步我把它做成事件驱动流：商品变更写入Postgres主库，使用Debezium推送到Kafka，消费者写入Elasticsearch用于搜索，再同步到Redis作热点缓存与秒杀预留。最常遇到的问题是并发扣减导致超卖；经验是用Redis Lua脚本做原子扣减，结合本地事务+异步补偿（Saga），把失败率控制在可接受范围内。

      直播间互动侧重实时性与可扩展性：WebSocket和gRPC流式消息混合使用。把房间消息放入Kafka做冷备，热数据用Redis Stream支撑高并发弹幕与连麦信令。遇到过一次消息丢失，根因是消费位点管理不当——我们改用消费者组配合幂等写入与消息重试，减少人工干预。

      运维层面不再是可选项。Kubernetes做容器编排，Prometheus+Grafana监控关键链路：推流QPS、转码队列长度、库存锁命中率、订单P95时延等。压测工具推荐k6和Locust：真实流量回放时，API网关（建议用Envoy）需配置熔断与限流，避免单个主播导致雪崩。

      最后一点是迭代节奏：把复杂功能拆成可回滚的小步子发布。例如先上线商品上架到搜索的完整链路，再加实时库存到直播抽样。我的判断是，没有完美方案，但通过自动化测试、链路追踪和压测，可以把风险降到可控范围。未来会持续关注WebTransport、AV1编码与边缘计算在本场景的落地可能。