-
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 億條/秒
查看全部
舉報