Övergång av PHP-backend till Redis streams och val av ramverksoberoende bibliotek.

Förord

Min webbplats, som jag jobbar med som en hobby, är avsedd för att lagra intressanta hemsidor och personliga sidor. Detta ämne började intressera mig i början av min programmeringsresa, då jag fascinerades av att hitta stora proffs som skriver om sig själva, sina intressen och projekt. Vanan att upptäcka dem för mig har kvarstått och nu: nästan på varje kommersiell och mindre webbplats fortsätter jag att kolla i sidfoten för att hitta länkar till författarna.

Genomförande av idén

Den första versionen var helt enkelt en html-sida på min personliga webbplats, där jag samlade länkar med kommentarer i en ul-lista. Efter att ha samlat omkring 20 sidor över tid började jag tänka att detta inte var särskilt effektivt och bestämde mig för att försöka automatisera processen. På stackoverflow märkte jag att många angav webbplatser i sina profiler, så jag skrev en parser i php som helt enkelt gick igenom profilerna, började med den första (adresser på SO ser fortfarande ut som `\/users\/1`), extraherade länkar från den önskade taggen och sparade dem i SQLite.

Detta kan kallas den andra versionen: en samling av tiotusentals URL:er i en SQLite-tabell, som ersatte den statiska listan i html. Utifrån denna lista skapade jag en enkel sökfunktion. Eftersom det endast fanns URL:er, var sökningen enkel såväl.

Vid detta stadium övergav jag projektet och återkom till det efter en lång tid. På den tiden hade jag över tre års arbetslivserfarenhet och kände att jag kunde göra något mer seriöst. Dessutom fanns det en stark vilja att lära mig relativt nya teknologier.

Den moderna versionen

Projektet är driftsatt i Docker, databasen har bytts till mongoDb, och relativt nyligen har Redis lagts till, som först användes för caching. En av PHP:s mikroramverk används som grund.

Problemet

Nya webbplatser läggs till med ett kommandoskript som synkront gör följande:

• Laddar ner innehåll från URL
• Sätter en flagga om HTTPS var tillgängligt
• Sparar webbplatsens entitet
• Sparar den ursprungliga HTML-koden och rubrikerna i historiken "indexering"
• Parserar innehållet, extraherar Title och Description
• Sparar data i en separat samling

Detta var tillräckligt för att enkelt lagra webbplatser och visa dem i en lista:

Men idén att automatiskt indexera, kategorisera och rangordna allt och hålla allt uppdaterat passar dåligt in i detta paradigm. Även ett enkelt tillägg av en webbmethode för att lägga till sidor krävde kodduplicering och blockeringar för att undvika potentiell DDoS.

Självklart kan allt göras synkront, och i webbmethode kan man helt enkelt spara URL:en så att det monstruösa demonet utför alla uppgifter för URL:er från listan. Men även här kommer ordet "kö" upp. Och om man inför köer kan man dela upp alla uppgifter och åtminstone utföra dem asynkront.

Lösning

Införa köer och skapa ett event-driven system för att bearbeta alla uppgifter. Jag har länge velat prova Redis Streams.

Använda Redis Streams i PHP

Eftersom jag inte använder ett ramverk från de tre giganterna Symfony, Laravel, Yii, ville jag hitta ett oberoende bibliotek. Men, som det visade sig (vid första granskningen) – det är omöjligt att hitta seriösa separata bibliotek. Allt som rör köer är antingen ett litet projekt med tre commits från för fem år sedan eller kopplat till ett ramverk.

Jag har hört om Symfony som en leverantör av användbara komponenter, och dessutom använder jag redan några av dem. Och från Laravel går det också att använda vissa saker, till exempel deras ORM, utan att behöva ha själva ramverket.

symfony/messenger

Den första kandidaten verkade omedelbart perfekt och utan tvekan installerade jag den. Men att hitta exempel på användning utanför Symfony visade sig vara svårare. Hur samlar man från en massa klasser med generiska, meningslösa namn, en bus för att överföra meddelanden, och dessutom på Redis?

