high-concurrency-and-synchronization.md

同步场景

Q：类似抖音直播间，如果有十万人同时在线，该如何做直播间点赞同步操作？

A：嗯在这种高并发的场景下，肯定不能使用逐条广播，我会采用异步批量聚合 + 发布或订阅 + websocket 集群广播的方案，首先客户端通过 websocket 将点赞事件写入消息队列，消息队列可以用 Kafka 或 redis stream，然后再使用专门的聚合服务按照某个时间比如 100ms 为单位，把同一房间的点赞事件在内存里累加，然后原子性地存到 redis，更新后再通过 redis pub 或 sub 发布最新总数，然后所有 websocket 节点订阅该房间的更新频道，收到后只发一条点赞更新消息给该房间的所有客户端，客户端拿到最新的点赞数后再更新渲染 UI，这样就保证了高可用和消息可靠，扩展性也比较好，也有一定的容错性

Q：直播间突然有大流量打过来，现有的服务器资源只能维持现状，该怎么办？

A：感觉主要还是要先快速降级和限流保护，比如说可以先把一些非核心的功能关闭，可以限制每个用户的请求频率，或者是限制每个房间的并发连接数等，比如说点赞、评论等，或者是把一些非必要的请求丢弃掉，比如说可以把一些低优先级的请求放到消息队列中，等有空余资源时再处理；另外也可以考虑使用 CDN 来缓存一些静态资源，减轻服务器的压力；如果还是不行的话就只能考虑扩容了，比如说可以增加一些新的服务器节点，或者是使用负载均衡来分担流量；如果还是不行的话就只能考虑限流了 如果直播间突然来了超出现有资源的大流量，我会第一时间开启限流与降级，关停非核心功能，优先保证视频推流和互动。接着把所有操作请求写入消息队列，后端按能力排队处理，避免打穿数据库。静态资源和 HLS 流都走 CDN，减轻源站；应用层做本地＋Redis 多级缓存。 同时，我会触发 Kubernetes 的水平弹性伸缩，快速拉新实例，如果资源仍不足，就用 Serverless 函数临时卸载热点请求。事后结合 Prometheus 告警与容量预案，优化压测脚本，确保下次大流量到来时，我们可以平滑度过。

Q：有没有了解过看门狗机制？

A：看门狗本质上是一种定时器，用来监控运行状态，系统或服务在正常运行时会不断喂狗，如果在规定时间内没有收到喂狗信号，看门狗就会认定系统卡死或者异常，后端方面主要是操作系统或进程的软件看门狗或者云和容器平台的软件看门狗，如果主逻辑超时没有相应，看门狗线程就会执行自我修复逻辑，比如重启、释放资源、告警等