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

Question

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

---

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

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

混乱

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

Answer 1

你错了，基于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.js和Socket.io。