A key difference between XMPP and AMQP is binary content. AMQP handles binary data just fine, and XMPP seems more designed for XML. Personally for online games I use Google Protocol Buffers for message formatting and parsing, and with their very small binary footprint, I'd be more inclined to use AMQP to deliver those messages.
But do consider what AMQP server you want to use. I've been bitten by using RabbitMQ for my AMQP server in the past. RabbitMQ does not have any flow control facilities, at all. So if your clients are sending messages faster than your server can consume them, buffers on the server can fill up and blow the server up. More recent versions of RabbitMQ implement flow control in an exceedingly coarse way: they halt all consumers in the system until memory clears up.
I've never tried zeromq; perhaps it'd be better for the things I've been using RabbitMQ for...
5K users doesn't tell me much about their behaviour, but if they all submited one request within the same 10 second window then let's say you'd be looking in the 500-1000 requests per second.
I've had Active/MQ running on my relatively low-powered lap-top easily handling 300 requests per second and so I'd happily recommend it here. You can also set up clusters of brokers and achieve horizontal scalability. You can use an http protocol (STOMP) or its native binary protocol. Lots of client API libraries also for C/C++, Java, JavaScript and others. There is some initial AMQP support.
You didn't mention any persistence requirement, but again I would have thought that most RDBMSs would suffice. That said, some of the document oriented and big-table type databases look interesting from a horizontal scaling perspective.
I've also found Apache Camel highly performant and I strongly recommend it. Camel is used to implement your logic layer.
发布评论
评论（2）
XMPP 和 AMQP 之间的主要区别在于二进制内容。 AMQP 可以很好地处理二进制数据，而 XMPP 似乎更适合 XML。就我个人而言，对于在线游戏，我使用 Google Protocol Buffers 进行消息格式化和解析，并且由于其二进制占用空间非常小，我更倾向于使用 AMQP 来传递这些消息。
但请务必考虑您要使用哪种 AMQP 服务器。过去，我一直在使用 RabbitMQ 作为我的 AMQP 服务器。 RabbitMQ 根本没有任何流量控制设施。因此，如果您的客户端发送消息的速度比服务器消耗消息的速度快，则服务器上的缓冲区可能会被填满并导致服务器崩溃。 RabbitMQ 的最新版本以极其粗略的方式实现流量控制：它们停止系统中的所有消费者，直到内存清理干净。
我从来没有尝试过zeromq；也许对于我一直使用 RabbitMQ 做的事情会更好......
A key difference between XMPP and AMQP is binary content. AMQP handles binary data just fine, and XMPP seems more designed for XML. Personally for online games I use Google Protocol Buffers for message formatting and parsing, and with their very small binary footprint, I'd be more inclined to use AMQP to deliver those messages.
But do consider what AMQP server you want to use. I've been bitten by using RabbitMQ for my AMQP server in the past. RabbitMQ does not have any flow control facilities, at all. So if your clients are sending messages faster than your server can consume them, buffers on the server can fill up and blow the server up. More recent versions of RabbitMQ implement flow control in an exceedingly coarse way: they halt all consumers in the system until memory clears up.
I've never tried zeromq; perhaps it'd be better for the things I've been using RabbitMQ for...
5000 个用户并没有告诉我太多关于他们的行为的信息，但如果他们都在同一个 10 秒窗口内提交一个请求，那么假设您会查看每秒 500-1000 个请求。
我已经在我的相对低功耗的笔记本电脑上运行了 Active/MQ，每秒可以轻松处理 300 个请求，因此我很乐意在这里推荐它。您还可以设置代理集群并实现水平可扩展性。您可以使用 http 协议 (STOMP) 或其本机二进制协议。许多客户端 API 库也适用于 C/C++、Java、JavaScript 等。有一些初步的 AMQP 支持。
您没有提到任何持久性要求，但我还是认为大多数 RDBMS 就足够了。也就是说，从水平扩展的角度来看，一些面向文档和大表类型的数据库看起来很有趣。
我还发现 Apache Camel 具有高性能，因此我强烈推荐它。 Camel 用于实现逻辑层。
5K users doesn't tell me much about their behaviour, but if they all submited one request within the same 10 second window then let's say you'd be looking in the 500-1000 requests per second.
I've had Active/MQ running on my relatively low-powered lap-top easily handling 300 requests per second and so I'd happily recommend it here. You can also set up clusters of brokers and achieve horizontal scalability. You can use an http protocol (STOMP) or its native binary protocol. Lots of client API libraries also for C/C++, Java, JavaScript and others. There is some initial AMQP support.
You didn't mention any persistence requirement, but again I would have thought that most RDBMSs would suffice. That said, some of the document oriented and big-table type databases look interesting from a horizontal scaling perspective.
I've also found Apache Camel highly performant and I strongly recommend it. Camel is used to implement your logic layer.