C# c/s 网络通信 大数据传输方式选择

[u010018424]

上位机（主控室）与多个下位机通信（TCP/ip通信），接收多个下位机（大约100台）传过来的数据，每台下位机的数据量大约100k/s。

两种接收方式：
1.上位机开辟多线程，每个线程分别与每台下位机相连。下位机分别实时主动送数据，100个线程并行传输数据会不会有问题？
2.上位机采用轮询方式，向某台下位机要数据，单线程即可解决，这样不会出现并行传输数据的问题，但是需要在每台下位机装配IP主节点存储下位机的数据，增加了成本。

由于现在只实现了上位机与两台下位机连接，采用的方式1，目前对100台下位机连接时有疑惑和顾虑。

请问上述数据接收处理方式是否合理？ 有没有更合理的接收方式？

[u010018424]

引用 1 楼 sp1234 的回复:

[quote=引用 楼主 u010018424 的回复:] 1.上位机开辟多线程，每个线程分别与每台下位机相连。下位机分别实时主动送数据，100个线程并行传输数据会不会有问题？

服务器端通讯应该是异步并发的，就算是10万个下位机与上位机进行实时通讯，在某一个瞬间，你也不能说有100001个线程在那里死循环着。可能一个线程都不用，或者可能最多（瞬间）用20个线程，总之不能纠结那么多线程数。 有些人完全是滥用线程去胡写代码，这可能跟 msdn 上某个具体通讯语句的特殊“范例”的误导有关，也可能是跟10几年前某些 java 书上的例子有关。 比如说，.net 中对属性的改变进行监听，实际上应该使用的编程模式是 INotifyPropertyChanged 接口。而有些人偏偏说“我用一个死循环执行的线程，不是仅能‘监控’变量值了吗？”。再比如说，当用将桌面上的窗口拖到桌面边缘时应该将窗口收缩起来，有的人就会滥用一个50毫秒的定时器不断轮询判断窗口是否在桌面边缘，而实际上应该使用的方式是捕获窗口被拖动的事件去判断..... 基于滥用轮询、线程的方式编程，这从出发点就是错的。假设你只是1、2个线程滥用，也许你觉得没有什么。顶多就是电脑似乎卡了一点点，“还能忍受”。但是你需要迅速从2个线程过渡到“1万个线程”的情况，此时你不可能随手有20G内存、1000G Hz主频的CPU，你还是得老老实实地使用“事件驱动”的异步编程思路。此时一个线程都不用，根本就跟线程数无关。 100个下位机跟上位机实时连接，这不占用1个线程。你怎么反而能说要占用100个线程呢？可见你现在程序该立刻重写。[/quote] 谢谢哥哥的详细耐心的回答。其实开始用多线程编程就是图省事，保证数据独立、安全。拿方式1来说，说是下位机主动送，其实只有我主动去读，下位机才送过来数据。在每个线程中收到的数据，进行异步存储和显示（初始时用的委托事件，但是数据量大，处理不过来），然后再读下一次。开的线程会一直连续接收数据，不是短链接。

[u010018424]

引用 4 楼 intraweb 的回复:

用消息队列。 下位机往上位机发数据，上位机用一个线程收数据，然后不做任何处理丢到消息队列中，上位机后台再开N个线程去处理消息队列中的任务。 如果担心一个线程接收慢，多开几个也行，搞个线程池。 上面的模型对付数百并发足够了，如果并发几千几万，可以参考完成端口模型。

谢谢，我去学习一下消息队列

[u010018424]

引用 3 楼 sp1234 的回复:

你不用调用人家的方法，人家回回调你的 --> 你不用调用人家的方法，人家会回调你的 线程这个高大上的词儿让一些人疯狂。msdn 上某个通讯语句的错误的阻塞式编程“范例”也助长了这种任性滥用线程的情况。实际上，如果只是在偶尔仅仅有1、2个连接且1分钟才需要连接一次的短连接的例子，才可能随便那样编程。

http://bbs.csdn.net/topics/391034226 我的问题和连接里的问题差不多，都是长连接，不用开多线程吗？

[以专业开发人员为伍]

引用 楼主 u010018424 的回复:

1.上位机开辟多线程，每个线程分别与每台下位机相连。下位机分别实时主动送数据，100个线程并行传输数据会不会有问题？

服务器端通讯应该是异步并发的，就算是10万个下位机与上位机进行实时通讯，在某一个瞬间，你也不能说有100001个线程在那里死循环着。可能一个线程都不用，或者可能最多（瞬间）用20个线程，总之不能纠结那么多线程数。 有些人完全是滥用线程去胡写代码，这可能跟 msdn 上某个具体通讯语句的特殊“范例”的误导有关，也可能是跟10几年前某些 java 书上的例子有关。 比如说，.net 中对属性的改变进行监听，实际上应该使用的编程模式是 INotifyPropertyChanged 接口。而有些人偏偏说“我用一个死循环执行的线程，不是仅能‘监控’变量值了吗？”。再比如说，当用将桌面上的窗口拖到桌面边缘时应该将窗口收缩起来，有的人就会滥用一个50毫秒的定时器不断轮询判断窗口是否在桌面边缘，而实际上应该使用的方式是捕获窗口被拖动的事件去判断..... 基于滥用轮询、线程的方式编程，这从出发点就是错的。假设你只是1、2个线程滥用，也许你觉得没有什么。顶多就是电脑似乎卡了一点点，“还能忍受”。但是你需要迅速从2个线程过渡到“1万个线程”的情况，此时你不可能随手有20G内存、1000G Hz主频的CPU，你还是得老老实实地使用“事件驱动”的异步编程思路。此时一个线程都不用，根本就跟线程数无关。 100个下位机跟上位机实时连接，这不占用1个线程。你怎么反而能说要占用100个线程呢？可见你现在程序该立刻重写。

[以专业开发人员为伍]

电脑要干什么异步的事情，首先想到的是“注册好事件捕获机制”。你不用调用人家的方法，人家回回调你的。 如果你的思路就是滥用“线程”，那就没救了。

[以专业开发人员为伍]

你不用调用人家的方法，人家回回调你的 --> 你不用调用人家的方法，人家会回调你的 线程这个高大上的词儿让一些人疯狂。msdn 上某个通讯语句的错误的阻塞式编程“范例”也助长了这种任性滥用线程的情况。实际上，如果只是在偶尔仅仅有1、2个连接且1分钟才需要连接一次的短连接的例子，才可能随便那样编程。

[szjay]

用消息队列。 下位机往上位机发数据，上位机用一个线程收数据，然后不做任何处理丢到消息队列中，上位机后台再开N个线程去处理消息队列中的任务。 如果担心一个线程接收慢，多开几个也行，搞个线程池。 上面的模型对付数百并发足够了，如果并发几千几万，可以参考完成端口模型。