实现Web Sockets的不同模式
WebSockets用于浏览器和服务器之间的实时通信。这些通信是双向的。因此它适合低延迟的应用，如聊天、实时多人游戏、应用内通知。
如果你是WebSockets的新手，我建议你看看我写的下面这篇文章，以便更好地了解它的工作原理。
然而，在这篇文章中，我将着眼于在实际使用WebSockets时的4种关键模式。
- 直接发送消息。
- 只有触发器。
- 单个发布者和多个订阅者。
- 多个发布者和订阅者。
1.直接发送消息
当客户端和服务器之间打开WebSocket连接时，它被认为是一个全双工连接。数据流是双向的。
在实现WebSockets时，保持连接开放并通过该链接直接发送消息/信息是很典型的。
例如，让我们看看一个聊天应用程序，如WhatsApp。当有人给你发信息的时候，你会在你的手机或桌面应用程序上收到它。你也可以即时回复这个消息，这将是实时发送和接收的。
使用这种模式，需要服务器一直保持WebSocket连接开放。然后，如果连接失败，客户端就应该用重试逻辑重新建立连接。
直接发送消息的优点
- 即时更新并传输更新中的所有信息。
- 客户端不需要轮询信息。服务器可以发送数据，它将立即提供给客户端 - 快速传递
直接发送信息的缺点
- 需要一直有一个活跃的连接。因此，它需要更多的服务器资源。
- 由于始终处于活动状态的连接，在客户端也会利用更多的资源。例如，一个有直接消息和开放连接的移动聊天应用程序会更快地消耗手机电池。
- 扩展和负载平衡是很难的，这需要一个后方通道来扩展。
- 只适合于每条消息的有效载荷较小的应用，因为实时发送较大的有效载荷会非常昂贵。
2.仅触发器
这种模式只在有新数据的时候向客户端发送通知，而 "不是数据本身"。
例如，假设你有一个仪表板来监控你的电子商务网站的订单。当一个客户下了一个新的订单，你的仪表盘会收到一个通知，说 "你有一个新的订单"。
一旦你点击这个通知，你的仪表板（客户端）将向服务器发送一个HTTP请求，以获取新订单的数据。
这种方法比直接发送消息成本低，因为较小的消息有效载荷是从WebSocket服务器发送的。
这样一来，始终处于活动状态的连接将只用于触发通知。
只使用触发器的优点
- 所需带宽较少，服务器负载较小，比直接发送所有信息的成本低。
- 有可能在不需要单独更新的情况下分批发送更新。
- 它可以触发通知，比如对于新的更新，与信息一起发送有效载荷是不现实的。
只使用触发器的缺点
- 与直接发送所有信息相比，实时性较差（涉及延迟），因为更新的信息只有在要求时才会被获取。
- 不适合有效载荷较小的应用（我们可以通过触发器发送），或者对整个信息周期要求低延迟的应用。
3.单个发布者--多个订阅者
这个名字表明了这个模式的作用。例如，一个发布者将发送更新，而多个订阅者则期望收到更新。这是通过事件完成的。
发布者触发事件，而订阅者听从事件。
这类似于用于聊天应用程序的模式，在那里有更多的当事人参与。
使用单个发布者--多个订阅者的优点
- 能够创建应用程序（例如，白板），用于有一个主持人和许多听众的团队协作。
- 不会出现你需要在应用层面上处理的并发问题。
- 实时向许多人发送更新。
使用单一发布者--多个订阅者的缺点
- 只允许一个发布者。不适合团队活动。
4.多个发布者--多个订阅者
这是一种从单一发布者--多个订阅者增强的模式。与上述模式不同的是，使用这种模式时，允许许多发布者。
因此，这适用于需要团队协作的应用程序。
使用多发布者-多订阅者的优点
- 允许多于一个发布者。适用于团队活动。
- 向所有订阅的用户实时发送更新信息，对事件沟通很有效。
使用多个发布者--多个订阅者的缺点
- 会有大量的事件排放。在整个合作过程中，需要保持WebSocket的活动连接。因此，需要更多的服务器资源。
- 需要在应用层面上处理并发问题。
- 需要高效的持久化消息的方法（例如：流处理）。
总结
我们讨论了在实践中使用WebSockets时可以使用的几种模式。使用的正确方法取决于你的应用需求。
在选择遵循的模式之前，你必须权衡利弊，分析资源利用率，并根据所需的实时更新的重要性来决定。
请在下面的评论中告诉我你在你的应用程序中使用了哪种模式。谢谢你的阅读!