Dokumentationen på den officiella sidan var tillräckligt detaljerad, men initialiseringen beskrevs endast för Symfony med hjälp av deras älskade YML och andra magiska metoder för dem som inte är Symfony-användare. Jag hade inget intresse för själva installationsprocessen, särskilt under nyårshelgerna. Men jag var tvungen att ge mig på det och det tog oväntat lång tid.

Att försöka förstå instanseringen av systemet utifrån Symfony-källkoden är inte heller en helt trivial uppgift med tighta tidsramar:

Efter att ha rotat i allt detta och försökt göra något för hand kom jag till slutsatsen att jag arbetade med något slags nödlösningar och bestämde mig för att prova något annat.

illuminate/queue

Det visade sig att detta bibliotek är djupt kopplat till Laravel-infrastrukturen och många andra beroenden, så jag lade inte ner mycket tid på det: jag installerade det, tittade, såg beroendena och tog bort det.

yiisoft/yii2-queue

Här antyder namnet direkt en stark koppling till Yii2. Jag har använt detta bibliotek och det var ganska bra, men jag hade inte tänkt på att det helt beror på Yii2.

Övriga

Allt annat jag hittade på GitHub var opålitliga, föråldrade och övergivna projekt utan stjärnor, forks eller ett stort antal commits.

Återgång till symfony/messenger, tekniska detaljer

Jag var tvungen att sätta mig in i detta bibliotek och, efter att ha spenderat lite mer tid, lyckades jag. Det visade sig vara ganska enkelt och klart. För att instansiera busen skapade jag en liten fabrik, eftersom jag planerade att ha flera bussar med olika handlare.

Bara några steg:

• Skapa meddelandehanterare som bara ska vara callable
• Vi sveper in dem i HandlerDescriptor (en klass från biblioteket)
• Dessa "Deskriptorer" sveps in i en instans av HandlersLocator
• Lägg till HandlersLocator i en instans av MessageBus
• Överför en uppsättning `SenderInterface` till SendersLocator, i mitt fall instanser av klasserna `RedisTransport`, som konfigureras uppenbart
• Lägg till SendersLocator i en instans av MessageBus

MessageBus har en metod `->dispatch()`, som letar efter motsvarande hanterare i HandlersLocator och överför meddelandet till dem, med hjälp av motsvarande `SenderInterface` för att skicka via bussen (Redis streams).

I konfigurationen av containern (i detta fall php-di) kan hela denna koppling konfigureras så här:

        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);
        },

Här kan vi se att vi har tilldelat olika "transporter" för två olika meddelanden i SendersLocator, var och en av dem har sin egen anslutning till motsvarande strömmar.

Jag har gjort ett separat demoprojekt som visar en applikation av tre demonprocesser som kommunicerar med varandra via en sådan buss: https://github.com/backend-university/products/tree/master/products/02-redis-streams-bus.

Men jag visar hur en konsument kan vara organiserad:

använd 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();

Användningen av denna infrastruktur i applikationen

Genom att implementera bussen i min backend separerade jag olika steg från det gamla synkrona kommandot och gjorde separata handlare, var och en med sitt eget ansvarsområde.

Pipeline för att lägga till en ny webbplats i databasen blev så här:

Och genast efter detta blev det mycket enklare för mig att lägga till nya funktioner, till exempel att extrahera och bearbeta Rss. Eftersom denna process också kräver ursprungsinnehåll, prenumererar handlern som extraherar länkar till rss, precis som WebsiteIndexHistoryPersistor, på meddelandet "Content/HtmlContent", bearbetar det och vidarebefordrar rätt meddelande genom sin egen pipeline.

I slutändan blev det flera daemoner, var och en som håller anslutningar endast till nödvändiga resurser. Till exempel är daemonen crawlers innehåller alla hanterare som kräver åtkomst till internet för innehåll, medan daemonen persister håller anslutningen till databasen.

Nu, istället för att göra select-frågor från databasen, skickas de nödvändiga id:n efter att de har lagts till av persistern enkelt genom bussen till alla intresserade hanterare.

Källa: habr.com