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

【问题标题】：Why do chat applications have to be asynchronous?为什么聊天应用程序必须是异步的？
【发布时间】：2016-02-07 04:29:41
【问题描述】：

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

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

【问题讨论】：

你能把这个问题说清楚一点吗？如何编写应用程序是您的选择。你能写一个满足你的规范和用户体验的基于 Django 的同步聊天应用程序吗？那么答案是肯定的，没关系！ :)
如果你有任何javascript背景，我推荐一个简单的js框架Socket.io，它实现了以下答案中提到的WebSockets。你可以找到很好的演示here。
还值得指出的是，django-channels 是一个让在 Django 中做异步事情变得更容易的项目。非常这个项目很可能会在某个时候被合并到核心中。

标签： python django chat tornado

【解决方案1】：

Django 与许多其他 Web 框架一样，是围绕从 Web 客户端接收 HTTP 请求、处理请求并发送响应的概念构建的。分解该流程（为清楚起见进行了简化）：

远程客户端打开 TCP 与您的 Django 服务器的连接。
客户端向服务器发送HTTP 请求，其中包含路径、一些标头和可能的正文。
服务器发送 HTTP 响应。
连接已关闭
服务器返回到等待新连接的状态。

如果聊天服务器需要实时性，则需要有所不同：它需要与已连接的客户端保持许多同时打开的连接，以便在通道上发布新消息时通知相应的客户端相应地。

一种现代的实现方式是使用WebSockets。客户端和服务器之间的这种通信流程以 HTTP 请求开始，就像上面描述的那样，但是客户端向服务器发送一个特殊的 Upgrade HTTP 请求，要求会话从简单的切换将请求/响应范例转换为持久的“全双工”通信模型，其中客户端和服务器都可以随时双向发送消息。

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

不过是同步方法

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

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

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

【讨论】：

【解决方案2】：

如果您要制作聊天应用程序，您需要使用websockets。他们将使参与对话的所有客户获得更新变得更加容易，并且它会在您的应用程序中为您提供实时对话。话虽如此，我从未见过在同步框架中使用 websocket。

是否可以制作仅基于 Django 的同步聊天应用程序？太多未回答的问题无法得到合理的答案。有多少人会使用这个聊天应用程序？每次对话有多少人？这个应用程序会存在多久？如果你想为你和几个朋友做一些简单的事情，那就做你所知道的。如果您通过制作此应用获得报酬，请使用 websockets 并使用异步框架。

【讨论】：

【解决方案3】：

您当然可以开发一个同步聊天应用程序，您不一定需要我们一个异步框架。但这一切都取决于您希望您的应用程序做什么？有多少人会使用该应用程序？会有多个用户同时进行多个聊天吗？

【讨论】：