高性能（但愚蠢）的网络服务器
我正在尝试编写一个非常简单的网络服务器，它执行以下操作：
- 接收请求。
- 用一个小文件响应；关闭连接。
- 处理请求数据。
换句话说，响应不依赖于请求信息，但请求信息仍然很重要。数据将被持久化，然后用于分析。
我尝试使用一些事件驱动的网络框架来做到这一点，但它们似乎都保持连接，直到处理代码返回。这是有道理的，因为通常服务器在响应后不需要执行任何工作，但就我而言，不需要这种特定的处理方式。
理想情况下，服务器应该继续响应请求，同时将请求数据添加到堆栈中，该堆栈在持久化时被清空。
我们期望每秒处理数千个请求。事件驱动编程真的是正确的选择吗，还是应该坚持使用（传统）线程？哪种语言或框架更适合这种工作？
谢谢。
I'm trying to write a very simple web server that does the following:
- Receive request.
- Respond with a tiny file; close the connection.
- Handle the request data.
In other words, the response doesn't depend on the request information, but the request information is still important. The data will be persisted and then used for analytics.
I've tried to do this with some event-driven networking frameworks, but they all seem to hold the connection until the handling code returns. This makes sense, because generally a server doesn't have to do any work after responding, but in my case there's no need for this particular way of doing things.
Ideally, the server should keep responding to requests, whilst the request data is added to a stack which is emptied as it is persisted.
We expect to handle thousands of requests per second. Is event-driven programming really the way to go, or should I stick with (traditional) threads? Which language or framework is more appropriate for this kind of work?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否考虑过使用 Node.js？它允许您使用 javascript 快速轻松地编写面向 http 的服务器程序。它似乎非常适合您的需求，因为它的行为是可定制的，并且据说可以很好地扩展。
您可能需要考虑阅读一些教程。
Have you considered using Node.js? It allows you to write http-oriented server programs quickly and easily, using javascript. It seems to be pretty well suited to your needs, as its behavior is customizable and it is said to scale pretty nicely.
You might want to consider reading some tutorials.
我意识到，与其使用回调（或绿色线程，如果您愿意的话）来做任何类型的实际工作，我最好将请求数据委托给独立的应用程序。对此的一些研究向我指出了像 beanstalkd 和 RabbitMQ 这样的工作队列。
beanstalkd 看起来比竞争对手更轻、更快，所以我可能会坚持使用它。
I realized that instead of using the callback (or green thread, if you will) to do any sort of real work, I'd be better off just delegating the request data to an independent application. Some research into this pointed me to work queues like beanstalkd and RabbitMQ.
beanstalkd seems lighter and faster than the competition, so I'll probably stick to it.