网络系统架构疑问

时间:2023-01-29 19:40:55
现在要做个C/S系统,客户端可能要2000个,客户端与服务器不需要一直连接,只要有数据再连接。客户端发送数据频率从10分钟一次到1周一次都有,每次发送数据从60K到1K的范围。客户端的数据在保证数据完整性的前提下尽量实时。请问这个服务器的架构采用哪种方式较好。敬请高人指点。

11 个解决方案

#1


间隔时间长又要保证发送的实时性,那么可以进行预连接,即你可能需要12:30:00进行发送,而你可以在12:27:00就开始连接,到点就可以发送了.就2000个连接,中间还有部分间隔时间那么长,使用任何一种架构都不存在问题.

#2


可以先起几个线程预连接,在超过某个数值的客户端进行连接的时候,再起几个线程满足,这样可以减少开销,具体怎么实现,期望有能人出面来解答

#3


你只有2000个客户端的话,数据量有这么小,那就是基本没什么压力了,这样的话,保证实时性,对号的就是长连接。

#4


2000个,还小?各位高人。多谢。希望有更具体的实施方法。

#5


引用 4 楼 dyne08 的回复:
2000个,还小?各位高人。多谢。希望有更具体的实施方法。

2000只算是普通的量.关键要看应用的复杂度,对于复杂应用,比如企业信息化系统之类的2000个倒算是相当大了.

#6


引用 4 楼 dyne08 的回复:
2000个,还小?各位高人。多谢。希望有更具体的实施方法。


还要看你的连接做什么事.如果一直都有数据通讯,每秒都有大量数据通讯,这当然有压力.你的客户端又不是同时一起连接进去(发送频率从10分钟到1周).如果同时连接进来,同时一起发送60K数据让服务器接收,这样服务器自然有压力,但你的情况基本不存在这样的情况出现.如果什么数据都不发,一般服务器接收上W个连接也一点问题也没有,就是同时连进来时CPU使用率会突然增加一下,到全部连进后基本不用什么CPU.

#7


不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。

#8


引用 7 楼 dyne08 的回复:
不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。

你这叫未雨绸缪。总共2000个,就按10%的并发计算,也才200个能有多少压力?按照你的这种需求,并发度能达到50个已经是相当高了.

#9


传数据的时候,才连接,然后发送数据,当次传完后再关闭刚建立的连接,这样也不用费神去管理连接了.只是服务器端如果采用普通的listen,accept,recv的话,支持的并发连接数可能就那么几十个,服务程序就有点恼火了,服务器端采用完成端口模型,即使极端的2000个并发连接,也没问题.

#10


引用 9 楼 mzy2003 的回复:
传数据的时候,才连接,然后发送数据,当次传完后再关闭刚建立的连接,这样也不用费神去管理连接了.只是服务器端如果采用普通的listen,accept,recv的话,支持的并发连接数可能就那么几十个,服务程序就有点恼火了,服务器端采用完成端口模型,即使极端的2000个并发连接,也没问题.

能够支持的并发连接数,跟使用socket1.1的兼容API还是Winsock2的API没有太大差别,如果能够在一定的时间内把需要处理的业务处理完,那在容忍的时间内,并不会影响其它并发连接.如果说服务器本身只能支持到几十个并发连接,那么即使使用完成端口,结果相差不太大.完成端口在这个过程当中能提升的响应能力并不太大.

#11


引用 7 楼 dyne08 的回复:
不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。


你自己都说发送数据频率是10分钟到1周,这么长的周期,一起并发连接的机率实在太低了.依我估计,一般平均每分钟并发连接不会超过10个呢,服务器悠闲得紧.

#1


间隔时间长又要保证发送的实时性,那么可以进行预连接,即你可能需要12:30:00进行发送,而你可以在12:27:00就开始连接,到点就可以发送了.就2000个连接,中间还有部分间隔时间那么长,使用任何一种架构都不存在问题.

#2


可以先起几个线程预连接,在超过某个数值的客户端进行连接的时候,再起几个线程满足,这样可以减少开销,具体怎么实现,期望有能人出面来解答

#3


你只有2000个客户端的话,数据量有这么小,那就是基本没什么压力了,这样的话,保证实时性,对号的就是长连接。

#4


2000个,还小?各位高人。多谢。希望有更具体的实施方法。

#5


引用 4 楼 dyne08 的回复:
2000个,还小?各位高人。多谢。希望有更具体的实施方法。

2000只算是普通的量.关键要看应用的复杂度,对于复杂应用,比如企业信息化系统之类的2000个倒算是相当大了.

#6


引用 4 楼 dyne08 的回复:
2000个,还小?各位高人。多谢。希望有更具体的实施方法。


还要看你的连接做什么事.如果一直都有数据通讯,每秒都有大量数据通讯,这当然有压力.你的客户端又不是同时一起连接进去(发送频率从10分钟到1周).如果同时连接进来,同时一起发送60K数据让服务器接收,这样服务器自然有压力,但你的情况基本不存在这样的情况出现.如果什么数据都不发,一般服务器接收上W个连接也一点问题也没有,就是同时连进来时CPU使用率会突然增加一下,到全部连进后基本不用什么CPU.

#7


不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。

#8


引用 7 楼 dyne08 的回复:
不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。

你这叫未雨绸缪。总共2000个,就按10%的并发计算,也才200个能有多少压力?按照你的这种需求,并发度能达到50个已经是相当高了.

#9


传数据的时候,才连接,然后发送数据,当次传完后再关闭刚建立的连接,这样也不用费神去管理连接了.只是服务器端如果采用普通的listen,accept,recv的话,支持的并发连接数可能就那么几十个,服务程序就有点恼火了,服务器端采用完成端口模型,即使极端的2000个并发连接,也没问题.

#10


引用 9 楼 mzy2003 的回复:
传数据的时候,才连接,然后发送数据,当次传完后再关闭刚建立的连接,这样也不用费神去管理连接了.只是服务器端如果采用普通的listen,accept,recv的话,支持的并发连接数可能就那么几十个,服务程序就有点恼火了,服务器端采用完成端口模型,即使极端的2000个并发连接,也没问题.

能够支持的并发连接数,跟使用socket1.1的兼容API还是Winsock2的API没有太大差别,如果能够在一定的时间内把需要处理的业务处理完,那在容忍的时间内,并不会影响其它并发连接.如果说服务器本身只能支持到几十个并发连接,那么即使使用完成端口,结果相差不太大.完成端口在这个过程当中能提升的响应能力并不太大.

#11


引用 7 楼 dyne08 的回复:
不准备一直链接,有数据时再链接。但是这么多客户端,有可能同时上传数据。


你自己都说发送数据频率是10分钟到1周,这么长的周期,一起并发连接的机率实在太低了.依我估计,一般平均每分钟并发连接不会超过10个呢,服务器悠闲得紧.