感觉与 flask 和 celery 均无关，而是如何正确处理时相关问题。
“动态设定任务的时间间隔”比较模糊，可能的情况是：

1. 如果上一次任务完成时你必定知道下一次任务应当发生的时间，则在上一次任务的过程中添加下一次任务（以非定时的方式）。
2. 否则，以所有可能的定时任务的最小公约数为间隔执行，添加是否真正执行任务的条件判断。

（等你描述清楚了，你也就写出来了。

说个事儿，忘记哪看到的了，日本对公司收 “增长税”，也就是说你的利润，不花出去，就是一半归 gov
所以都会尽可能把所有的收入拿去用掉，比如做广告。
这有个什么好处呢？能从供应侧推动内循环，避免个人暴富。

又是我最喜欢的大家一起乱猜环节
我先猜一个 v-model="?" 这里名字写错了
我再猜一个 vm/data/? 这里名字写错了
最后猜一个其实根本没有引入 Vue 库

@haiironezumi 而且 LTT 之前也说了，这波操作，你媒体就算认出来那是个坑，你也得往下跳，不跳不行。别人都跳了，你不跳，反正那么多人跳了少你一个苹果没损失，你没蹭到热度你有损失。

@JasonLaw 我猜测：你没有意识到你的问题里蕴含的前提。故，我把这个前提指出来。

或者说，
> 想要更快地为顾客提供咖啡，最后还是需要请很多很多的厨师？
当然，你如果不想请很多很多厨师，那为什么要请收银员呢？

@jousca 陈述的是少见，突然开始讲安全未免有点牛头不对马嘴。
WC 服务器是真的少见。挂在 Azure 上面的都是 Linux 多，M$ 才意识到、才去认真对待开源软件（是否认真对待自由软件另说）。
1. 在不考虑成本上限的情况下，所有系统当然都能做到同等的安全性，但是真实世界是有成本的；
2. GNU/Alpine+Linux+OpenSSL 的安全性部分来自可以裁剪降低攻击面和攻击面的不确定性，这在成本上是非常低的，同时提供了大量的缓冲时间；
3. 所有 WC 都无法抗拒来自 M$ 的恶意，你只能通过其他手段让 WC 不知道 M$ 的恶意，但你也不能保证这个手段生效了；
4. 非 WC 也不是只有 Linux，BSD 在安全策略上更激进；
5. 重大恶性 Bug 的平均存续时间（包括存在但未被发现的时间），Linux 是 5 年，Windows 是 10 年。

@adocder 俺寻思这个项目看上去就是在尝试将快捷键 “通用化”，至于是否完成了这一目的、完成得出色与否，是结果论的部分。
GUI 也是 Palo Alto 的顶尖 hacker 们发明的。不要 shell 中心主义

你没有收银员，你怎么请很多厨师呢？你还得为每个厨师自己配个收银台、让厨师自己收银？
谈完非阻塞 IO，回到负载均衡，一个收银员可以接受了一百个汉堡，让十名厨师分别做 10 个肉饼。
“负载均衡器” 的核心工作是分配负载，标题里说的那些是为了更有效地实现这一工作的优化。

@adocder 大约是黑客（ hacker ）的本义，而非讹义。

完全可以推算出最恰当的组织形式，为什么要自己拍脑袋做转换？

https://gist.github.com/no1xsyzy/5391a79203b0ee64aec7c7de46b028f2

creation_subject_id
creation_subject_user_name
creation_complete_time

首先，如果是 canonical complete 的关系型表设计，不应当是一个条目里存储创建者
而应当是记录创建的发生，其主体与客体与完成时间（参考是）。
就你提到的设计来说，item.creator_id 实质上是 creation.subject_id ON creation.object_id=item.id 的嵌入，[id] 相消，应当是 creation_subject_id
我认为应当写成 嵌入表名称 "_" 嵌入表字段名
同理，item.creator_name 其实是 user.name ON user.id=item.creation_subject_id 的嵌入，[id] 相消，所以剩下的是 creation_subject_user_name

然后官方文档也可能有错
真正、完整的确认需要看源代码。

很认真地很淡定地慢悠悠地泡咖啡。给某个很正常的动作设置很多复杂多余的设定
比如杯子清洗完要拿饮用水荡一遍，再泡茶。泡茶要先烫一遍茶叶

这和现代的所谓 “冥想” 其实差不多的，实质是专注训练，把所有的意念投入到唯一一件事上去