使用 django 开发实时应用程序

发布于 2024-12-09 07:53:37 字数 498 浏览 1 评论 0原文

我已经研究这个问题一两天了。我正在开发一个实时应用程序(聊天和视频聊天)。我正在使用 django/apache 组合,我知道它不适合这个(至少 apache 部分)。

在这方面,我在 stackoverflow 中找到了几个链接,例如 http://www.skitoy.com/p/ django-tornado-chat/305 以及一些比较,例如 http://nichol.as/asynchronous-servers-in-python

我的问题是。从事过 django 实时应用程序工作的人可以让我知道我应该使用什么框架吗?看来我可以在tornado上使用django,也可以在twisted框架上使用django。我是实时应用程序的新手,只需要指针,这样我就可以节省一些时间。

I have been researching this for a day or two. I am working on a real time application (a chat and a video chat). I am using django/apache combination which I understand is not suitable for this (at least the apache part).

In this regard I found several links from within stackoverflow such as http://www.skitoy.com/p/django-tornado-chat/305 and some comparisons such as the one at http://nichol.as/asynchronous-servers-in-python

My question is. Can someone who has worked on django real time application let me know what framework I should use. It seems that I can use either django on tornado or use django with twisted framework. I am new to real time application and just need pointers so I can save some time.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

甜心小果奶 2024-12-16 07:53:37

做过类似事情的人还提供了一些提示:
http://eflorenzano.com/blog/post/technology-behind-convore/< /a>

更新时间:2023-05-04

此问答已有 12 年历史。上面链接的文章已经死了(Convore 本身 AFAICT 也是如此),但可以在以下位置找到:https://web.archive.org/web/20120819142511/http://eflorenzano.com/blog/2011/02/16/technology-behind-concore

我应该将其摘录发布在我原来的答案。

...开发人员在发现 Convore 时往往会问的第一个问题是“该网站采用什么技术?

好吧,12 年后我问的第一个问题是“Convore 是什么?”

它似乎是一个“托管” IRC”平台,即 Slack 或 Discord 之类的平台:https://www.ycombinator.com/companies/convore

Convore 是一个在线平台,使用户能够与群组进行实时交流。其用户可以加入现有组或创建自己的组。
Convore 允许用户发布主题并与朋友就这些主题进行对话。该平台还为其用户提供公共和私人群组。

好吧,回到原来的博文:

我们所有的应用程序代码均由 Python 提供支持。我们的前端 html 页面生成是由 Django 完成的,考虑到 Convore 作为产品的实时性,我们以令人惊讶的传统方式使用它。

所有重要数据都规范地存储在 PostgreSQL 中,包括消息、主题、组、未读计数和用户配置文件。搜索功能由 Solr 提供,它通过方便的 Haystack Django 应用程序连接到我们的应用程序

当一条新消息进入系统时...一个任务被发送到 Celery(通过 Redis)通知它这条新消息已收到...然后它发布到该组的 Redis 发布/订阅消息发布到的位置。

我们的实时更新端点实际上是一个非常简单且轻量级的纯 WSGI Python 应用程序,使用 Eventlet 托管。它为每个请求生成一个协程,在该协程中,它查找用户所属的所有组,然后打开与订阅所有这些通道的 Redis 的连接。这些 Eventlet 托管的 Python 应用程序中的每一个都能够托管数百到数千个开放连接,并且我们在每台前端计算机上运行多个实例。它还有更多职责,例如在返回响应之前将主题标记为已读,但最重要的是成为用户和 Redis pub/sub 之间的桥梁。

这个基本架构至今仍然具有现实意义。

对于 Solr,我们可能会考虑 ElasticSearch。我们可能会使用 Python 3 异步功能,而不是 Eventlet(另请参阅 Gevent)。

此外,Django 本身现在通过“通道”支持实时功能:

https://channels。 readthedocs.io/en/stable/

Channels 是一个采用 Django 的项目,并将其功能扩展到 HTTP 之外 - 处理 WebSocket、聊天协议、物联网协议等。它基于称为 ASGI 的 Python 规范构建。

Some more tips here from people who've done similar:
http://eflorenzano.com/blog/post/technology-behind-convore/

Update 2023-05-04

This Q and A are now 12 years old. The article linked above is dead (as is Convore itself AFAICT), but can be found at: https://web.archive.org/web/20120819142511/http://eflorenzano.com/blog/2011/02/16/technology-behind-convore

I should have posted excerpts from it in my original answer.

...the first question developers tend to ask when they find Convore is "what technology powers this site?

Well, 12 years later the first question I am asking is "What is/was Convore?"

It seems to have been a "Hosted IRC" platform, i.e. something like Slack or Discord: https://www.ycombinator.com/companies/convore

Convore is an online platform that enables its users to communicate with groups in real time. Its users have the ability to join an existing group or create groups of their own.
Convore allows its users to post topics and have conversations with friends about those topics. The platform also provides its users with both public and private groups.

Ok, back to the original blog post:

All of our application code is powered by Python. Our front-end html page generation is done by Django, which we use in a surprisingly traditional way given the real-time nature of Convore as a product.

All of the important data is canonically stored in PostgreSQL, including messages, topics, groups, unread counts, and user profiles. Search functionality is provided by Solr, which is interfaced into our application by way of the handy Haystack Django application

When a new message comes into the system ... a task is sent to Celery (by way of Redis) notifying it that this new message has been received ... then it publishes to a Redis pub/sub for the group that the message was posted to.

Our live updates endpoint is actually a very simple and lightweight pure-WSGI Python application, hosted using Eventlet. It spawns off a coroutine for each request, and in that coroutine, it looks up all the groups that a user is a member of, and then opens a connection to Redis subscribing to all of those channels. Each of these Eventlet-hosted Python applications has the ability to host hundreds-to-thousands of open connections, and we run several instances on each of our front-end machines. It has a few more responsibilities, like marking a topic as read before it returns a response, but the most important thing is to be a bridge between the user and Redis pub/sub.

This basic architecture is still relevant today.

For Solr we might look to ElasticSearch. Rather than Eventlet (see also Gevent) we'd probably use Python 3 async features.

Additionally, Django itself now has support for real-time features via "Channels":

https://channels.readthedocs.io/en/stable/

Channels is a project that takes Django and extends its abilities beyond HTTP - to handle WebSockets, chat protocols, IoT protocols, and more. It’s built on a Python specification called ASGI.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文