PHP バックエンドを Redis ストリーム バスに転送し、フレームワークに依存しないライブラリを選択する

序文

趣味で運営している私の Web サイトは、興味深いホームページや個人サイトをホストするように設計されています。 このトピックに興味を持ち始めたのは、プログラミングの旅を始めたばかりの頃でした。その瞬間、私は自分自身、趣味、プロジェクトについて書いている優れた専門家を見つけることに魅了されました。 自分でそれらを見つける習慣は今でも残っています。ほとんどすべての商用サイトでも、あまり商用でないサイトでも、著者へのリンクを探してフッターを調べ続けています。

アイデアの実現

最初のバージョンは私の個人的な Web サイト上の HTML ページで、署名付きのリンクを UL リストに追加しました。 一定期間にわたって 20 ページを入力した後、これではあまり効果的ではないと考え始め、プロセスを自動化してみることにしました。 stackoverflow で、多くの人が自分のプロファイルでサイトを示していることに気づきました。そのため、最初のプロファイルから始めてプロファイルを単純に処理するパーサーを php で作成しました (今日までの SO のアドレスは次のとおりです: `/users/1`) )、目的のタグからリンクを抽出し、SQLite に追加しました。

これは XNUMX 番目のバージョンと呼ぶことができます。SQLite テーブル内の数万の URL のコレクションであり、HTML の静的リストを置き換えたものです。 このリストから簡単な検索をしてみました。 なぜならURL のみがあり、検索は単に URL に基づいていました。

この段階でプロジェクトを放棄し、久しぶりにプロジェクトに戻りました。 この段階で、私の職歴はすでに XNUMX 年以上になっており、もっと本格的なことができるのではないかと感じていました。 さらに、比較的新しいテクノロジーを習得したいという強い願望もありました。

現代版

プロジェクト Docker にデプロイされ、データベースは mongoDb に転送され、さらに最近では、当初はキャッシュ専用だった大根が追加されました。 PHP マイクロフレームワークの XNUMX つが基礎として使用されます。

問題

新しいサイトは、次のことを同期的に実行するコンソール コマンドによって追加されます。

• URLごとにコンテンツをダウンロードします
• HTTPS が利用可能かどうかを示すフラグを設定します
• ウェブサイトの本質を維持する
• ソースHTMLとヘッダーは「インデックス作成」履歴に保存されます
• コンテンツを解析し、タイトルと説明を抽出します
• データを別のコレクションに保存します

単純にサイトを保存してリストに表示するには、これで十分でした。

しかし、すべてを自動的にインデックス付け、分類、ランク付けし、すべてを最新の状態に保つというアイデアは、このパラダイムにはうまく適合しませんでした。 ページを追加する Web メソッドを追加するだけでも、潜在的な DDoS を回避するためにコードの複製とブロックが必要でした。

もちろん、一般的にはすべてを同期的に行うことができ、Web メソッドでは URL を保存するだけで、巨大なデーモンがリストの URL に対するすべてのタスクを実行できます。 しかし、それでも、ここでも「行列」という言葉自体が暗示されています。 また、キューが実装されている場合、すべてのタスクを分割して、少なくとも非同期に実行できます。

ソリューション

キューを実装し、すべてのタスクを処理するためのイベント駆動型システムを作成します。 そして、私は長い間 Redis Streams を試してみたいと思っていました。

PHP での Redis ストリームの使用

なぜなら私のフレームワークは Symfony、Laravel、Yii の 3 つの巨人のどれでもないので、独立したライブラリを探したいと思っています。 しかし、（最初の調査で）判明したように、個別の本格的なライブラリを見つけることは不可能です。 キューに関連するものはすべて、XNUMX 年前の XNUMX つのコミットからのプロジェクトであるか、フレームワークに関連付けられています。

Symfony については、個別の便利なコンポーネントのサプライヤーとしてよく耳にしており、すでにいくつかを使用しています。 また、Laravel の一部のもの (ORM など) も、フレームワーク自体が存在しなくても使用できます。

symfony/メッセンジャー

