使用Django RF、Celery、RabbitMQ实现多API定时拉取的相关问题咨询

问题1：Celery直接发起API拉取还是单独写拉取脚本 #

可以直接在Celery任务中编写拉取逻辑，无需额外维护独立的拉取脚本。
你可以把每个第三方API的拉取逻辑封装为独立的Celery任务，不同接口的鉴权规则、请求参数、超时阈值都可以在对应任务中单独配置，还能直接复用Celery自带的失败重试、异常捕获、告警通知能力，比独立脚本的维护成本更低，任务调度和状态追踪也更方便。

问题2：拉取结果回传存储的实现方案 #

不需要额外新增队列和Worker处理返回结果。
由于你的Celery服务和Django项目共用一套代码上下文，在拉取任务拿到第三方接口返回的异构数据后，可以直接导入项目中提前定义好的DRF序列化器，对数据做格式校验、字段转换，校验通过后直接调用序列化器的save()方法，或者直接用Django ORM操作将数据写入PostgreSQL即可，全程不需要额外的消息流转。
如果你的拉取量极大、数据转换存储逻辑耗时很高，怕阻塞拉取任务的执行，也可以将存储逻辑拆分为独立的Celery任务，拉取完成后触发存储任务执行，这种场景下可以新增独立队列隔离两类任务，普通量级的定时拉取完全不需要做额外改造。

问题3：Worker配置方案选型 #

优先选择单Worker带多子进程的方案，和你的场景匹配度更高。
你的拉取任务属于典型的IO密集型任务，大部分时间都在等待第三方API返回响应，单Worker启动多子进程的资源利用率更高，管理也更简单。多Worker单进程的方案更适合CPU密集型任务，或者需要对不同类型任务做资源隔离的场景，目前你的需求不需要用这个方案。
初期可以按CPU核心数的1_{2倍设置单Worker的子进程数，比如4核CPU开4}8个子进程即可。如果后续需要更高的拉取并发，还可以直接将Celery的执行模式换成gevent/eventlet协程模式，单Worker就能支持上百个并发拉取任务，足够满足每日定时拉取的需求。

内容的提问来源于stack exchange，提问作者paulavan