【Django】未来的坑

1、定时任务

Linux下可能会改用crontab，应该可以自己控制启动与结束
现暂时打算用apscheduler，但是这个在使用uwsgi作为服务器的时候会出现重复运行的bug，详情请搜索“apscheduler重复运行”
重复运行解决方法
也可以考虑使用celery，因为看到配置较麻烦，用于小项目中不划算所以有点犹豫。但对于高性能应该是这个的处理好一点吧。发现它也不怎么支持windows，只支持linux

2、存放在线模拟器的变量

现在暂时用python全局变量，也就是说会跨app的文件读这个全局变量，所以会思考安全性问题，比如多线程带来的。
必须了解一下Django的运行机制，比如它是不是多线程或者多进程的。搜索一下发现Django本身并没有设计什么多进程线shuod额程，这是wsgi的工作，而且要看是什么样的wsgi server, uwsgi 和 gunicorn 都支持多线程模式。大家都建议全局变量的话，配置进 settings，业务数据进 redis 或者 DB
细节一点讲，开发环境时Django自带服务器是单进程的，而一份全局变量只存在于一个python进程中。生产环境所用的服务器很有可能是多进程的，每个进程的内存都是单独的。
解决方法：可以采用django的cache机制来存，可以直接使用本地的内存/磁盘，也可以使用memcached，redis
Django缓存机制

3、WSGI，uwsgi，uWSGI到底是什么

python Web开发你要理解的WSGI & uwsgi详解
说得更像人话一点：cgi、wsgi、uwsgi 与 uWSGI都是啥？
廖雪峰教程关于WSGI接口详解

django框架提供了一个开发调试使用的WSGIServer，所以一般写代码调试时就是在这个服务器上跑，runserver 开启的方式也是单进程。但如果正式部署到uwsgi上，就会有一些之前可以运行的代码运行错误了，应该是因为WSGI和uwsgi的协议不太一样。

关于WSGI, 全称Web服务器网关接口(Python Web Server Gateway Interface, WSGI),是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口…简单来说就是用来处理Web服务端与客户端的通信问题的

以django框架为例,使用的是wsgiref模块,该模块的功能：
监听8000端口,把http请求根据WSGI协议将其转换到applcation中的environ参数, 然后调用application函数.
wsgiref会把application函数提供的响应头设置转换为http协议的响应头,把application的返回(return)作为响应体,根据http协议,生成响应,返回给浏览器.

wsgiref模块又是什么：
Python内置了一个WSGI服务器，这个模块叫wsgiref，它是用纯Python编写的WSGI服务器的参考实现。所谓“参考实现”是指该实现完全符合WSGI标准，但是不考虑任何运行效率，仅供开发和测试使用。

坑总览，也可以看到跟py文件执行顺序，为什么会有多进程的原因：django项目在uwsgi+nginx上部署遇到的坑 ==》 Django源码分析之程序执行入口分析
如何实现写的代码只跑一次，不会跑多次：uwsgi托管seDjango掉进去的那些坑

但是托管给uwsgi发布到服务器时发现分线程的定时任务并没有启动，查了些文档，发现uwsgi默认是one thread one processor，没有请求的时候，进程被挂起，子线程也就被挂起了。

4、性能的提高

有前辈提到“Django 的内置 server 性能有多差，你用 ab 之类的工具压测一下就知道了。”
在需要性能的场合，通常单单 nginx 和 uwsgi 也是不够的。nginx 主要优化的是连接数和静态文件。uwsgi 主要优化的是 wsgi 服务。这些都只是手段。其它手段包括，优化数据库，增加缓存，加入负载均衡器，引入异步 IO 框架，计算密集型模块用 C 重写等。