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

Question

我试图像facebook一样做一个实时通知.经过学习和搜索很多我非常困惑请解释我什么是对的,什么是错的..

---

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

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

混乱

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

Answer 1

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

根据Facebook新闻室,他们在2013年9月平均每天有大约7.27亿活跃用户,或者每分钟点击Facebook页面的大约504,000个独立用户.鉴于平均访问时间为18分钟(由statisticbrain.com研究),他们的通知基础架构必须能够24/7全天候服务大约900万(18*504k)并发TCP连接.虽然这个数字非常接近,但是如果你要构建这样一个系统,它可以很好地理解它们正在处理什么以及你需要处理什么.

您可以使用长轮询和websockets来构建实时通知系统.在这两种情况下,您都面临与您的操作系统相关的类似问题(解释是针对基于Unix的系统):

• 对端口的限制,一个tcp监听器套接字只能在它正在侦听的同一IP /端口上接受2 ^ 16个连接,因此您需要监听多个端口和/或多个IP地址.
• 内存,每个打开的连接使用至少一个文件描述符

了解有关限制的更多信息现代Linux机器可以具有的理论最大开放TCP连接数是多少

长轮询与Websockets:

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

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