如何制作像facebook这样的实时通知?

时间:2014-01-13 06:28:18

标签: facebook websocket long-polling ratchet

我正试图像facebook一样进行实时通知。经过学习和搜索,我很困惑,请向我解释什么是对的,什么是错的。


请确保该网站可能拥有与Facebook相同数量的用户

  • 我们可以通过长轮询进行实时通知吗?如果是,优点,缺点和限制是什么。
  • 我们可以使用websockets进行实时通知吗?请注意用户数量可以与facebook相同。如果是,优点,缺点和限制是什么。
  • 如果还有其他方法请解释。

混乱

我在网上学到了多少,发现Websocket很好但是开放连接的数量有限制(最大5K),这意味着每次最大用户数只有5K,这是非常少于facebook的用户数量。如果我错了请解释。

1 个答案:

答案 0 :(得分:13)

你错了,基于websocket的解决方案不仅限于5K并发连接。

根据Facebook Newsroom,他们在2013年9月平均拥有约7.27亿活跃用户,或每分钟点击Facebook页面的约54万独立用户。鉴于平均访问时间为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

中的限制

Long-polling vs. Websockets:

长轮询解决方案中的每个轮询都需要一个新的HTTP请求,这需要比保持websocket连接所需的带宽更多的带宽。此外,通知作为HTTP响应返回,从而产生新的轮询请求。虽然websocket解决方案在带宽和系统资源消耗方面可以更高效,但它有一个主要缺点:缺乏浏览器支持

根据手头的统计数据,仅限websocket的解决方案会忽略约20-40%的访问者(来自statscounter.com的统计信息)。出于这个原因,开发了不同的服务器库,它们将连接的概念从“物理”底层传输模型中抽象出来。因此,更现代化的浏览器使用websockets和旧版浏览器后退来创建连接,以便替代传输,例如, HTTP长轮询,jsonp轮询或闪存。这些库的突出示例是Sock.jsSocket.io