彗星的Python消息缓存？
我可以通过简化版本的示例来最好地描述我正在寻找的内容。 Tornado 的演示之一是一个简单的聊天服务器：
https:/ /github.com/facebook/tornado/blob/master/demos/chat/chatdemo.py
我对这里的 MessageMixin 类感兴趣。它保留静态长度的消息积压，当新消息可用时，它返回新消息列表的切片。或者这就是它看起来的作用。我知道我之前在编写一个简单的彗星应用程序时已经实现了类似的东西。
那么有人概括了这一点并添加了一些奇特的东西吗？我对管理多种沟通渠道并删除一段时间未使用的沟通渠道的方法特别感兴趣。坚持也许也有用。
这是 MQ 可以做的事情吗？
I can best describe what I'm looking for with an example of a simplified version. One of the demos for Tornado is a simple chat server:
https://github.com/facebook/tornado/blob/master/demos/chat/chatdemo.py
I'm interested in the MessageMixin class here. It keeps a static-length backlog of messages, and when new messages are available, it returns the slice of the message list that's new. Or that's what it appears to do. I know that I've implemented something like that before when writing a simple comet app.
So has anyone generalized this and added fancy things to it? I'm particularly interested in a way to manage many channels of communication and delete ones that haven't been used in a while. Persistence might also be useful.
Is this something an MQ can do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Redis 有一个 发布/订阅功能，以及额外的面向数据结构的命令，您可以使用它们来持久化和使消息积压过期，列出给定房间中的用户或与他们关联的其他属性。该协议基于文本，是 Memcached 命令的超集。
以下描述使用 聊天作为 pub/sub 的示例以及 使用 Websocket 的 Ruby 示例，以及使用 Websocket、Tornado 和 Redis pub/sub 实现一个简单的聊天室。
根据您问题中的信息，专用消息队列（例如 RabbitMQ）也可能对您有用。如果不知道您在消息量、容错性、复制等方面的需求，就很难说。Redis 也可能是您正在寻找的，但如果没有其他的话，它非常简单，可以帮助您获得原型快速运行以进一步确定您的应用程序的要求。
Redis has a publish/subscribe feature, along with additional data structure-oriented commands which you can use to persist and expire the message backlog, list users in a given room, or other attributes associated with them. The protocol is text-based and is a superset of the Memcached commands.
Here is a description which uses chat as an example of pub/sub along with a Ruby example using Websocket, and a snippet in Python which uses Websocket, Tornado and Redis pub/sub to implement a simple chat room.
Based on the information in your question, a dedicated message queue (like RabbitMQ) may also be useful to you. It is hard to say without knowing what you need in the areas of message volume, fault-tolerance, replication, etc. Redis may also be what you're looking for, but if nothing else it is pretty simple and could help you get a prototype running quickly to further nail down your app's requirements.