“ 很多Web应用都有实时通讯的需求，这个问题比较典型，应该有不少同学都会有这个问题。”
先说结论：Django是可以做实时消息推送的。以下的内容分两个部分，我们先来了解消息推送模型的通用设计，再来了解Django怎么样可以实现消息推送。
消息推送模型
消息推送模型分为生产端和消费端，这里的生产端则是我们通常说的后台服务，比如这里的Django服务；而消费端主要是用户可达的客户端，比如app和网站等等。
对于消费端来说，消息推送模型分为Pull模型和Push模型，我们来逐一了解。
Pull模型
Pull，也就是拉取，指的是消费端主动拉取消息，此时，后台要实现相关的消息接口，消费端定时向后台发起消息更新的查询请求，以此来达到消息及时推送的功能，通信协议比较简单，可以直接使用无状态的HTTP协议。
Push模型
Push，也就是推送，指的是生产端后台主动向消费端推送消息。这里有个问题，那就是生产端怎么知道消费端的IP和地址？一般而言，消费端都会有生产端的地址，因为生产端的地址相对固定，并且频繁使用，但是生产端一般不会主动保存客户端的地址。所以Push模型一般是对于在线客户端而言的，也就是生产端和消费端之间保持网络连接，并通过心跳保活，连接断开由消费端主动重连。在这种保持连接的状态下，生产端就可以主动向消费端推送消息了，通信协议一般基于TCP连接的基础上自己实现。
哪种模型比较好？
关于Pull模型和Push模型的好坏，在此不做结论，不同的场景都有不同的考虑：比如生产端的速率远大于消费端的速率的场景；强调消息实时性的场景；消费端不在线的场景等等。另外两种模型在消息队列等框架下都有广泛使用，各有千秋，合适的才是最好的。
Django实现消息推送
对于Pull模型，Django实现Pull模型的生产端部分很简单，对外实现甚至可以就一个HTTP接口即可，供消费端主动请求查询，在内部需要维护一个消息队列，用于存储待推送的消息和标记没推送的用户，简单工程可以使用Python的线程安全队列；大工程一般结合Kafka、RabbitMQ等消息队列进行服务解耦。
对于Push模型，Push模型在网络连接上可以基于WebSocket进行通信，Django上可以使用已有组件实现WebSocket或者可以依赖第三方库，这里WebSocket保证了双方通信的连接，在连接之上，还需要定义通信协议。通信协议怎么理解呢？简单而言，就是需要生产端和消费端协商好通信报文的结构体是怎么样的，在协商好结构体后辅以序列化手段比如json、protobuf等。
以上，希望对大家有帮助。
注：本文源自课程《Django+小程序打造个人助手》问答区同学的疑问整理而来。
随时随地看视频
