celery源码解读
Celery启动的入口：
文件：Celery/bin/celery.py
看下main函数做了什么事
可以看到主要做了几个事根据-P参数判断是否需要打patch，如果是gevent或者eventlet则要打对应的补丁。
然后执行命令行逻辑
可以看到，这边取出系统参数
然后执行基类Command的execute_from_commandline，
文件：celery/bin/base.py
setup_app_from_commandline是核心函数，作用是获得我们的app对象和获得我们的配置参数
文件：Celery/bin/celery.py
这边主要获取启动类别及启动参数，我们的类别是worker所以：
这边是开始准备启动对应类别的对象，worker、beat等。
self.commands是支持的命令：
上面我们知道，我们的类型是worker，即celery.bin.worker.worker，初始化该类，然后执行run_from_argv函数
文件：celery/bin/worker.py
最后一行会执行到父类的__call__函数，
文件：celery/bin/base.py
这边主要执行的是run函数
这个函数主要是启动worker
终于进入worker了，现在这里涉及一些比较关键的东西了，
文件：celery/worker/__init__.py
在WorkController类里，是worker的基类
这是worker的蓝图，这边会形成一个依赖图，是启动的必要组件，分别负责worker的一部分任务，比较重要的几个：
Timer：用于执行定时任务的 Timer，和 Consumer 那里的 timer 不同
Hub：Event loop 的封装对象
Pool：构造各种执行池（线程/进程/协程）的
Beat：创建Beat进程，不过是以子进程的形式运行（不同于命令行中以beat参数运行)
文件：celery/apps/worker.py
文件：celery/apps/trace.py
文件：celery/app/base.py
从init_before开始，这边是最主要的，即绑定所有的task到我们的app，注册task在下面
每个task都有delay和apply_async函数，这个可以用来帮我们启动任务。
文件：celery/worker/__init__.py
这边是设置关注及不关注的队列，可以看到，celery支持ampq协议。
调用setup_includes安装一些通过CELERY_INCLUDE配置的模块,保证所有的任务模块都导入了
最后初始化蓝图，并进行apply完成蓝图各个step的依赖关系图的构建，并进行各个组件的初始化，依赖在component中已经标出
这个requires就是依赖，说明hub依赖timer，上面蓝图声明的组件都有互相依赖关系。
回到文件：celery/worker/__init__.py执行start
执行的是蓝图的start。
分别执行各个步骤的start，在apply时，会判断step是否需要start，不start但是仍要create。
通过启动日志看，worker启动的step为Pool，和Consumer；
如果换成prefork方式起，worker会多起hub和autoscaler两个step：
Hub依赖Timer，我们用gevent，所以include_if是false，这个不需要start。
Hub创建时候引用的kombu的Hub组件，Connection会注册到Hub，Connection是各种类型连接的封装，对外提供统一接口
Queue依赖Hub，这边是基于Hub创建任务队列
下面是我们的worker启动的step其中的一个，重点进行说明
初始化线程/协程池，是否弹缩，最大和最小并发数
Celery支持的几种TaskPool，
我们是gevent，所以这边直接找gevent的代码。
这边直接引用gevent的Pool
下面看worker启动的第二个step
可以看到，这边启动的是celery.worker.consumer.Consumer，这边就会涉及另一个重要的蓝图了。
文件：celery/worker/consumer，Consumer类
这是Consumer的蓝图，
Consumer启动的step为Connection，events，mingle，Gossip，Tasks，Contorl，Heart和event loop。
__init__初始化一些必要的组件，很多都是之前worker创建的。
然后执行blueprint的apply，做的事我worker之前是一样的。
执行Consumer的start，也就是执行blueprint的start。
启动的step的基本功能：
Connection：管理和broker的Connection连接
Mingle：不同worker之间同步状态用的
Tasks：启动消息Consumer
Gossip：消费来自其他worker的事件
Heart：发送心跳事件（consumer的心跳）
Control：远程命令管理服务
其中Connection，Tasks，Heart和event loop是最重要的几个。
先看Connection。
使用了consumer的connect()
Conn引用了ampq的connection，ampq的Connection是直接使用的kombu的Connection，上面说过，这个Connection是各种支持的类型（如redis，rabbitMQ等）的抽象，对外提供统一接口。
如果hub存在，会将连接注册到event loop。
再看Tasks：
这边引用的ampq的TaskConsumer，ampq的TaskConsumer继承了kombu的Consumer。
可以看到，在关键的几个地方，celery都引用了kombu，Kombu对所有的MQ进行抽象，然后通过接口对外暴露出一致的API（Redis/RabbitMQ/MongoDB），Kombu对MQ的抽象如下：
Message：生产消费的基本单位，就是一条条消息
Connection：对 MQ 连接的抽象，一个 Connection 就对应一个 MQ 的连接
Transport：真实的 MQ 连接，也是真正连接到 MQ(redis/rabbitmq) 的实例
Producers: 发送消息的抽象类
Consumers：接受消息的抽象类
Exchange：MQ 路由，这个和 RabbitMQ 差不多，支持 5种 类型
Queue：对应的 queue 抽象，其实就是一个字符串的封装
Hub是一个eventloop，Connection注册到Hub，一个Connection对应一个Hub。Consumer绑定了消息的处理函数，每一个Consumer初始化的时候都是和Channel绑定的，也就是说我们Consumer包含了Queue也就和Connection关联起来了，Consumer消费消息是通过Queue来消费，然后Queue又转嫁给Channel，再转给connection，Channel是AMQP对MQ的操作的封装，Connection是AMQP对连接的封装，那么两者的关系就是对MQ的操作必然离不开连接，但是，Kombu并不直接让Channel使用Connection来发送/接受请求，而是引入了一个新的抽象Transport，Transport负责具体的MQ的操作，也就是说Channel的操作都会落到Transport上执行。
再看下event loop：
上面我们有了connection以及绑定connection的consumer，下面看看消费者怎么消费消息，如果是带hub的情况：
先对consumer进行一些设置，
然后开始进行循环。loop是kombu创建的event loop，启用事件循环机制，然后next这边就开始不停的循环获取消息并执行。
这个是kombu里的部分实现，是对从池里取到的消息进行处理。
看下同步代码，register_callback将回调注册consumer，然后执行consume：
再看消息循环那几行，
获取到消息后，调用回调函数进行处理。
回调函数使用的是create_task_handler()，strategies是在上面的update_strategies里进行的更新，该函数是在Task里调用的
打印一下strategies里的信息，只截部分图：
下面看下我们怎么启动任务的，
调用到app的send_task
再调用到ampq的publish_task，
最终又交给kombu的publish。
关于pool的选择：
使用的是app的pool，即
通过connection又走到了ampq再转到kombu里。
Worker和consumer基本大框架就是上面的流程，下面看下beat是怎么实现的。
Beat起动的时候是celery beat，根据我们上面的分析，首先进入的应该是celey/bin/beat.py，然后调用该文件中的Beat的run函数：
然后在指向apps的Beat：
在apps里的Beat调用run：
主要执行了三个函数，init_loader主要初始化并绑定task，第二步设置一些头信息之类的，关键是第三步，主干代码
主要是初始化service并start。
Start最关键的部分是那个while循环体，只要不被shutdown，就会一直调用scheduler的tick
这边这个self.schedule就是我们准备调度的任务：
下面看对这些任务的处理：
这是判断是否要执行任务的逻辑，如果要执行，则执行apply_async。
如果发现任务该执行了，则去tasks里获取任务，并执行，这边的apply_async和worker那边的没区别，如果没找到task，则将task注册到broker。
怎样将consumer和concurrency联系起来
这边调用了_process_task，调用的是worker里的
这边调用各种池的启动函数：
但是queue里只是引用，后面还有别的处理
在初始化consumer时候将调用池的操作传了进去，成为了Consumer里的on_task_request
在Tasks调用start的时候会更新strategies
然后在这边调用start_strategy
然后就进入
然后走入strategy的default
这里取了consumer的on_task_request，就是我们传入的池执行的逻辑，_limit_task是这样的：
做了一些判断，符合条件再执行。
这个文件是strategy的default的下半个文件，做了一些流量控制，然后执行limit_task或者直接执行handler。
这边因为使用的gevent，所以就走到gevent的apply_async，
这边是起一个协程处理，这样就将任务交给了gevent。
具体上面是执行流程，具体在哪里执行的呢？
这边注册了callback，create_task_handler从strategy这边取值取值执行
Qos对ack的处理部分：
Kombu的transport的redis.py里的额basic_consume，调用channel的basic_consume；
在Kombu.transport.virtual.__init__.py文件中
这里维护了一个dict：self._delivered，一个set：self._dirty和一个int：prefetch_count，
如果no_ack为False在执行consume后会向self._delivered中添加一条数据，
ack后会向self._dirty中添加一条数据，然后，后面会将self._dirty逐条删除，并同时删除self._delivered中的数据，如果没有ack，则不会删除：
每次拉任务的时候会调用can_consume：
比较prefetch_count和self._delivered减self._dirty的值，如果小于预取限制，则允许，否则不允许。
