不重复造轮子。

技术难点

内核瓶劲

• 推送量大：100W在线 * 10条/每秒 = 1000W条/秒
• 内核瓶颈：linux内核发送TCP的极限包频 ≈ 100W/秒

锁瓶劲

• 需要维护在线用户集合（100用户在线），通常是一个字典结构
• 推送消息即遍历整个集合，顺序发送消息，耗时极长
• 推送期间，客户端仍然正常的上下线，集合面临不停的修改，修改需要遍历，所以集合需要上锁

CPU瓶颈

• 浏览器与服务端之间一般采用的是JSon格式去通讯
• Json编码非常耗费CPU资源
• 向100W在线推送一次，则需100W次Json Encode

优化方案

内核瓶颈

• 减少网络小包的发送，我们将网络上几百字节定义成网络的小包了，小包的问题是对内核和网络的中间设备造成处理的压力。
• 方案是将一秒内N条消息合并成1条消息，合并后，每秒推送数等于在线连接数。

锁瓶颈

• 大锁拆小锁，将长连接打散到多个集合中去，每个集合都有自己的锁，多线程并发推送集合，线程之间推送的集合不同，所以没有锁的竞争关系，避免锁竞争。
• 读写锁取代互斥锁，多个推送任务可以并发遍历相同集合

CPU瓶颈

• 减少重复计算，Json编码前置，1次消息编码+100W次推送，消息合并前置，N条消息合并后，只需要编码一次。

单机架构

单机架构

最外层是在线的长连接，连接到服务端后，打散到多个集合里面存储，我们要发送的消息呢，通过打包后，经过json编码，被多个线程或协程分发到多个集合中去，最终推给了所有的在线连接。

单机瓶颈

• 维护海量长连接，会花费不少内存
• 消息推送的瞬时，消耗大量的CPU
• 消息推送的瞬时带宽高达400-600Mb（4-6Gbits），需要用到万兆网卡，是主要瓶颈

集群

部署多个节点，通过负载均衡，把连接打散到多个 服务器上，但推送消息的时候，不知道哪个直播间在哪个节点上，最常用的方式是将消息广播给所有的网关节点，此时就需要做一个逻辑集群。

逻辑集群

• 基于Http2协议向gateway集群分发消息（Http2支持连接复用，用作RPC性能更佳，即在单个连接上可以做高吞吐的请求应答处理）
• 基于Http1协议对外提供推送API（Http1更加普及，对业务方更加友好）

整体架构

集群整体架构

任何业务方通过Http接口调用到逻辑集群，逻辑集群把消息广播给所有网关，各个网关各自将消息推送给在线的连接即可。