用 celery 任务的 eta 参数，可以了解下

kafka 做消息队列呗。
前面生产数据到队列，后面起消费进程，格式化，入库等等，解耦还是挺容易的。

跟楼主做过类似的项目，当时是为了实时处理日志的情景。
1 Kafka 有个消费组的机制，我同一个 topic 有 N 个 parition， 每一个 partition 对应一个 python 进程（ supervisor 管理所有的进程）。假如遇到了性能瓶颈就，新增 partition, 新增进程（包括机器）。这种比较简单粗暴
2 后面优化这种流程，换了 golang 了。。。

[best-pratices]( https://lincolnloop.com/django-best-practices/)
我一般业务逻辑都是放 model 层，view 层大多数做判断之类的。
但是留意到题主可能更多的问题是公司团队内部的不统一吧。。试试主动 push 下代码规范统一？

@dassh 感谢你的思路~
- to 的参数我测试了下， 在不调用 `start_background_task ` 的情况下，可以完成独立 print 功能
- 在调用 `start_background_task ` 才会出现提到的，旧的窗口也会获取到新窗口的数据（日志数据）
- 所以是比较想好奇这一块的实现方式或者原理

@dassh 这里每一个日志都是独立的（每个任务都生成对应的日志）
所以 client on log 会接受 server 多个线程分别 emit 的数据？
我这个 scan log 不是用多个线程进行的么，另外 emit 的时候用 to 这个参数也区别了 client 的发送的呀

@strict 这个只是保存任务的一些必要参数吧。执行结果，参数，执行时间等等。
但是像执行日志，类似任务 stdout 输出， 不会在这里面吧？还是有啥盲点我没发现的吗，华生

@shanghai1943 clickhouse 做 OLAP 比较合适，高并发这个要求得看具体场景，很多大厂还是有 clickhouse 的实践经验的。

Clickhouse +2，而且还可以帮你涉及下新的领域？

@Suigintou 某宝就可以找店家操作

帮顶。希望能跟优秀的热血骚年们一起共事

@Lwf1995 python 欢迎您

@jmercer python 还是 前端呀？可以发个简历给小姐姐看一下哦：）

@ml071987 额..我是帮妹子招聘而已。。欢迎来望京交流一下。^-^

@knva 只看？是时候展示真正的技术了啊

@yacolinqi 可以可以，最后你看上行政妹子

@mec 妹子属于全世界

@winiex 阿公就是好