我正在尝试像 facebook 一样进行实时通知。经过大量学习和搜索,我很困惑,请解释一下什么是对的,什么是错的..
请确保该网站可能拥有与 Facebook 相同数量的用户
- 我们是否可以通过长轮询进行实时通知?如果是,优点、缺点和限制是什么。
- 我们是否可以使用 websockets 进行实时通知?请注意用户数量可以与 facebook 相同。如果可以,优点、缺点和限制是什么。
- 如有其他方法请说明。
困惑
我在 web 上学到了多远,发现 Websocket
很好,但是打开连接的数量有限制(最大 5K),这意味着一次最大用户数只有 5K , 这比 facebook 的用户数少很多.. 如果我错了请解释。
你错了,基于 websocket 的解决方案不限于 5K 并发连接数。
根据Facebook Newsroom 2013 年 9 月,他们平均拥有约 7.27 亿日活跃用户,即每分钟约有 50.4 万独立用户访问 Facebook 页面。假设平均访问时间为 18 分钟(由 statisticbrain.com 研究),他们的通知基础设施必须能够 24/7 全天候服务大约 900 万 (18*504k) 个并发 TCP 连接。虽然这个数字是一个非常近似的数字,但它可以让您大致了解他们正在处理什么以及如果您要构建这样一个系统您必须处理什么。
您可以使用长轮询和 websockets 来构建您的实时通知系统。在这两种情况下,您都会遇到与您的操作系统相关的类似问题(针对基于 Unix 的系统的解释):
- 端口限制,一个 tcp 监听器套接字在其监听的同一 IP/端口上只能接受 2^16 个连接,因此您需要在多个端口和/或多个 IP 上监听地址。
- 内存,每个打开的连接至少使用一个文件描述符
在 What is the theoretical maximum number of open TCP connections that a modern Linux box can have 中阅读有关限制的更多信息
长轮询与 Websockets:
长轮询解决方案中的每个轮询都需要一个新的 HTTP 请求,这需要比保持 websocket 连接事件所需的带宽更多的带宽。此外,通知作为 HTTP 响应返回,从而产生新的轮询请求。虽然 websocket 解决方案在带宽和系统资源消耗方面可以更有效,但它有一个主要缺点:缺乏浏览器支持。
根据手头的统计数据,仅 websocket 的解决方案会忽略大约 20-40% 的访问者(来自 statscounter.com 的统计数据)。为此,开发了不同的服务器库,将连接 的概念从“物理”底层传输模型中抽象出来。因此,更多现代浏览器使用 websockets 创建连接,而旧版浏览器回退到替代传输方式,例如HTTP 长轮询、jsonp 轮询或 flash。此类库的突出示例是 Sock.js和 Socket.io .