polling与流媒体播放——概念与应用场景

在系统中，客户端和服务器之间进行通信。客户端提出请求，而服务器则向相应的客户端返回所需的数据。那么，我应该以什么频率来更新数据呢？这完全取决于你的目的以及你的系统需求。在这里，我们将讨论两个基本概念。polling与流媒体播放。

民意调查

所谓“定期请求数据”的过程，指的是客户端以固定的时间间隔（比如每x秒）来请求特定的数据，而服务器则会以常规的方式返回所需的数据。

在这些情况下，当客户端需要定期更新数据（从服务器获取数据）时，使用轮询方式可能并不适合你的架构设计。例如：你正在开发一个聊天应用，该应用中有许多用户，他们可以实时进行通信。系统设计专家你需要确保客户能够收到这些信息。更新/补充信息 立刻/瞬间（这里的“更新”指的是聊天记录、短信以及各种消息信息。）不过，投票功能则属于另一种情况。并非在所有地方都适用。作为ChatBox的一个例子，你需要获得以下内容：即时消息因为消息是从另一端发送的，而由于设置了x秒的延迟时间，你无法立即收到消息。因此，你的消息会经历较长的延迟时间。

Polling方式最适用的场景是，能够以固定的时间间隔获取温度信息，这些时间间隔可能为30秒或1分钟。

流式传输

流式传输是通过套接字来实现的。您可以在这里详细了解有关套接字的更多信息。简单来说，套接字就是一种文件，您的计算机可以通过与另一台计算机进行长连接的方式来读写这些文件。开放式连接直到有一台机器将其关闭为止。

例如：像WhatsApp、Instagram等类似的聊天应用的设计过程

你可以考虑减少这些时间间隔，转而使用轮询方式而不是流式传输方式。也就是说，你可以考虑这样做。缩短固定的时间间隔在10秒内，您可以为单个客户端发送多达20个请求。而对于数百万个客户端来说，这就会给服务器带来巨大的负担，使其难以同时处理这些请求。需要注意的是，虽然这样可以立即获得反馈，但这种做法并不理想，因为会为服务器带来更大的压力。

关键点：在 polling 模式中，对于服务器的响应，每个请求都会被发送出去。而在流式传输模式下，客户端会主动接收数据，而无需从服务器处获取任何外部请求。在服务器端，流式传输模式下，不会为每一个请求都等待数据的发送，而是会在检测到任何变化时立即推送数据。通过流式传输模式，用户可以实时进行聊天，而不会遇到任何延迟，同时每个客户端也不会需要每秒发送10到20个请求。

场景/情境

当……的时候客户端处理它比在轮询和流式传输情况下可能出现的各种情况要慢。

在流媒体中这些更新会在客户端上形成一条长长的队列。一旦客户端接收到第一个事件，服务器就会继续发送下一个事件，如此反复下去，直到处理完所有的事件为止。延迟由于加工质量不佳，所以才会出现这种情况。数据不会以任何零散的形式出现。

在民意调查中这些过程的更新需要一些时间。一旦其中一个过程完成之后，它就会立即开始处理下一个过程。请立即回答它。服务器始终努力保持稳定性，确保流媒体连接能够正常运行。如果无法进行写入操作，那么服务器会等待一段时间，同时可能会过滤掉一些不需要的更新信息。

注意：流式传输并不比轮询方式更好，而轮询方式或许比流式传输更合适。这完全取决于你的使用场景以及系统的特性。

一般规则：如果你需要实时更新数据，那么你应该选择使用流式传输方式。而如果你正在构建仪表板，比如用于监控股票价格之类的场景，那么你可能更倾向于使用轮询方式。因为在这种情况下，其实并不需要保持开放的连接，每30秒就可以获取一次数据更新。