yufpga

官方文档:
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; 消费者从有序集合中拿最近需要执行的那个任务, 判断是否到期, 到期就执行, 没有到期继续等待

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

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

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

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

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