最初の候補がすぐに理想的だと思い、何の疑いもなくそれをインストールしました。 しかし、Symfony 以外での使用例を Google で検索するのはさらに難しいことが判明しました。 普遍的で意味のない名前、メッセージを渡すためのバス、さらには Redis 上でさえも持つ多数のクラスから組み立てるにはどうすればよいでしょうか?

公式サイトのドキュメントは非常に詳細でしたが、Symfony のお気に入りの YML や非シンフォニスト向けのその他の魔法のメソッドを使用した Symfony の初期化についてのみ説明されていました。 特に年末年始は、インストールのプロセス自体に興味がありませんでした。 しかし、予想外に長い間これを行う必要がありました。

Symfony ソースを使用してシステムをインスタンス化する方法を見つけ出すことも、厳しい締め切りの中での最も簡単な作業ではありません。

これらすべてを掘り下げて、自分の手で何かをしようとした後、私はある種の松葉杖を使っているという結論に達し、別のことを試してみることにしました。

ライトアップ/キュー

このライブラリは Laravel インフラストラクチャやその他の多数の依存関係に密接に関連付けられていることが判明したため、私はこれにあまり時間を費やしませんでした。インストールして確認し、依存関係を確認して削除しました。

yiisoft/yii2-queue

さて、ここでも名前からすぐに、Yii2 との厳密な関係が推測されました。 このライブラリを使用する必要があり、それは悪くありませんでしたが、完全に Yii2 に依存しているという事実については考えていませんでした。

残り

GitHub で見つけた他のものはすべて、スター、フォーク、多数のコミットのない、信頼性が低く、時代遅れで、放棄されたプロジェクトでした。

symfony/メッセンジャー、技術的な詳細に戻る

このライブラリを理解する必要があり、さらに時間を費やした後、理解することができました。 すべてが非常に簡潔でシンプルであることがわかりました。 バスをインスタンス化するために、私は小さな工場を作りました。 複数のタイヤと異なるハンドラーを使用することになっていました。

ほんの数ステップ:

• 単純に呼び出すことができるメッセージ ハンドラーを作成します。
• それらを HandlerDescriptor (ライブラリのクラス) でラップします。
• これらの「記述子」を HandlersLocator インスタンスでラップします。
• HandlersLocator を MessageBus インスタンスに追加する
• `SenderInterface` のセットを SendersLocator に渡します。私の場合は、明らかな方法で構成された `RedisTransport` クラスのインスタンスです。
• SendersLocator を MessageBus インスタンスに追加する

MessageBus には、HandlersLocator で適切なハンドラーを検索し、対応する `SenderInterface` を使用してバス (Redis ストリーム) 経由で送信するメッセージをハンドラーに渡す `->dispatch()` メソッドがあります。

コンテナー構成 (この場合は php-di) では、このバンドル全体を次のように構成できます。

        CONTAINER_REDIS_TRANSPORT_SECRET => function (ContainerInterface $c) {
            return new RedisTransport(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_SECRET),
                $c->get(CONTAINER_SERIALIZER))
            ;
        },
        CONTAINER_REDIS_TRANSPORT_LOG => function (ContainerInterface $c) {
            return new RedisTransport(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_LOG),
                $c->get(CONTAINER_SERIALIZER))
            ;
        },
        CONTAINER_REDIS_STREAM_RECEIVER_SECRET => function (ContainerInterface $c) {
            return new RedisReceiver(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_SECRET),
                $c->get(CONTAINER_SERIALIZER)
            );
        },
        CONTAINER_REDIS_STREAM_RECEIVER_LOG => function (ContainerInterface $c) {
            return new RedisReceiver(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_LOG),
                $c->get(CONTAINER_SERIALIZER)
            );
        },
        CONTAINER_REDIS_STREAM_BUS => function (ContainerInterface $c) {
            $sendersLocator = new SendersLocator([
                AppMessagesSecretJsonMessages::class => [CONTAINER_REDIS_TRANSPORT_SECRET],
                AppMessagesDaemonLogMessage::class => [CONTAINER_REDIS_TRANSPORT_LOG],
            ], $c);
            $middleware[] = new SendMessageMiddleware($sendersLocator);

            return new MessageBus($middleware);
        },
        CONTAINER_REDIS_STREAM_CONNECTION_SECRET => function (ContainerInterface $c) {
            $host = 'bu-02-redis';
            $port = 6379;
            $dsn = "redis://$host:$port";
            $options = [
                'stream' => 'secret',
                'group' => 'default',
                'consumer' => 'default',
            ];

            return Connection::fromDsn($dsn, $options);
        },
        CONTAINER_REDIS_STREAM_CONNECTION_LOG => function (ContainerInterface $c) {
            $host = 'bu-02-redis';
            $port = 6379;
            $dsn = "redis://$host:$port";
            $options = [
                'stream' => 'log',
                'group' => 'default',
                'consumer' => 'default',
            ];

            return Connection::fromDsn($dsn, $options);
        },

