如何在重新连接时将上下文传输到WebSocket会话？

Question

我正在使用WebSockets在C＃，ASP.NET和.NET framework 4.5中开发Web应用程序。为了规划未来的可扩展性，应用程序池可以选择Web园，以便在我的单个开发机器上模拟多个Web服务器。

我遇到的问题是如何处理websocket端的重新连接。最初创建新的websocket会话时，客户端浏览器可以间接锁定SQL数据库中的记录。但是当连接丢失时，我的老板希望浏览器尝试重新连接到websocket服务器会话的相同的实例，这样它就不需要重新锁定任何东西了。 / p>

我不知道这样的事情是否可行，因为重新连接负载均衡器将随机地＃34;选择要处理新连接的Web服务器。我正在考虑解决这个问题，但它并不是很干净：

1. 客户端在服务器A上打开初始websocket连接并锁定记录。
2. 客户暂时失去互联网连接，websocket关闭。 （重要的是要注意，服务器端将在它之前等待最多60秒，然后处理＆＃34;本身;因此，SQL记录将保持锁定状态，直到60秒为止。）
3. 客户端互联网连接已恢复并重新连接到网站，但这次是在服务器B上。
4. 服务器B发现此上下文最初是在服务器A上连接的;因此，将会话转移到服务器A。
5. 服务器A检查进程ID以查看它是否在正确的工作进程中运行（如果是Web园）。
6. 服务器A找到了初始实例并处理连接。

我尝试使用谷歌搜索这个问题，但它似乎不是一个非常常见的问题，因为我不认为大多数websocket网络应用程序保持记录锁定的时间长于我的应用程序（这可能取决于一小时）。

提前感谢您的所有帮助！

2016年3月15日更新

我希望Server.TransferRequest会有所帮助，但它似乎不适用于网络套接字。有人会知道如何最好地将websocket上下文从一个进程转移到另一个进程吗？

Answer 1

首先，您可能需要重新检查为什么您长时间锁定记录并要求客户端每次都返回到同一服务器。这不是通常类型的高规模Web架构，也许您只是因为这个要求而需要重新连接到相同的服务器，或许您应该重新考虑如何设计以便您的应用程序可以正常工作用户连接的主机。

如果您可以删除该要求，那么这肯定会简化对大量用户和服务器的扩展。然后，您可以随后实施本地缓存和半粘连接作为性能增强，但只有在您将需求发布到100％的时间后才能连接到同一主机。

如果您始终坚持要求始终连接到同一主机，那么您最终将需要某种粘性负载平衡。有很多不同的方案。有些是由服务器前面的网络基础设施驱动的，有些是由服务器驱动的，有些甚至是客户端驱动的。他们都有不同的权衡。以下简要介绍了一些方案：

1. 硬件，网络负载均衡器。在这里，您有一个相当透明的机制，通过该机制，硬件负载均衡器（实际上只是在自定义硬件上运行的软件）位于您的Web服务器场并使用各种技术来确保给定用户最初连接到它的任何服务器将在后续连接上重新连接。这可以基于各种方案（IP地址，cookie值等）作为识别特定用户的关键，并且它通常具有许多可能的配置以便它如何工作。

2. 代理负载均衡器。这实际上是硬件负载均衡器的全部软件版本。这里，代理位于服务器场的前面，并根据某种算法（IP地址，cookie值等）将连接指向特定服务器。

3. 服务器重定向。此处将传入连接随机分配给服务器。在连接时，服务器确定连接应该连接到的位置，返回302重定向到实际主机，导致客户端重新连接到正确的服务器。这涉及少一层基础设施（没有物理负载平衡器），但将不同的服务器端点暴露给外部世界，而前两个选项则没有。

4. 客户端选择算法。这里，客户端了解各种服务器端点，并使用算法进行编码，以便为该用户一致地选择一个。它可以是userID的哈希值，然后将其划分为服务器桶池，最终结果是客户端最终选择特定的DNS名称，例如cl003.myserver.com，然后连接到该名称。此选择需要最少的工作服务器端，因此可以更简单地实现，但它需要更改客户端代码才能修改算法。

有关Amazon Web Services粘性负载平衡的文章，让您了解一种机制的工作原理，您可以阅读：Elastic Load Balancing: Configure Sticky Sessions for Your Load Balancer。

这是另一篇关于如何nginx proxy is configured for sticky load balancing。

的文章

您可以在Google搜索＆＃34;粘性负载均衡＆＃34;中找到许多其他文章。

讨论各种方案的利弊是长时间讨论的主题，其中一些涉及对基础设施的更具体要求和具体能力的了解。