如何发出像Facebook这样的实时通知? [英] How to make a realtime notification like facebook?

问题描述

我正在尝试像Facebook一样实时发出通知.在学习和搜索很多内容后，我非常困惑，请向我解释什么是正确的，什么是错误的..

I am trying to make a realtime notification just like facebook.After learning and searching alot i m very confuse please explain me what is right and what is wrong..

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

• 我们可以通过长时间轮询来发出实时通知吗?如果可以，优点，缺点和局限性是什么?
• 我们是否可以通过websocket进行实时通知?请注意，用户数量可以与facebook相同.如果是，则优点，缺点和局限性是什么.
• 如果还有其他方法，请解释.

我在网络上学习了多远，发现Websocket很好，但是开放连接的数量有一个限制(最大5K)，这意味着在一次最大用户数仅为5K的情况下，这要少得多比facebook的用户数多.如果我错了，请解释.

How Far I learn in web and found that Websocket is good but there is a limitation(Max 5K) in number of open connection which means that at a time the max number of user is just 5K,this is very less than facebook's number of users.. if I m wrong please explain.

推荐答案

您错了，基于Websocket的解决方案不仅限于5K并发连接.

You're wrong, a websocket based solution is not limited to 5K concurrent connections.

根据 Facebook新闻室，他们在9月平均每日活跃用户约为7.27亿2013年，即每分钟访问Facebook页面的约504k唯一用户.给定平均访问时间为18分钟(由 statisticbrain.com 搜索)，他们的通知基础结构必须能够服务约900万个(18 * 504k)并发TCP连接24/7.尽管这个数字非常接近，但是却可以很清楚地了解他们要处理的内容以及要构建这样一个系统时必须处理的内容.

According to the Facebook Newsroom they have about 727 million daily active users on average in September 2013 or about 504k unique users that hit the Facebook page every minute. Given an average visit time of 18 minutes (researched by statisticbrain.com) their notification infrastructure must be able to serve about 9 million (18*504k) concurrent TCP connections 24/7. Although this number is a very far approximation it gives a far idea of what they are dealing with and what you have to deal with if you are going to build such a system.

您可以使用长时间轮询以及网络套接字来构建实时通知系统.在这两种情况下，您都会遇到与操作系统(说明适用于基于Unix的系统)相关的类似问题:

You can use long polling as well as websockets to build your realtime notification system. In both cases you face similar problems which are related to your OS (Explanations are for a Unix based system):

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

• limitation of ports, one tcp listener socket can only accept 2^16 connections on the same IP/Port it is listening, so you'll need to listen on multiple ports and/or multiple IP adresses.
• memory, every open connection uses at least one file descriptor

在长轮询与Websockets

Long-polling vs. Websockets:

您的长轮询解决方案中的每个轮询都需要一个新的HTTP请求，该请求所需要的带宽超过了保持Websocket连接存活所需的带宽.此外，该通知作为HTTP响应返回，从而导致新的轮询请求.尽管Websocket解决方案在带宽和系统资源消耗方面可以更有效，但它具有一个主要缺点:缺乏浏览器支持.

Every poll in your long-poll solution requires a new HTTP request, which requires more bandwidth than what is needed to keep a websocket connection alive. Moreover the notification is returned as a HTTP response resulting in a new poll request. Although the websocket solution can be more efficient in terms of bandwidth and consumption of system resources, it has a major drawback: lack of browser support.

根据当前的统计信息，仅基于Websocket的解决方案会忽略大约20-40％的访问者(来自 statscounter.com的统计信息).因此，开发了不同的服务器库，这些服务器库从物理"基础传输模型中抽象了连接"的概念.结果，更多现代的浏览器使用websocket建立连接，而较旧的浏览器后退与其他传输方式，例如HTTP长轮询，jsonp轮询或闪存.此类库的突出示例是 Sock.js 和 Socket.io .

Depending on the stats at hand, a websocket-only solution ignores about 20-40% of your visitors (stats from statscounter.com). For this reason different server libraries were developed that abstract the concept of a connection away from the 'physical' underlying transport model. As a result more modern browsers create the connection using websockets and older browsers fall back to an alternative transport such as e.g. HTTP long polling, jsonp polling, or flash. Prominent examples of such libraries are Sock.js and Socket.io.

这篇关于如何发出像Facebook这样的实时通知?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！