第一篇：Python神器Celery源码阅读（1）

第二篇：Python神器Celery源码阅读（2）

Celery是一款非常简单、灵活、可靠的分布式系统，可用于处理大量消息，并且提供了一整套操作此系统的工具。Celery也是一款消息队列工具，可用于处理实时数据以及任务调度。

本篇我们继续celery的基础库:kombu，一个python实现的消息库，在celery中承担核心的消息处理流程。本文包括下面几个部分:

接上篇，我们继续学习AMQP的相关概念。理解这些基础概念对kombu为什么这样实现很有帮助。这次我们用小故事来模拟kombu的消息处理流程。

小学三年级的小明同学喜欢同桌的小红同学，喜欢她的马尾和笑容，经常写小纸条给她。这里小纸条就是Message，小明同学是Producer,小红同学是Consumer，这种直接投递的方式是direct。有时候，小红同学不在座位上，小明就把纸条放在她的抽屉里。抽屉就当做Queue使用，临时存放投递的消息。老师发现小明和小红上课经常有小动作后，棒打鸳鸯把他们分开了，他们不再是同桌。

小明同学没法忘记小红的笑容，距离产生了更多的美，就拜托前面的小马帮他递小纸条，纸条封面上写着“请给小红”。小马就是Exchange，小马的前座也是Exchange，“请给小红”就是消息的route-key。常在河边走，哪有不湿脚。有次纸条被老师抓住，老师让小明同学在讲台上把纸条的内容讲给大家听。当众念小纸条这叫广播,也就是fanout。

幼稚的小故事也是一种真实的生活，谁又没有写过小纸条呢，请暂停回忆一分钟:)。业务是生活场景的一种抽象，代码又是更高层一点的抽象。理解业务，就对代码上的概念不发楞。

以上这些概念Exchange，Queue都是broker要实现的内容。可是客户端Producer/Consumer也包含，这是为什么呢？消息传输过程可不可以简化成一个客户端只使用producer发送消息，另外一个客户端只使用consumer消费消息呢？这样也不是不行，前提是AMQP协议中exchange和queue的创建及绑定，需要使用管理工具在broker先创建好，这无疑约束了AMPQ使用的灵活性。kombu中包含了Exchange，Queue模型，主要是用来对broker的管理。

kombu是植物家族的重要一员,芹菜(celery)、葡萄藤(vine)、海带(kombu)是快乐的一家人。我们解析kombu，采用的版本是5.0.0,主要模块如下: