erlang, nodejs, go, python，

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 4586 天前的主题，其中的信息可能已经有所发展或是发生改变。

服务器软件，支持3万个客户端同时在线，每个客户每分钟发3个1k的数据包，与服务器通信使用UDP。
用python＋twisted+线程＋线程间通信？
还是erlang？
还是nodejs？
还是go？

无论那种语言，我的想法是最好能针对每一个客户端启动一个线程，这样逻辑简单很多。
但是启动3万个线程，而且线程不退出，不知道那一个框架和语言可以在比较低的内存消耗和cpu使用量上实现

谢谢。

线程

Python

Nodejs

16 条回复 • 1970-01-01 08:00:00 +08:00

lfeng

2012-05-11 20:02:56 +08:00

erlang 比较靠谱吧。。。

eric_q

2012-05-11 20:09:57 +08:00

非阻塞……erlang吧，不过看了你另一个帖子，我觉得还是老老实实python吧

bhuztez

2012-05-11 20:12:23 +08:00

@eric_q 看具体应用啊。这个场景，明显 Erlang 简单，只要照着OTP风格依样画葫芦就可以了。

oldgun

2012-05-11 20:35:02 +08:00

用python的话建议eurasia

HowardMei

2012-05-11 20:36:44 +08:00

可以看看 http://mongrel2.org/ (+http://code.google.com/p/openpgm/ to support PGM/UDP)能不能满足你的需求，你可以直接用任何语言(php/c/c++/java/ruby/python 只要 zeroMQ 支持即可)写 backend handler

用python 框架 http://brubeck.io 写web handler 也未尝不可

这个也没有多少 proven records，但比 hack from scratch 要好那么一点点。

如果你一定要用 twisted，可以看看 http://cyclone.io/

virushuo

2012-05-11 20:41:21 +08:00

看看go的goroutines 和 channel，正是你需要的。

myrual

2012-05-11 20:52:03 +08:00

@HowardMei openpgm 在arm上无法编译。官方不支持。
@lfeng @virushuo @HowardMei @oldgun @bhuztez
非常感谢好心人。

另外我观察了目前得到的试验数据，基于UDP在实际网络情况中的糟糕表现，可能控制命令的传输还是要回到TCP上来。
zero暂时又回到视线范围内。

ayang23

2012-05-11 21:01:41 +08:00

3万客户端每分钟3个数据包是很简单的事情，不需要复杂化，介于有可能3万个客户端同时发来数据，做个异步处理或者队列就有必要了。差不多的框架性能上都能满足。

myrual

2012-05-11 21:12:47 +08:00

@ayang23 三万个TCP连接同时保持的话，是很大的问题么？
用twisted这样的框架是不是就够了？

ayang23

2012-05-11 21:17:21 +08:00

每分钟更新3个数据，没必要TCP持久连接。应该没问题。

jiyinyiyong

2012-05-11 21:22:49 +08:00

学 Node 但没深入.. 常说单线程非阻塞, 没发现在 CPU 和内存有优势.

reus

2012-05-11 22:45:29 +08:00

erlang的线程最轻量，所以个人感觉最经济
其实还有一个选择是openresty，国人写的基于nginx的框架 http://openresty.org/
作者的微博：http://weibo.com/agentzh ，如果有兴趣可以问下他看这种场景是否适合

notedit

2012-05-12 01:54:14 +08:00

据我对go的了解，一个goroutine 用来维持一个连接，一个goroutine 大概占4k的空间。 go写并发的server简直就是利器(有很多好用的好用的api)

myrual

2012-05-12 07:31:42 +08:00

@ayang23 业务要求保持长链接，类似pushmail那样的

CMGS

2012-05-13 00:33:56 +08:00

其实我很想说……Gevent……
3W并发没达到过，我做过最高的压测大概是2W同时……
4 workers， gunicorn+gevent……

myrual

2012-05-15 20:56:25 +08:00

谢谢大家的讨论。今天经过开会讨论，所有的客户端通过https访问服务器来传输各种命令和获取信息。然后负载的问题交给iis，业务逻辑还是让it部门去干，他们依然可以使用他们最熟悉的asp.net。只要嵌入式设备能够完整实现https客户端就好，不要发了tcp连接建立，发送数据之后就断开连接。
这意味着我之前考虑的各种并发问题，通讯问题，tcp问题一去不复返。
我只要专心做好一个服务模块就行了。这个模块对外提供http服务，让别的服务器通过http来发送和获取数据。然后我只要把一些从UDP通讯中获取的简单数据通过http服务返回给查询的客户端。
我想，这是一个必定可以工作的方案，而且似乎是相对成熟的方案，毕竟基于http，有IIS。

我只是想，为什么有人要发明那些zeromq，erlang来进行发送大规模消息呢？
http发送有什么明显的缺点么？