-
webSocket推送
查看全部 -
推模式：服务端推送消息到浏览器
查看全部 -
拉模式与推模式的区别
拉模式：前端轮询的调用接口
查看全部 -
aaa
查看全部 -
整体架构！
查看全部 -
网关集群！
查看全部 -
单机瓶颈
维护海量长连接会花费不少内存
消息推送瞬时消耗大量 CPU 资源
消息推送瞬时帯宽高达 400~600MB (4-6 Gbits），是主要瓶颈！
查看全部 -
单机架构！
查看全部 -
内核瓶颈 - 优化原理
减少网络小包的发送
内核瓶颈 - 优化方案
将同一秒内的 N 条消息，合并成 1 条消息
合并后，每秒推送次数只等于在线连接数
锁瓶颈 - 优化原理
大拆小
锁瓶颈 - 优化方案
连接打散到多个集合中，每个集合有自己的锁
多线程并发推送多个集合，避免锁竞争
读写锁取代互斥锁，多个推送任务可以并发遍历相同集合
CPU 瓶颈 - 优化原理
减少重复计算
CPU 瓶颈 - 优化方案
json 编码前置，1 次消息编码 + 100 万次推送
消息合并前置，N 条消息合并后只编码 1 次
查看全部 -
CPU 瓶颈
浏览器与服务端通常采取 json 格式通讯
json 编码非常耗费 CPU 资源
向 100 万在线推送 1 次，则需 100 万次 json encode
查看全部 -
锁瓶颈
需要维护在线用户集合（100 万在线），通常是一个字典结构
推送消息即遍历整个集合，顺序发送消息，耗时极长
推送期间，客户端仍旧正常上/下线，所以集合需要上锁
查看全部 -
內核瓶颈
推送量大：100万在线 * 10条/秒 = 1000万条/秒
内核瓶颈：linux 内核发送 TCP 的极限包频 ～ 100 万/秒
查看全部 -
3 个性能瓶颈
內核瓶颈
锁瓶颈
CPU 瓶颈
查看全部 -
內部原理
启动读协程，循环读取 WebSocket，将消息投递到 in channel
启动写协程，循环读取 out channel，将消息写给 WebSocket
查看全部 -
API 原理
SendMessage 将消息投递到 out channel
ReadMessage 从 in channel 读取消息
查看全部 -
隐藏细节，封装 API
封装 connection 结构，隐藏 ebsocket/底层连接
封装 connection 的 API，提供 Send/Read/Close 等线程安全接口
查看全部 -
缺乏工程化的设计
其他代码模块，无法直接操作 Websocket 连接
Websocket 连接非线程安全，并发读/写需要同步手段
查看全部 -
Websocket 是 HTTP 协议 Upgrade 而来
使用 http 标准库快速实现空接口：/ws
查看全部 -
NodeJS：单线程模型，推送性能有限
C/C++：TCP 通讯、Websocket 协议实现成本高
Go！
多线程，基于协程模型并发
成熟的 WebSocket 标准库，无需造轮子
查看全部 -
Heartbeat
查看全部 -
Upgrade: websocket
查看全部 -
抓包观察
使用 chrome 开发者工具，观察 WebSocket 通讯流程
查看全部 -
传输原理
协议升级后，继续复用 HTTP 的底层 socket 完成后续通讯
message 底层被切分成多个 frame 帧传输
编程时只需操作 message，无需关心 frame
框架底层完成 TCP 网络 I/O，WebSocket 协议解析，开发者无需关心
查看全部 -
通讯流程！
查看全部 -
基于 WebSocket 推送
浏览器支持的 socket 编程，轻松持服务端的长连接
基于 TCP 可靠传输之上的协议，无需开发者关心通讯细节
提供了高度抽象的编程接口，业务开发成本较低
查看全部 -
推模式
仅在数据更新时才需要推送
需要维大量的在线长连接
数据更新后可以立即推送
查看全部 -
拉模式
数据更新频率低，则大多数请求是无效的
在线用户数量多，则服务端的查询负载很高
定时轮询拉取，无法满足时效性要求
查看全部 -
N 个直播间
推送频率：N*10 亿条/秒
查看全部 -
1 个直播
在线人数：100 万
发送弹幕：1000 条/秒
推送频率：100 万*1000 条/秒 = 10 亿条/秒
查看全部
举报