千万级弹幕系统必须分层解耦、水平扩展，禁用阻塞操作，采用二进制协议、一致性哈希分片、客户端驱动心跳及原子化连接清理。
千万级弹幕系统不能靠单机 std::queue + epoll 硬扛
直接用 C++ 写个带 std::queue 和 epoll 的服务，撑不过 5 万并发连接——不是代码写得不好，是架构层面就卡在单点瓶颈上。内存带宽、内核 socket 数、TCP 连接跟踪表（conntrack）、网卡中断聚合能力，全会在 10 万连接左右开始明显退化。真实线上系统必须拆：连接层、分发层、状态层分离，且每层可水平伸缩。
libevent 或 io_uring 不是银弹，选型要看内核版本和部署环境
用 libevent 可快速落地，但默认配置下每个连接仍占约 2.5KB 内存（含 buffer + event 结构），千万连接即 24GB 仅用于连接上下文；io_uring 内存更省、延迟更低，但要求 Linux ≥ 5.1，且需手动处理 IORING_OP_RECV 的 partial read、buffer 生命周期管理。生产环境若混合 CentOS 7（内核 3.10）和 Ubuntu 22.04，建议先统一用 libev + 自定义 slab 分配器，避免 malloc 频繁抖动。
- 禁用
evbuffer自动扩容，预设固定大小（如 8KB）并复用 - 关闭 Nagle：
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)) - 对弹幕消息做二进制协议压缩（如 length-delimited + snappy），别传 JSON 字符串
弹幕广播不能走“一发十连”，要用 topic 分片 + fanout 缓存
一个热门直播间有 300 万人观看，若每次弹幕都遍历 300 万个 connection* 指针再逐个 write，CPU cache miss 率飙升，吞吐必然崩。实际做法是：按直播间 ID 做一致性哈希分片到 N 个 fanout 节点，每个节点只维护本分片内的在线用户列表，并用 ring buffer 存储最近 10 秒弹幕（供新用户 Join 时补帧）。
- 分片数建议设为 256～1024，避免某直播间独占整个分片导致热点
- 用户上线时，通过 Redis HyperLogLog 估算当前房间人数，决定是否触发分片迁移
- 弹幕消息体必须带
timestamp和seq_id，客户端靠这个做去重与乱序补偿
心跳与断线重连逻辑必须由客户端驱动，服务端只做超时驱逐
服务端主动 ping 客户端？千万连接下每秒几万次定时器 tick 就能吃满一个核。正确做法是：客户端每 15 秒发一次 PING 包（无 payload，仅 opcode），服务端收到后刷新该连接的 last_active_ts；后台用单个 timerfd 每秒扫描一次连接哈希表，只对 now - last_active_ts > 30s 的连接调用 close() 并清理资源。
立即学习“C++免费学习笔记（深入）”；
- 禁止在
on_message回调里做任何阻塞操作（如查 DB、调 HTTP） - 连接清理必须原子：先从用户索引 map 中 erase，再 close fd，最后释放内存，顺序错一步就内存泄漏或 double-free
- 客户端重连时需携带上次断开前的
seq_id，服务端据此决定是否补推或跳过
真正难的不是写通一个能发弹幕的 demo，而是让每个连接的生命周期、每条消息的跨节点路由、每次心跳的低开销判定，都在微秒级可控——这些细节堆起来，才叫「支持千万在线」。
