在可伸缩的客户机-服务器应用程序上是否使用多线程
本文关键字：是否 程序上 多线程 应用程序 应用 可伸缩 客户机 服务器 | 更新日期: 2023-09-27 18:19:17
几年前，我开发了一个服务器应用程序(c#， . net 4.0)，它有多个客户端可以连接到它。我这样做的方法是为每个连接创建一个线程，并维护这些连接的列表。当我测试这个应用程序时，它处理了全国50个客户的连接。它运行正常(从我看到的)。
我的问题是:
- 对于一个可扩展的解决方案，多线程是一个可行的解决方案来处理多个连接到不同的客户端，或者我应该在同一个线程上处理所有的连接?
- 在。net下，线程和线程的数量是否有限制? 在。net中使用线程有缺点吗?
我知道这有点模糊，但是自从我前段时间开发了这个项目以来，我已经忘记了一些更复杂的细节。我有兴趣在。net中为服务器应用程序开发一个可扩展的解决方案，并想从一开始就知道我以前的方法是否有改进的地方。
UPDATE 1
我没有使用线程轮询实例化。我实际上为一个方法创建了一个线程(让我们称之为方法threadLife)。
在threadLife中，我有一个while(true)语句，等待来自客户端的消息。在while中，我会等待客户端发送消息(因此while被阻塞，直到我收到消息)
在我的应用程序中，连接是相当稳定的(即客户端将保持连接很长一段时间)，所以连接保持活跃，直到客户端断开(没有关闭每条消息后的连接，我会收到非常频繁的消息，让我知道客户端状态)
每个连接一个线程不是一个可扩展的解决方案。
为了更好地扩展，应该专门使用异步套接字方法。问题是是在一个线程上复用它们还是使用线程池。线程池可以比多路复用更好地扩展，但是它引入了多线程的复杂性。
许多开发人员试图同时学习套接字编程和多线程，这实在是太多了。
可以使用消息队列、负载平衡、调度等。没有单一的答案。有些解决方案适合某些问题，有些则不适合。
好的起点可以是:
- ØMQ文档
- 警告:不稳定范式!
- 推送框架技术架构
每个连接一个线程是不可伸缩的。
我建议一个线程可以处理一组连接的客户端。如果连接的客户机数量增加，服务器应用程序应该能够添加尽可能多的线程来处理增加的数量。如果事情继续增长，那么其他服务器实例也会继续增长。与其让线程做所有的事情(就像应用程序实例所做的那样)，不如让一些专用的线程分别处理相同的任务，并以同步的方式共享内存中的数据。
这就是IIS的工作方式。通过控制面板可以管理工作进程的数量、线程的数量和线程池的数量。
我记得OpenSim项目(一个虚拟世界平台)是这样运行的:每个连接的客户端一个线程。它已经按照上面解释的方式进行了重构。
显然你已经很好地开始了多线程。也许这本免费的电子书会帮助你深入挖掘。
当我开始使用多线程时，我一开始很难理解它的意思是同时执行相同的代码，主要是在同一个实例。