Python 有自己的网关接口标准，叫 WSGI ，去看看具体的标准才再开始。

而且切莫重复造轮子，已经有很多 WSGI server ，一般人就是写个 application 的 callback 而已。

猜测是有个任务抛异常，没有捕捉，就那样所有 worker 挂了

@unity0703 filter 函数在 Python 3 与生成器表达式是一个样，所以我觉得首要说明用什么版本的 Python

其二，正则表达式那边，我觉得尽可能不如说， 2 次以上的调用则要编译，否则就可以略去编译。

@aljun 什么架构？你最熟悉的架构就是最好的。说架构你上 InfoQ 一搜一大把，你一个人能用吗？选择你能维护，你最熟悉的就是最好的，性能不行的时候再加机器，升机器。

没有最好的，你现在在网上看到的所有架构都是 trade off 之后的结果。你说你的项目食面向整个京城的大学，我还见过很多面向全国的的项目呢？所以年轻人不要想太多，扎克伯格当你也没有想那么多，就很直接的撸个 the facebook 。你就先去撸吧，等你上了一定规模，你的性能真不行的时候，你自然就会了，没有一步到位的。

@aljun 没有什么坏处，你配置多花点功夫而已，就好像你觉得 uwsgi 费时，我们生产还不是上 uwsgi 。

redis 之类的，你能用自然就用。反正玩而已，你去试试就知道。坏处我能想到就是你要付出时间精力去配置这些东西，不过现在这个学习阶段，这些都不是事，多试试就好。

多读文档，多读源码，多写代码。别人给你个 benchmark 结果真的就对你有用吗？一切都还是得自己去试，你试过就知道，大学里面这样的机会多。出去社会就不多了，赶紧试，试玩多总结就好了，不会的单词就查字典，不要吐槽英语，以后的文档都是英语的。不要期望那么多教程，以后很多时候甚至连文档都没有都有可能。

@vus520 inotify 是 linux 内核特性， Mac 自然没有。

其实我觉得其实不一定要上 SSD ，通过调整 JVM 启动参数，一样可以很流畅使用 Jetbrains 家的 IDE 软件，甚至可以说更流畅，当然随着 JVM 的 GC 算法改进，用户体验也在提升。经我观察，其实更多时候卡顿都是因为内存使用达到了阈值，强制 GC 导致 stop the world 。若是调高 JVM 能使用内存的最大值，卡顿会大大减少。

@aljun Gunicron 文档超级简单的，上面甚至还有 supervisor 的配置文件，你下载下来改改就能跑了。官方文档就是详细教程，为什么还要求？

@aljun 这个不是渣不渣的问题，而是你要理解为什么 Python 这样跟 mod_php 的区别，你说若要学 php,Python 上古时期还有 mod_python 呢，就是用 Python 替代 php ，一样的执行模式。

至于部署，你真的需要 gevent 吗？你无端端增加中间件，那复杂度肯定上升啊，你直接单用一个 Gunicron 就好了。也就是 nginx+Gunicron ，过早的优化是万恶的源泉。你的网站先将日流量跑到上万的 PV 再说，若是一日才几百 PV ，然后就做高并发的时期，然后吐槽，这。。。。。。。

淘宝单重启就要几个小时。

@zonghua ⊙﹏⊙b 汗，那是 Boland 。

dns 挂了，很大程度上是 DNS 污染，跟操作系统没关系

php 跟 apache 结合是一个请求一个进程， apache 负责启动

python 已经定义好了 wsgi ，前面的 web server 转发 http 请求给 wsgi server 就可以了，这个有什么问题？

就是个简单的进程管理， nginx 转发而已，每次都是 git push 触发钩子脚本就可以部署了，没什么大的问题。

@gaocegege 将所有的数据库连接要不 mock 要不 stub

对所有的程序来说，能跑!=能用。哪怕你写了单元测试，那样一样不能说你写的就是对的，测试还会分单元测试，集成测试。

建议先写单元测试，后面在慢慢上集成测试，同时使用 coverage ，尽量使测试覆盖率到达 100%。

绝对的正确唯有定理证明，将你的需求转换为一个定理，然后编写程序去证明它，若是证明出来了，那么你就不用写什么测试了。你的程序必然是对的，但是这个领域就有点远了。

OS X 沙盒机制导致的，喷前多了解。

至于版权，没版权的下架是很正常的一件事，不是只有腾讯才是有版权的，网易也是有给钱的。这个事情本来就是一场博弈，一般可以认为，你们现在还能用的流音乐基本上都是合法的。毕竟前段时间国家才大力进行过音乐版权这方面的清查。

不要尝试去跟团队风格做斗争，你若是喜欢 Arch 可以自己继续用，我相信你的团队不会为难你，前提是你自己能够配合。不要尝试让别人迁就你。团队已经适应了 OS X ，自然不会因为你而迁移开发环境。你若是能正常协作，你用什么都没问题。
团队合作效率大于一切，这是真理，当然你若是 CTO 就另外说。否则就严于律己。

尝试一下 OS X 吧， Linux 下面的命令行基本上都可以迁过来，没有什么大的不同。

@mzer0 一千万的请求，多少时间内一千万的请求？如果是 1 分钟， 1 个小时， 1 天都是不一样的。过早的优化是万恶的源泉。

不是说这些知识需不需要懂，关键是到底有多少家公司能达到 1 小时 1 千万的请求数。我都不说分钟了。又不是每家公司都能达到这样的程度，达到这样程度的公司自然就能解决，你说 4 路的服务器，我们的老板只批 1CPU ， 1G 的配置，你说这个怎么解决？这个也要上多线程？这样的条件下面简单粗暴就行了，反正一天也就那么多请求。有这个时间去提高单机性能，我还不如搞下自动化部署，自动化运维好了。

其实我想知道，为什么有云的，还要贸然同一台机器上面重装。重新开个实例不更好么？反正也花不了多少钱，新实例能正常运行了再删除旧实例

@julyclyde
队列不是因为这样才分，是看你要不要优先处理你的特定任务。比如 task1 的处理不应堵塞 task2 那么就应该采用不同队列而且分配不同的 worker 去处理

@lixia625
你 task 里面的 settings 读错了，还是用同样的参数，那肯定是连到同样的数据库里面。