Kombuソース解析1
2755 ワード
詳細
Kombuソース解析1
Pythonをプレイしている学生の多くはCeleryをプレイしたことを聞いたことがあるかもしれませんが、CeleryはPythonで最も流行している非同期メッセージキューとして非常に人気があると言えます.しかし、多くの学生を使うのも1つの感触があると信じて、それは时々奇妙な穴に出会って、しかも最后にすべて再开を通じて解决するしかなくて、原因を探し当てるのは本当に容易なことではありませんためです.
私はこの怪我をした人の中の一人として、この大きな穴の内部の原理を理解したいので、かつてその内部の実現をすり抜けたことがありますが、Celeryは確かに少し膨大で、コードの実現も多くないと思いますので、一部の知識を学んだだけですが、多くの収穫があります.だから、最近いろいろな事情で、私は今回深く掘り下げたので、後続の文章はCeleryが実現したことを話しています.
Celeryのソースコードを確認してみると、根本的に迂回できない穴があることがわかります.それはKombuです.Kombuの位置付けはAMQPプロトコルに対応するメッセージキュー抽象ですが、これは作者の一言にすぎません.コードを見てみると、非同期MQのAMQPに対応する抽象キューを試していることがわかります.だから、私はまずKombuのコードから書くことにしました.この文章は最初の文章です.
私はこのシリーズの中でKombu 4.1.0とCelery 4.1.0のことを話しています.まず、後続の学生が番号に合わないように、事前に言っておきます.
Kombuコードのダウンロード
Kombuのコードは探しやすいです.Celeryと強く結合しているので、Celeryのコードグループに入れて、Githubで簡単に見つけることができます.だから、ダウンロードも簡単です.
これで、あなたは私のこのシリーズの文章の中のKombuのソースコードを得て、私の后ろのすべてのコードのソースと行数はすべてこのバージョンのコードに対応しています!
全体Review
コードを手に入れた後、私はまずすべての非コード部分を捨てて、kombuというディレクトリの下に何があるかを全体的に見ました.
kombuというディレクトリの大部分はファイルで、3つのフォルダしかありません.それぞれ:
async:非同期操作の関数とクラスTransport:各種MQ対応クラスutils:いくつかの補助関数とクラスこのディレクトリから、私たちはいくつかの問題を発見しました.抽象的なMQである以上、非同期操作は何がほしいですか.これは少し限界がありますね.
メッセージの簡単な追加/取得
OK、概要を見て実際のものを見て、まずKombuで生産/消費のコードを書いてみましょう.このDEMOは2つの部分に分かれています.
simple_receive.py:簡単な消費者simple_send.py:単純な生産者この2つのコードがどのように書かれているかを見てみましょう.
相変わらず、この2つのコードは私のGithubで見つけることができます.まず消費者を見てみましょう.消費者のコードは簡単です.まずMQとの接続を確立してから、MQの指定されたキューからメッセージを出して、処理します.
生産者は逆に、前もキューと接続を確立しなければならないが、ここでexchangeを作成してからキューにメッセージを送信し、メッセージを送信すると同時に多くのパラメータを組み合わせることが少し異なる.
ここでKombuは興味深い点で、すべてのMQを抽象化し、インタフェースを通じて一致したAPIを露出することを意図しています.そうすれば、下層で何を使っているのか、Redis/RabbitMQ/MongoDBなどの勝手な切り替えに関心を持つ必要はありません.
KombuのMQモデル
KombuはAMQPを抽象化しているので、必ず抽象的なモデルがありますが、実際にはRabbitMQとほぼ差はありませんが、全く同じではなく、いくつかの違いがありますので、Konbuの抽象的なモデルを紹介します.
Kombuでは、いくつかの概念が存在しますが、実際には、前の簡単な生産/消費者サンプルでいくつか見ました.彼らはそれぞれ:
Message:生産消費の基本単位は、実は私たちのいわゆるニュースです.
Connection:MQ接続の抽象に対して、1つのConnectionは1つのMQの接続に対応する
Transport:実際のMQ接続であり、MQ(redis/rabbitmq)に実際に接続されたインスタンスでもある.
Producers:メッセージを送信する抽象クラスConsumers:メッセージを受信する抽象クラスExchange:MQルーティング、これとRabbitMQの差は多くなく、5タイプをサポート
Queue:対応するqueue抽象は、実は文字列のパッケージである.
メッセージはそのQueueに送信されました
Redisの'test'という名前のqueueにメッセージを送信したいと仮定すると、KombuはどのようにしてExchangeの概念に設計されています.現在Kombuは異なるMQに対してこのように支持している.
もし私たちがDirectを使っているとしたら、私たちのProducerは生産時にQueue=testを指定するだけでいいので、testというqueueで送信されます.Exchangeの詳細については、AMQP 0-9-1 Model Explainedを参照してください.
この記事では、まずここまで紹介し、その後、コードレベルに深く入り込み、このモデルの各エンティティがどのように実現されているかを見てみましょう.
Reference
AMQP 0-9-1 Model Explained
Kombu Docs
Kombuソース解析1
Pythonをプレイしている学生の多くはCeleryをプレイしたことを聞いたことがあるかもしれませんが、CeleryはPythonで最も流行している非同期メッセージキューとして非常に人気があると言えます.しかし、多くの学生を使うのも1つの感触があると信じて、それは时々奇妙な穴に出会って、しかも最后にすべて再开を通じて解决するしかなくて、原因を探し当てるのは本当に容易なことではありませんためです.
私はこの怪我をした人の中の一人として、この大きな穴の内部の原理を理解したいので、かつてその内部の実現をすり抜けたことがありますが、Celeryは確かに少し膨大で、コードの実現も多くないと思いますので、一部の知識を学んだだけですが、多くの収穫があります.だから、最近いろいろな事情で、私は今回深く掘り下げたので、後続の文章はCeleryが実現したことを話しています.
Celeryのソースコードを確認してみると、根本的に迂回できない穴があることがわかります.それはKombuです.Kombuの位置付けはAMQPプロトコルに対応するメッセージキュー抽象ですが、これは作者の一言にすぎません.コードを見てみると、非同期MQのAMQPに対応する抽象キューを試していることがわかります.だから、私はまずKombuのコードから書くことにしました.この文章は最初の文章です.
私はこのシリーズの中でKombu 4.1.0とCelery 4.1.0のことを話しています.まず、後続の学生が番号に合わないように、事前に言っておきます.
Kombuコードのダウンロード
Kombuのコードは探しやすいです.Celeryと強く結合しているので、Celeryのコードグループに入れて、Githubで簡単に見つけることができます.だから、ダウンロードも簡単です.
> git clone https://github.com/celery/kombu.git
> cd kombu
> git checkout v4.1.0
これで、あなたは私のこのシリーズの文章の中のKombuのソースコードを得て、私の后ろのすべてのコードのソースと行数はすべてこのバージョンのコードに対応しています!
全体Review
コードを手に入れた後、私はまずすべての非コード部分を捨てて、kombuというディレクトリの下に何があるかを全体的に見ました.
kombuというディレクトリの大部分はファイルで、3つのフォルダしかありません.それぞれ:
async:非同期操作の関数とクラスTransport:各種MQ対応クラスutils:いくつかの補助関数とクラスこのディレクトリから、私たちはいくつかの問題を発見しました.抽象的なMQである以上、非同期操作は何がほしいですか.これは少し限界がありますね.
メッセージの簡単な追加/取得
OK、概要を見て実際のものを見て、まずKombuで生産/消費のコードを書いてみましょう.このDEMOは2つの部分に分かれています.
simple_receive.py:簡単な消費者simple_send.py:単純な生産者この2つのコードがどのように書かれているかを見てみましょう.
相変わらず、この2つのコードは私のGithubで見つけることができます.まず消費者を見てみましょう.消費者のコードは簡単です.まずMQとの接続を確立してから、MQの指定されたキューからメッセージを出して、処理します.
生産者は逆に、前もキューと接続を確立しなければならないが、ここでexchangeを作成してからキューにメッセージを送信し、メッセージを送信すると同時に多くのパラメータを組み合わせることが少し異なる.
ここでKombuは興味深い点で、すべてのMQを抽象化し、インタフェースを通じて一致したAPIを露出することを意図しています.そうすれば、下層で何を使っているのか、Redis/RabbitMQ/MongoDBなどの勝手な切り替えに関心を持つ必要はありません.
KombuのMQモデル
KombuはAMQPを抽象化しているので、必ず抽象的なモデルがありますが、実際にはRabbitMQとほぼ差はありませんが、全く同じではなく、いくつかの違いがありますので、Konbuの抽象的なモデルを紹介します.
Kombuでは、いくつかの概念が存在しますが、実際には、前の簡単な生産/消費者サンプルでいくつか見ました.彼らはそれぞれ:
Message:生産消費の基本単位は、実は私たちのいわゆるニュースです.
Connection:MQ接続の抽象に対して、1つのConnectionは1つのMQの接続に対応する
Transport:実際のMQ接続であり、MQ(redis/rabbitmq)に実際に接続されたインスタンスでもある.
Producers:メッセージを送信する抽象クラスConsumers:メッセージを受信する抽象クラスExchange:MQルーティング、これとRabbitMQの差は多くなく、5タイプをサポート
Queue:対応するqueue抽象は、実は文字列のパッケージである.
メッセージはそのQueueに送信されました
Redisの'test'という名前のqueueにメッセージを送信したいと仮定すると、KombuはどのようにしてExchangeの概念に設計されています.現在Kombuは異なるMQに対してこのように支持している.
もし私たちがDirectを使っているとしたら、私たちのProducerは生産時にQueue=testを指定するだけでいいので、testというqueueで送信されます.Exchangeの詳細については、AMQP 0-9-1 Model Explainedを参照してください.
この記事では、まずここまで紹介し、その後、コードレベルに深く入り込み、このモデルの各エンティティがどのように実現されているかを見てみましょう.
Reference
AMQP 0-9-1 Model Explained
Kombu Docs