Django 中聊天请求的客户端轮询（反向 AJAX）？
我想让网站上的一个用户可以聊天请求我的 Django 网站上的另一位用户。我希望被请求者得到一个实时框，上面写着：“你想聊天吗？”
以下客户端轮询方法听起来如何：
user1 单击 users2 昵称，生成对某些 /message/requests 的 POST 请求，这会在数据库中创建 CHAT_REQUEST 类型的消息。同时，user2 浏览器上的 JavaScript 片段会重复查询服务器以获取消息更新。当它收到 CHAT_REQUEST 类型的消息时，它会打开一个弹出窗口...
这种方法的问题似乎是数据库访问。
如果客户端每 10 秒轮询一次，并且 100 个用户保持浏览器窗口打开，则每秒有 10 个数据库请求。
将这些消息存储在 Django RAM 或会话信息中而不是数据库中会更好吗？或者这个数据库表会用PostgreSQL缓存在RAM中，并且检索速度快吗？
I want to make it that one user on the site can chat request another user on my Django site. I want the requestee to get a realtime box that say: "Do you want to chat?"
How does the following client polling approach sound:
user1 clicks on users2 nickname, generating a POST request to some /message/requests, which creates a Message of type CHAT_REQUEST in the database. Meanwhile, a Javascript piece at user2's browser, repeatedly queries the server for message updates. When it receives a Message of type CHAT_REQUEST it opens a popup...
The problem with this approach seems to be the database access.
If the client is polling every 10 seconds, and 100 users leave their browser windows open, that is 10 database requests per seconds.
Would it be better to store these messages not in the database, but in Django RAM or session information? Or will this database table be cached in RAM with PostgreSQL, and the retrieval fast?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您所说，用于此目的的数据库表会给您的服务器带来负载，但如果您出于某种原因想要保留这些请求的记录，则可能会很有用。
使用 memcached 或 AMQP 服务器之类的东西可能会给你带来更好的性能。如果您愿意，您甚至可以使用更高性能的键值存储，例如 Tokyo Cabinet / Tokyo Tyrant。
A database table for this would put a load on your server, as you said, but might be useful if you want to keep a record of these requests for whatever reason.
Using something like memcached or an AMQP server might give you better performance. If you like you could even use a higher-performance key-value-store such as Tokyo Cabinet / Tokyo Tyrant.
如果您担心服务器性能和带宽使用情况，我建议您寻找“类似 COMET”的通信而不是“类似 AJAX”的通信。
顺便说一句，REDIS 看起来非常适合处理这种内存数据结构。
I suggest you look for a "COMET like" communication instead of "AJAX like" if you worry about server performance and bandwidth usage.
By the way, REDIS looks very well suited for handling that kind of in-memory data structures.