Integracja z Allegro w systemach B2C często zaczyna się od prostego założenia: „pobrać produkty i zapisać w bazie”. Na papierze wygląda to banalnie – do momentu, gdy klient zamiast 50 ofert, wystawia ich 5000, a każda ma galerię zdjęć w wysokiej rozdzielczości.
W jednym z naszych projektów takie podejście doprowadziło system do ściany. Oto jak przebudowaliśmy architekturę, przechodząc z synchronicznego skryptu na system asynchronicznych workerów.
Dlaczego klasyczny PHP „pęka”?
Standardowy model request-response (jeden skrypt wykonujący wszystko po kolei) przy dużej skali generuje te same problemy:
- Maximum execution time exceeded – skrypt ubijany przez serwer.
- 504 Gateway Timeout – serwer WWW traci cierpliwość w oczekiwaniu na odpowiedź.
- Zatory I/O – skrypt marnuje 90% czasu na czekanie, aż zdjęcia pobiorą się z zewnętrznych serwerów.
Zamiast zwiększać limity w php.ini, postawiliśmy na RabbitMQ i architekturę opartą o wyspecjalizowane procesy.
Architektura: 6 kroków do stabilności
Zamiast jednego „monolitycznego” skryptu, import podzieliliśmy na niezależne etapy (workery). Każdy z nich ma tylko jedno zadanie:
1. Synchronizacja kategorii (importCatsAllegro)
Zanim zaczniemy import, musimy znać strukturę Allegro. Ten worker dba o to, by drzewo kategorii w naszej bazie było zawsze aktualne.
2. Mózg operacji (importSoapAllegro)
To dispatcher. Pobiera dane z API Allegro, ale ich nie przetwarza. Rozdziela zadania na dwie ścieżki:
- Dane tekstowe/numeryczne wysyła do kolejki produktów.
- Adresy URL obrazów wysyła do kolejki zdjęć.
3. Zapis danych biznesowych (saveProductsData)
Ten worker zajmuje się wyłącznie „tekstami”. Dzięki temu, że nie dotyka ciężkich plików, potrafi przetworzyć tysiące rekordów w sekundy.
4. Ciężka praca z mediami (downloadImage)
To tutaj dzieje się magia skalowania. Worker pobiera zdjęcie, skaluje je do kilku rozmiarów i wysyła na serwer plików. To najwolniejszy etap, dlatego możemy uruchomić np. 20 jego instancji jednocześnie, by przyspieszyć proces.
5. Finalizacja (saveImagesData)
Gdy zdjęcia są gotowe i fizycznie znajdują się na serwerze, ten worker spina je z odpowiednimi produktami w bazie danych.
6. Centralne logowanie (saveLog)
Wszystkie błędy (np. niedziałający link do zdjęcia) trafiają tutaj. Mamy pełną analitykę importu bez zaśmiecania głównych procesów.
Co zyskaliśmy? Skalowanie horyzontalne
Największą zaletą tej architektury jest to, że PHP przestaje być ograniczony jednym procesem. Dzięki zastosowaniu Docker-a i RabbitMQ:
- Skalujemy tam, gdzie boli: Widzimy, że kolejka zdjęć rośnie? Dokładamy 10 kolejnych workerów
downloadImage. - Odporność na błędy: Jeśli jeden obrazek jest uszkodzony, worker po prostu loguje błąd i bierze kolejne zadanie. Import nie przerywa się w połowie.
- User Experience: Administrator systemu widzi postęp w czasie rzeczywistym, a strona sklepu nie „wiesza się” podczas ogromnych aktualizacji stanów.
Wniosek dla architektów: PHP nie jest problemem – problemem bywa model wykonania. Przejście na asynchroniczność pozwala budować systemy gotowe na miliony produktów bez konieczności zmiany całego ekosystemu technologicznego.