op 引用的链接说的很清楚, 在于过滤的时机在生成临时表前还是生成临时表后。那么在某些情况下， 使用 on 能够极大的减小临时表的大小. 临时表太大，如果数据库服务器磁盘，内存等资源不充裕时，就会导致 sql 执行失败(我曾经在 mysql5.6 上出现过这个问题, 后来改用 on 就可以了).

指法不一定百分百标准，每个人习惯不一样, 能做到字母和一部分功能键盲打即可. 但对于一部分盯着键盘打字，连自己输入错误都不能及时发现的人来说, 我觉得练习指法还是有必要的. 因为可以减少 bug 和变量名拼写错误的情况.

这让我想起来去年这个时候用 python 写过一个:
https://gitee.com/fpgayu/national-day-avatar

官方文档:
https://gorm.io/docs/dbresolver.html

@firejoke 是我看差了, 我以为只有一个 queue, 而你的代码里是两个 context, 各自 3 个 queue, 也就是总共 6 个 queue, 对应 6 个 write_db 的 task. 当遇到 await 的时候, 确实是会跳转到别的 task 里面执行. 确实比较奇怪，但我仍然觉得瓶颈不大可能在 parse_text, 你可以试着记录一下队列写入数据的速率， 如果这个速率也在 400/s 左右, 那说明确实有可能是 parse_text 慢了

大概看了下, 这瓶颈显然不是在 parse_text 中的文件读,就算再怎么阻塞，读写本地文件也不至于到每秒才 400 行的程度. 而在 write_db 中, 出现好几处 await 的地方, 这些地方可都是要同步等待结果返回的呀. 一个很好容易验证的方法就是把 write_db 中的 await 用 await asyncio.sleep 替换掉, 尝试不同的 sleep 时间. 实际上上面的问题在于每一次 while 1 的循环循环是同步的, 你必须要先处理完队列中的前一条数据, 才能继续处理下一条数据. 所以处理也很简单, 把每一次的循环异步化掉.

方法挺多的, 简单点在 settings.py 中做, 标准点就是楼上说的 ready, 可以翻一下你自己项目下面的 wsgi.py ，django.setup(), apps.populate(settings.INSTALLED_APPS)的源码. 楼上说多进程启动的问题, 在做这部分操作的时候，用 redis 做个分布式锁就好了

redis sorted set (有序集合), 任务 id 作为集合的内容, 任务执行时间(时间戳)作为 score; 消费者从有序集合中拿最近需要执行的那个任务, 判断是否到期, 到期就执行, 没有到期继续等待

evio, gnet, netpoll

我不明白为什么要取余数. 按照现有的逻辑，可以在 redis 中维护一个已使用的编号集合，先取号，然后 sadd {:key:} {:取的号:}, 如果 sadd 返回值是 1， 说明该号没有被占用，取号成功； 如果返回值是 0，说明该号已被占用，取号失败，就继续取。关键在于要处理实例下线之后，要将下线实例从集合中剔除。

@HashV2 你说的惰性迭代器缺失可以减少内存占用，但生成器的应用场景不只是迭代器上

@wuwukai007
@HashV2
我并没有在解释节省内存的问题，我在说的是生成器的原理，解释元祖形式的列表生成器的本质。

可以去看看 python 生成器的 PEP ( https://www.python.org/dev/peps/pep-0255/), 该有的里面都有.

事实上，你们也看到，生成器不一定总是会减少内存占用

首先生成器的目的并不是为了减少空间占用。其次你要搞明白生成器的原理, 就绕不开理解 yield 的机制。(x for x in [1,5,-1,10]) 等价于：

def gen():
for i in [1, 5, -1, 10]:
yield i

g = gen()

日常的并发操作下, 你说这这个是可以避免的。问题是如果是秒杀系统, 请求都不会直接打到 mysql.

对使用传统的关系型数据库来说, 需求 2 非常难以实现, 需要自己维护一个 B->A 的映射表(同时还要在表上做 A 的索引)，类似于倒排索引, 但如果存在频繁的写入操作, 该表也很难维护.
其实楼上该说的基本都说了, 文件系统的方案, 实现功能上没啥问题, 至于效果如何, 没用过不知道.

我的想法比较直接, 其实可以用 ES 这一类方案来处理, 对于每一个节点数据, 我们只要拿两个字段用来分别存储其父节点(我觉得有一个父节点字段有时候会更方便点)和祖先节点, 祖先节点按照固定的规则用逗号或者空格等串成字符串存储就好了. 需求 1 没什么好说的, 需求 2 说白了就是两个条件, 祖先节点包含某个 A 节点, 还有就是按时间排序, 所以就是对祖先节点字段做一个分词搜索，再排个序就好了.

用这类工具的好处其实只有一个，不需要自己去维护这个倒排索引.

可以看看 MESI. cache 一致性协议应该是硬件(CPU)实现的, 但事实上硬件要做到强一致性同时兼顾性能也很难，所以实现上会弱化为最终一致性, 一般情况下也没有太大问题, 但是在并发多核的情况下，在某些临界点上还是会出现数据不一致的情况. 所以 CPU 设计的时候提供给程序或者编译器内存屏障机制, 来处理这种情况

你看一下 uwsg.ini 文件是如何配置的, 其中有 chdir, module 等配置项, 用来指定 wsgi.py 的位置和目标 application, wsgi.py 中有一个 get_wsgi_application 函数调用，就是用来初始化目标 application, 有加载 django 的 settings 文件, 初始化一些 django 配置信息，具体等你熟悉以后翻一下源码就知道了

每次合并之前，pull master 分支并不是必须的。因为你最后 push master 的时候，如果远程 master 分支有未 pull 的内容，会要求你先 pull master，否则你无法将本地的修改 push 到 master 上去. 另外还可以参考 git-flow 的流程.

// 自己细品
for index, name1 := range nameArr {
test[index] = func(i int, name1 string) Greeting {
return func(name string) string {
fmt.Println("hello " + name + name1 + strconv.Itoa(i))
return "hello " + name + name1 + strconv.Itoa(i)
}
}(index, name1)
}