-
GO千万级消息推送服务技术难点的解决方案
内核瓶颈
原理：减少网络小包（一般几百个字节）的发送
将同一秒内的N条消息，合并成1条消息
合并后，每秒推送次数只等于在线连接数
锁瓶颈
原理：大拆小
连接打散到多个集合中，每个集合有自己的锁
多线程并发推送多个集合，避免锁竞争
读写锁取代互斥锁，多个推送任务可以并发遍历相同集合
CPU瓶颈
原理：减少重复计算
json编码前置，1次消息编码+100万次推送
消息合并前置，N条消息合并后只编码1次
查看全部 -
GO千万级消息推送服务性能瓶颈
内核瓶颈
推送量大：100万在线*10条/秒=1000万条/秒
内核瓶颈：linux内核发送TCP的极限包频≈100万/秒
锁瓶颈
需要维护在线用户集合（100万在线），通常是一个字典结构
推送消息即遍历整个集合，顺序发送消息，耗时极长
推送期间，客户端仍旧正常上/下线，所以集合需要上锁
CPU瓶颈
浏览器与客户端通常采用json格式通讯
json编码非常耗费CPU资源
向100万在线推送1次，则需100万次json encode
查看全部 -
go原生的WebSocket的ReadMessage和WriteMessage方法不是线程安全的，但是Close方法是否线程安全的
查看全部 -
封装WebSocket内部原理
启动读协程，循环读取WebSocket，将信息投递到in channel
启动写协程，循环读取out channel，将信息写给WebSocket
查看全部 -
WebSocket的消息类型分为两种：文本类型和二进制类型
查看全部 -
WebSocke是HTTP协议Upgrade而来
查看全部 -
WebSocket传输原理
协议升级后，继续复用HTTP的底层socket完成后续通讯
message底层被切分成多个frame帧传输
编程时只需要操作message，无需关心frame
框架底层完成TCP网络I/O，WebSocket协议解析，开发者无需关心
查看全部 -
WebSocket通讯流程
查看全部 -
推模式
仅在数据更新时才需要推送
需要维护大量的在线长连接
数据更新后可以立即推送
查看全部 -
拉模式
数据更新频率低，则大多数请求是无效的
在线用户数量多，则服务端的查询负载很高
定时轮询拉取，无法满足时效性要求
查看全部 -
很有用啦啦
查看全部 -
试试查看全部
-
分布式架构——整体架构
查看全部 -
分布式架构——逻辑集群
查看全部 -
分布式架构——单机瓶颈
查看全部 -
千万级消息推送系统单机架构
查看全部 -
CPU瓶颈——优化方案
查看全部 -
锁瓶颈——优化方案
查看全部 -
内核瓶颈——优化方案
查看全部 -
技术难点——CPU瓶颈
查看全部 -
技术难点——锁瓶颈
查看全部 -
内核 瓶颈
查看全部 -
封装WebSocket内部原理
查看全部 -
封装WebSocket API原理
查看全部 -
封装WebSocket
查看全部 -
封装WebSocket
查看全部 -
完成WebSocket握手
查看全部 -
实现Http服务端
查看全部 -
服务端的技术选型
查看全部 -
WebSocket协议传输原理
查看全部 -
WebSocket协议传输原理
查看全部 -
客户端请求头中带upgrade字段表明需要升级http协议到websocket协议
WebSocket协议本身是基于Http协议调用完成的。
客户端首先发起一个Http请求到服务端，在header中带一个upgrade字段，告诉服务端把http协议升级为WebSocket协议。
服务端收到请求之后，就会给客户端一个握手的确认，switching的意思就是我允许你向WebSocket协议转换。一旦完成协商之后，客户端与服务端之间的连接是不会中断的。
客户端可以给服务端发送基于WebSocket的message消息
服务端也可以主动给客户端发送基于WebSocket的message消息
WebSocket中通信的单位就是Message消息。
查看全部 -
推模式：当服务端数据更新的时候，采去推送，没有必要做一些无用的轮询。
查看全部 -
拉模式：客户端定时轮询服务端的接口，获取最新的数据
查看全部 -
对WebSocket进行封装
查看全部 -
upgrade 提出升级类型为socket
查看全部 -
推模式特点
查看全部 -
第一天查看全部
-
将同一秒内的N条消息（小包），合并成1条消息
查看全部 -
内核瓶颈：linux内核发送TCP旳极限包频 100万/秒
查看全部 -
websocket协议传输原理查看全部
-
客户端请求头中带upgrade字段表明需要升级到websocket协议
查看全部 -
服务端推模式的特点查看全部
-
客户端拉模式的缺点
查看全部 -
测试测试测试测试测试测试
查看全部
举报