【笔记】Celery调研

Celery是一个分布式任务调度系统。
但是坑比较深。

1. 依赖第三方mq，复杂度增加，用Redis还是rabbit？这又是一个问题。
2. CeleryBeat作为任务调度器，有单点故障，如果部署多个实例，又会产生重复消费，所以需要引入Redis或者zk来做选举来failover。
   参考https://www.v2ex.com/t/661409
3. 生产消费高度耦合。
   @app.taskdef add(x, y): return x + y
   上面的逻辑感觉很尴尬，装饰器很奇怪，消费的逻辑在生产者的代码里，让人产生困惑，难以维护。
4. 任务消息去重排序合并幂，怎么避免被worker并发处理等问题，还是要依赖消费端来实现，怎么实现成了问题。
5. 批量处理消息，group方法感觉很难用。
6. 其他各种限制，各种参数，感觉很古怪。
   综上，基于业务选择消息队列和分布式协调件，比如redis，再根据业务实现自定义的消息调度消费逻辑，基于关系型数据库比如MySQL实现消息幂等。