为什么聊天应用程序必须是异步的？

Question

我需要为我的Web服务实现一个聊天应用程序(用Django + Rest api框架编写).在做了一些谷歌搜索之后,我发现可用的Django聊天应用程序都已弃用,不再受支持了.我找到的所有DIY(自己动手)解决方案都使用Tornado或Twisted框架.

所以,我的问题是:是否可以制作基于Django的同步聊天应用程序？我需要使用任何异步框架吗？我在后端编程方面经验很少,所以我希望尽可能简单.

Answer 1

与许多其他Web框架一样,Django是围绕从Web客户端接收HTTP请求,处理请求和发送响应的概念构建的.打破这种流动(为简化起见简化):

1. 远程客户端打开与Django服务器的TCP连接.
2. 客户端向服务器发送HTTP请求,具有路径,一些标头和可能的主体.
3. 服务器发送HTTP响应.
4. 连接已关闭
5. 服务器返回到等待新连接的状态.

聊天服务器,如果需要在某种程度上是实时的,则需要有所不同:它需要与连接的客户端保持许多同时打开的连接,以便在通道上发布新消息时,相应的客户端会得到相应的通知.

一种现代的实现方式,即使用WebSockets.客户端和服务器之间的通信流以HTTP请求开始,如上所述,但客户端向服务器发送特殊的升级 HTTP请求,要求会话从简单的请求/响应范例切换到持久性,"全双工"通信模型,客户端和服务器都可以在任何时间向两个方向发送消息.

与多个并发客户端的连接需要持久的事实意味着您不能拥有一个简单的执行模型,其中您的服务器一次只能处理一个请求,这通常发生在您调用同步服务器的情况中.Tornado和Twisted使用多线程进行网络连接的不同模型,因此可以保持多个连接打开并由服务器同时处理,并使聊天服务成为可能.

尽管如此,同步方法

话虽如此,有一些方法可以实现一个非常简单,不可扩展的聊天服务,具有明显的延迟:

1. 客户端POST向服务器执行请求以向通道发送消息.

2. 客户端GET向服务器执行定期请求,以向他们订阅的频道请求任何新消息.他们发送这些请求的速率基本上是聊天应用的刷新率.

使用这种方法,您的服务器将比使用异步执行模型来维护持久连接更加困难,但它会起作用.