实时直播弹幕系统设计

弱网环境短轮询策略，本地缓存+发送端限流（弹幕空间有限）+ ringbuffer（空间有限，对准确性要求不高）

https://www.zhihu.com/question/633271022/answer/1896985483596234797

整个服务读多写少，读写比例大概几百比1.

如果实时性要求高的话，可以采用长连接模式（轮询的话，时效性不好，同时对于评论少的直播间可能空转）

websocket 和 SSE架构

只要求服务端推送的话，可以选SSE，评论还是少量的，减少资源的浪费

长连接选型

单体架构

发布订阅模式去推送消息到SSE,会导致无用的消息，浪费大量SSE资源

按直播间分区，然后消费，可以缓解问题，但没有解决问题

多个topic 动态 直播间 。对元数据服务比如zookeeper的压力？ 实时关系变化()，导致问题：kafka rebalance

智能负载均衡器 opentstry lua

智能调度服务，rpc调用，和直播间关联的SSE服务数量正比，可以并行调用。

拓展能力平台化，实时推送平台，推送消息，点赞，礼物等。SSE连接管理 AKKA actor模式。

拓展

1.实时长连接选型

长连接实现、技术选型优缺点及代码实现细节如下：

‌一、长连接实现‌

在实现实时查看评论设计时，长连接技术是关键。其中，WebSocket和SSE是两种常用的技术选型。

‌二、技术选型优缺点‌

1. ‌WebSocket‌

   • ‌优点‌：
     • 实时性：WebSocket可以实现实时双向通信，非常适合需要实时数据更新的场景。
     • 持久连接：WebSocket保持长连接，减少频繁建立和断开连接的开销。
     • 低延迟：数据传输延迟低，适合需要快速响应的应用。
   • ‌缺点‌：
     • 复杂性：WebSocket的实现和维护相对复杂，需要处理连接管理、错误处理和重连逻辑。
     • 兼容性：某些老旧浏览器可能不支持WebSocket。

2. ‌SSE (Server-Sent Events)‌

   • ‌优点‌：
     • 简单性：SSE实现相对简单，适用于单向通信。
     • 兼容性：SSE在大多数现代浏览器中都有较好的支持。
   • ‌缺点‌：
     • 单向通信：SSE只能服务器向客户端发送数据，不支持双向通信。
     • 性能：SSE在大量数据更新时可能不如WebSocket高效。

2.AKKA 利用actor模型管理SSE连接推送

在基于 Akka 的 SSE（Server-Sent Events）实现中，通过 Actor 模型管理连接和推送可实现高并发、容错的实时数据流传输。以下是关键实现方案及技术细节：

---

一、Actor 模型管理 SSE 的核心设计

1. ‌连接与 Actor 绑定‌
   每个 SSE 客户端连接对应一个独立的 Actor 实例，负责管理连接生命周期（创建、消息推送、超时检测、异常终止等）‌26。Actor 通过 Akka Streams 的 Source 持续向客户端推送事件流。

2. ‌消息驱动机制‌

   • ‌事件推送‌：业务层通过向 Actor 发送消息（如 PushEvent(data)）触发数据推送，Actor 将消息转换为 SSE 格式（如 ServerSentEvent）并写入响应流‌26。
   • ‌状态管理‌：Actor 维护连接状态（如活跃状态、最后心跳时间），通过定时消息（如 CheckTimeout）检测闲置连接并自动关闭‌57。

3. ‌层级监管结构‌

   • ‌父 Actor 管理子 Actor‌：创建 SSEManagerActor 作为父级监管者，统一创建和监控子级 SSEConnectionActor，实现连接资源的弹性扩缩容‌35。
   • ‌容错策略‌：通过 Akka 的监管策略（如 SupervisorStrategy）处理子 Actor 的异常（如网络中断、序列化错误）‌47。

在线统计人数

1.订阅事件如何存储 典型的kv场景

uid->事件内容

事件->userid（set分片，大并发大key问题）

事件过期事件TTL，兜底内存泄漏

事件关系百万，并发分批返回，稳定性，带宽，延迟，GC影响 sscan非阻塞，热点SSE 事件导致一些热点，进行事件拆分或者打散

SSE连接如何维护，心跳如何设计，间隔，过期处理

单机连接数如何进行突破

一、订阅事件存储架构

1. ‌数据模型设计‌：

   • 采用双KV结构：uid→[event_content]使用LSM-Tree存储引擎（如RocksDB）保证写入性能1
   • event→[userid]采用分片Redis Cluster，通过CRC16分片算法避免大Key问题，单个分片控制在10MB以内24

2. ‌TTL与内存管理‌：

   • 实现二级过期策略：Redis原生TTL+定时扫描补偿机制（如每小时扫描ZSET过期键）4
   • 内存兜底采用LRU自动驱逐+监控告警熔断机制3

二、高并发处理方案

1. ‌热点事件优化‌：

   • 事件打散通过"事件ID+随机后缀"分片存储，如event_1234#shard17
   • 热点读采用本地缓存+一致性哈希，命中率提升40%+3

2. ‌批量查询优化‌：

   • 使用SSCAN迭代器模式，每次返回500-1000条记录，结合TCP Nagle算法优化带宽4
   • GC调优：Golang禁用GC（debug.SetGCPercent(-1)）或Java采用ZGC1

三、SSE连接管理

1. ‌心跳机制‌：

   • 动态心跳间隔：初始25s，根据网络质量指数退避（最大120s）4
   • 连接保活采用TCP KeepAlive（内核层）+应用层双校验3

2. ‌单机连接突破‌：

   • Linux内核调优：fs.nr_open=1000000 + net.ipv4.tcp_tw_reuse=14
   • 基于epoll的IO多路复用，单机支撑50万+连接（如Go的netpoll优化）1

四、容灾设计

1. 故障自动转移：采用Raft协议实现元数据一致性，切换时间<200ms2
2. 分级降级策略：事件优先保证核心业务通道（如支付事件）7

该设计通过分层解耦和动态调整机制，在蚂蚁集团类似场景中已验证支撑峰值500万QPS