ここでは、SendersLocator で XNUMX つの異なるメッセージに異なる「トランスポート」を割り当て、それぞれが対応するストリームへの独自の接続を持っていることがわかります。

次のバスを使用して相互に通信する XNUMX つのデーモンのアプリケーションをデモンストレーションする別のデモ プロジェクトを作成しました。 https://github.com/backend-university/products/tree/master/products/02-redis-streams-bus.

ただし、消費者がどのように構成できるかを示します。

use AppMessagesDaemonLogMessage;
use SymfonyComponentMessengerHandlerHandlerDescriptor;
use SymfonyComponentMessengerHandlerHandlersLocator;
use SymfonyComponentMessengerMessageBus;
use SymfonyComponentMessengerMiddlewareHandleMessageMiddleware;
use SymfonyComponentMessengerMiddlewareSendMessageMiddleware;
use SymfonyComponentMessengerTransportSenderSendersLocator;

require_once __DIR__ . '/../vendor/autoload.php';
/** @var PsrContainerContainerInterface $container */
$container = require_once('config/container.php');

$handlers = [
    DaemonLogMessage::class => [
        new HandlerDescriptor(
            function (DaemonLogMessage $m) {
                error_log('DaemonLogHandler: message handled: / ' . $m->getMessage());
            },
            ['from_transport' => CONTAINER_REDIS_TRANSPORT_LOG]
        )
    ],
];
$middleware = [];
$middleware[] = new HandleMessageMiddleware(new HandlersLocator($handlers));
$sendersLocator = new SendersLocator(['*' => [CONTAINER_REDIS_TRANSPORT_LOG]], $container);
$middleware[] = new SendMessageMiddleware($sendersLocator);

$bus = new MessageBus($middleware);
$receivers = [
    CONTAINER_REDIS_TRANSPORT_LOG => $container->get(CONTAINER_REDIS_STREAM_RECEIVER_LOG),
];
$w = new SymfonyComponentMessengerWorker($receivers, $bus, $container->get(CONTAINER_EVENT_DISPATCHER));
$w->run();

アプリケーションでこのインフラストラクチャを使用する

バックエンドにバスを実装した後、古い同期コマンドから個々のステージを分離し、それぞれが独自の処理を実行する個別のハンドラーを作成しました。

新しいサイトをデータベースに追加するパイプラインは次のようになります。

そしてその直後から、Rss の抽出や解析などの新しい機能を追加することがはるかに簡単になりました。 なぜならこのプロセスには元のコンテンツも必要です。その後、WebsiteIndexHistoryPersistor などの RSS リンク抽出ハンドラーが「Content/HtmlContent」メッセージをサブスクライブし、それを処理して、必要なメッセージをパイプラインに沿って渡します。

最終的には、それぞれが必要なリソースへの接続のみを維持する複数のデーモンを作成することになりました。 たとえば悪魔 クローラ コンテンツを取得するためにインターネットにアクセスする必要があるすべてのハンドラーとデーモンが含まれています。 持続性 データベースへの接続を保持します。

現在は、データベースから選択する代わりに、パーシスターによる挿入後の必要な ID が、バスを介して関係するすべてのハンドラーに送信されるだけです。

出所： habr.com