在系统中，客户端和服务器一起通信，其中客户端请求和服务器用请求的数据回复相应的客户端。现在可以选择我需要以什么频率更新数据？好吧，这完全取决于您的目的和系统。在这里，我们将讨论轮询和流传输两个基本概念。
轮询
它被定义为客户端以固定时间间隔（可能每 x 秒）请求特定数据的过程，并且服务器返回带有所需数据的通常响应。
在这些场景中，客户端需要在即时模式下定期更新数据（从服务器获取数据），轮询可能不会使您的架构受益。例如：您正在构建一个聊天应用程序，其中有许多旨在实时相互通信的客户端。作为系统设计专家，您需要确保客户端即时获得更新（这里的更新是指聊天、txt、消息）。但是Polling并不是处处都适合作为Chatbox的例子，你需要得到对方发送的即时消息，但是由于设置了x秒的间隔，你无法获得消息的即时感觉，你的消息会感觉很多延误
轮询的最佳适用性可以是每隔 30 秒/1 分钟定期更新温度。
流媒体
流式传输是通过套接字完成的，您可以在此处详细了解套接字。在外行人的术语中，套接字是一个文件，您的计算机可以在与另一台计算机的长宽连接中写入/读取，这是一个开放的连接，直到一台机器将其关闭。
例如：设计一个聊天应用程序就像 WhatsApp/Instagram 和许多其他应用程序
在这里你可能会想到一个选择，减少设置的时间间隔，使用 Polling 而不是 Streaming，也就是说，你可能会想到将设置的时间间隔减少到 1 秒/0.5 秒，而不是在 10 秒内为单个客户端请求多达 20 个请求，对于数百万客户端，这会给我们的服务器同时处理这些请求带来问题。在这里您需要注意，您可能会在消息中获得即时体验，但这并不是最佳选择，因为它会给服务器带来更多负载。
轮询与流媒体
关键点：在轮询中，对于服务器的响应，发送每个请求，但在流中，客户端公开侦听，没有来自服务器的外部数据请求。在服务器端，对于流式传输，它不会等待每个请求发送数据，而是会在注意到任何更改时推送数据。通过流媒体，您可以获得即时聊天体验，没有任何延迟，每个客户端每秒发送 10-20 个请求。
场景
当客户端处理慢于Polling和Streaming的情况下可能会出现不同的场景。
在流更新将形成在客户端的长队，一旦它接收到的第一个事件服务器将在下一个连续发送下一个，然后到年底，将有一个延迟，由于处理不佳，但有赢”数据中没有任何形式的零星。
在轮询中，进程需要一些时间来更新。一旦它完成一个，它就会要求另一个并立即回答。服务器总是试图保持健壮并保持流连接正常工作；如果它不能写入，它会等待并可能过滤更新。
注意：流并不比轮询好，轮询可能比流好，这完全取决于您的用例和系统。
一般规则：如果您需要立即更新您的数据（实时更新），那么您想要使用流媒体，并且如果您正在构建一个仪表板而不是监控股票价格或在这里有这样的用例，您可能更喜欢轮询，因为没有真正需要开放连接，每 30 秒就可以更新一次数据。