高性能で軽量な分散メモリキューシステム - beanstalk

Beanstalk は、高性能、軽量、分散型のインメモリ メッセージ キュー システムです。当初の設計目的は、時間のかかるタスクをバックグラウンドで非同期的に実行することにより、大容量の Web アプリケーション システムのページ アクセスの待ち時間を短縮することでした。実際、Beanstalkd は Memcached に似た典型的な設計で、同じプロトコルと使用スタイルを備えています。その基本的な設計思想は非常にシンプルです。高パフォーマンスは非同期性と切り離せないものであり、非同期性はキューと切り離せないものであり、内部モデルはプロデューサーとコンシューマーです。

背景：

現在、市場には多くのメッセージ キュー システムが存在します。よく使用されるものは、ActiveMQ、RabbitMQ、ZeroMA、Kafka、RocketMQ です。 Redis の作成者は最近、Disque をオープンソース化しました。以前、LeTVでApacheのqpidを使用していました。ただし、各システムが人気を博している理由は、そのシステムの重点によって異なります。

その中でも、ActiveMQ は JMS と AMQP の仕様を完全にサポートする従来型と言えます。

JMS は、Java Message Service アプリケーション プログラミング インターフェイスです。これは、Java プラットフォーム上のメッセージ指向ミドルウェア (MOM) の技術仕様です。メッセージ システム内の Java アプリケーション間のメッセージ交換を容易にし、メッセージの生成、送信、受信のための標準インターフェイスを提供することで、エンタープライズ アプリケーションの開発を簡素化します。 (*ここで述べたように、JMS はアプリケーション プログラミング インターフェイス、つまり API であり、API はプログラミング言語にバインドされていることを意味します)

JMS アーキテクチャは、JMS プロバイダー、JMS クライアント、JMS プロデューサー、JMS コンシューマー、JMS メッセージ、JMS キュー、および JMS トピックで構成されます。

JMS オブジェクト モデルには、接続ファクトリ、JMS 接続、JMS セッション、JMS 宛先、JMS プロデューサーとコンシューマー、および JMS メッセージが含まれます。その中でも、最も関心の高い 2 つの JMS メッセージ モデルは、ポイント ツー ポイント (キュー) とパブリッシュ/サブスクライブ (トピック) です。 2 つの違いは、ポイントツーポイント モードでは、プロデューサーがメッセージをキューに送信することです。キューには複数のコンシューマーを設定できますが、メッセージを受信できるのは 1 つのコンシューマーのみです。利用可能なコンシューマーがない場合、メッセージは利用可能なコンシューマーが存在するまで保存されるため、キューは信頼性の高い負荷分散を実装します。パブリッシュ/サブスクライブ モデルでは、パブリッシャーがトピックにメッセージを送信し、トピックをサブスクライブしたサブスクライバーだけがメッセージを受信します。トピックはパブリッシングとサブスクリプションを実装します。メッセージを公開すると、このトピックにサブスクライブしているすべてのサービスがこのメッセージを取得できるため、1 ～ N 人のサブスクライバーがこのメッセージのコピーを取得できます。

AMQP (Advanced Message Queuing Protocol) と JMS の違いは、JMS は Java プラットフォーム専用のソリューションであるのに対し、AMQP はクロス言語プロトコルである点です。クロス言語特性により、エンタープライズおよびシステム統合のオーバーヘッドが削減されます。したがって、現在のほとんどのメッセージ キュー システムは AMQP をサポートしていますが、JMS をサポートしているシステムは少数です。

AMQP の特徴は、メッセージの方向、キューイング、メッセージ モデル (JMS と同じ: ポイントツーポイントおよびパブリッシュ/サブスクライブ)、信頼性、およびセキュリティです。メッセージ配信の保証は、最大 1 回、少なくとも 1 回、正確に 1 回という 3 つあります。

メッセージ キューを使用するときによく言及されるブローカーは、AMQP プロトコルを実装するサーバーの名前です。その基本構造を下図に示します。

Beanstalkの紹介:

それでは、豆の木について話し始めましょう。まず、beanstalk は実際には JMS に準拠しておらず、AMQP プロトコルにも厳密に準拠していません。 Beanstalk と RabbitMQ の関係は、Nginx と Apache の関係と同じだと言う人もいます。よりシンプルで軽量、高性能で使いやすいです。しかし、Kafkaと比較すると、データ処理能力にはまだ差があるため、実際には徐々に置き換えを進めています。しかし、非常に使いやすい特別な機能がいくつかあり、それについては後ほど説明します。

Beanstalkは主に4つの部分で構成されています。

1> ジョブ: 非同期で処理する必要があり、チューブに配置する必要があるタスク。

2> チューブ: プロデューサーとコンシューマーの操作の対象となる、同じタイプのジョブを格納するために使用されるよく知られたタスク キュー。

3> プロデューサー: ジョブのプロデューサー。put コマンドを使用してジョブをチューブに配置します。

4> コンシューマー: ジョブのコンシューマーは、reserve、release、bury、delete コマンドを使用してジョブを取得したり、ジョブのステータスを変更したりします。

先ほど、Beanstalk には特別で便利な機能がいくつかあると言いました。つまり、タスクの優先度、遅延、実行時間、埋め込みをサポートし、分散バックグラウンド タスクとスケジュールされたタスク処理を適切にサポートできます。これらの機能は、豆の木の作業プロセスと密接に関連しています。

Beanstalk ジョブには、READY、RESERVED、DELAYED、BURIED の 4 つのライフ サイクルがあります。

プロデューサーが直接ジョブを配置すると、ジョブは READY 状態になり、コンシューマーが処理するのを待機します。遅延 put を選択した場合、ジョブは最初に DELAYED 状態になり、指定された時間に READY 状態になります。コンシューマーは READY ジョブを取得し、ステータスは RESERVED になります。こうすることで、他の消費者はこのジョブを操作できなくなります。コンシューマーがジョブを完了すると、削除、解放、または埋め込みを選択できます。

削除後はジョブを取得できなくなります。リリースされたジョブは、再度移行するか、READY に遅延することができます。埋め込みジョブは休止状態にしておき、必要に応じて READY にしたり削除したりできます。

Beanstalk の使用シナリオ:

遅延キューとして使用されます。たとえば、ユーザーが 30 分以内に操作しない場合、タスクは閉じられます。

循環キューとして使用: release コマンドを使用して、タスクをループで実行し、たとえば負荷分散タスクを分散します。

フォールバック メカニズムとして使用: たとえば、リクエストが失敗する可能性がある場合、Beanstalk を使用して継続的に再試行し、タイムアウトを設定し、その時間内に成功するまで試行することができます。

スケジュールされたタスクとして使用: たとえば、特別なバックグラウンド タスクに使用できます。

非同期操作に使用されます。これはすべてのメッセージ キューの中で最も一般的に使用されます。まず、タスクを投入して順番に実行します。