Mysql
 sql >> Baza danych >  >> RDS >> Mysql

Jak zarządzać procesami po stronie serwera za pomocą MySQL

Wygląda na to, że próbujesz uruchomić długotrwałe procesy z serwera WWW, a następnie śledzić te procesy w bazie danych. To nie jest niemożliwe, ale nie jest to zalecana praktyka.

Główny problem polega na tym, że żądanie HTTP musi być aktualnie obsługiwane przez serwer WWW, a Ty faktycznie rób cokolwiek (w tym śledzenie procesów działających w systemie) - potrzebujesz czegoś, co może działać przez cały czas...

Zamiast tego lepszym pomysłem byłoby posiadanie innego demonizowanego procesu „zarządzającego” (jak wspominasz perl, byłby to dobry język do pisania tego) odradzającego i śledzącego długo działające zadania (poprzez PID i sygnały) i do tego proces aktualizacji bazy danych SQL.

Następnie możesz nakazać swojemu „menedżerowi” nasłuchiwanie żądań uruchomienia nowego procesu z serwera WWW. Istnieje wiele mechanizmów IPC, których możesz użyć. (np. sygnały, SysV shm, gniazda domeny unix, kolejki w procesie, takie jak ZeroMQ itp.).

Ma to wiele zalet:

  • Jeśli Twoje skrypty muszą działać z izolacją opartą na użytkownikach/grupach (albo z systemu, albo od siebie), to Twój serwer internetowy nie musi działać jako root ani być ustawiony gid.
  • Jeśli wygenerowany proces „ulegnie awarii”, sygnał zostanie dostarczony do procesu „menedżera”, aby mógł bezproblemowo śledzić nieprawidłowe wykonanie.
  • Jeśli używasz kolejek w procesie (np. ZeroMQ) do dostarczania żądań do procesu „menedżera”, może on „dławić” żądania z serwera sieciowego (aby użytkownicy nie mogli celowo lub przypadkowo wywołać D.O.S).
  • Niezależnie od tego, czy wygenerowany proces zakończy się dobrze, nie potrzebujesz „aktywnego” żądania HTTP do serwera internetowego w celu zaktualizowania bazy danych śledzenia.

Co do tego, co powinno biec to biegać, to naprawdę zależy od twojej semantyki. (tj. czy opiera się na znanym czasie działania? na podstawie zużytych danych? itp.).

Sprawdzenie, czy jest bieganie może być dwojakie:

  1. Proces „menedżera” odpowiednio aktualizuje bazę danych, w tym wygenerowany PID.
  2. Kod hostowany przez Twój serwer sieciowy może w rzeczywistości wyświetlić listę procesów, aby określić, czy PID w bazie danych jest faktycznie biega, a nawet ile czasu robi coś pożytecznego!

Sprawdzenie, czy nie bieganie musiałoby być oparte na konwencji:

  1. Nazwij powstające procesy coś, co możesz przewidzieć.
  2. Uzyskaj listę procesów, aby określić, co nadal działa (nie działa?), a nie powinno.

W obu przypadkach możesz poinformować użytkowników, którzy zażądali odrodzenia procesów i/lub faktycznie coś z tym zrobić.

Jednym z rozwiązań może być posiadanie zadania CRON, które odczytuje z bazy danych SQL i wykonuje ps aby określić, które wytworzone procesy wymagają ponownego uruchomienia, a następnie ponownie żąda, aby proces „zarządzający” zrobił to przy użyciu tego samego mechanizmu IPC, który jest używany przez serwer sieciowy. To, jak odróżnisz uruchomienia od ponownych uruchomień w śledzeniu/monitorowaniu/rejestrowaniu, zależy od Ciebie.

Jeśli sam serwer utraci zasilanie lub ulegnie awarii, możesz poprosić proces „menedżera” o wykonanie czyszczenia przy pierwszym uruchomieniu, np.:

  1. Poszukaj wpisów w bazie danych dla procesów, które zostały wygenerowane, które rzekomo działały przed zamknięciem serwera.
  2. Sprawdź te procesy według PID i czasu działania (to ważne).
  3. Albo ponownie spawnuj procesy, które się nie zakończyły, albo przechowuj coś w bazie danych, aby wskazać serwerowi sieciowemu, że tak było.

Aktualizacja nr 1

Zgodnie z Twoim komentarzem, oto kilka wskazówek na początek:

Wspomniałeś o perlu, więc zakładając, że masz w tym pewną biegłość -- oto kilka modułów perla, które pomogą ci na drodze do napisania skryptu procesu „menedżera”:

Jeśli jeszcze go nie znasz CPAN jest repozytorium modułów perla, które robią w zasadzie wszystko.

Daemon::Daemonize - Aby demonizować proces, aby działał dalej po wylogowaniu. Zapewnia również metody pisania skryptów do uruchamiania/zatrzymywania/restartowania demona.

Proc::Spawn - Pomaga w „odradzaniu się” skryptów podrzędnych. Zasadniczo fork() następnie exec() , ale obsługuje również STDIN/STDOUT/STDERR (lub nawet tty) procesu potomnego. Możesz użyć tego do uruchomienia swoich długo działających skryptów perla.

Jeśli kod frontonu twojego serwera WWW nie jest jeszcze napisany w perlu, będziesz potrzebować czegoś, co jest całkiem przenośne do przekazywania wiadomości między procesami i kolejkowania; Prawdopodobnie zrobiłbym twój fronton serwera WWW w czymś łatwym do wdrożenia (takim jak PHP).

Oto dwie możliwości (jest wiele więcej):

Proc::ProcessTable - Możesz użyć tej kontroli w uruchomionych procesach (i uzyskać wszelkiego rodzaju statystyki, jak omówiono powyżej).

Time::HiRes - Użyj funkcji czasu o wysokiej szczegółowości z tego pakietu, aby zaimplementować strukturę „dławienia”. Po prostu ogranicz liczbę żądań usuwanych z kolejki w jednostce czasu.

DBI (z mysql ) - Zaktualizuj swoją bazę danych MySQL z procesu "menedżera".




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Zapytanie SQL:uporządkować według długości znaków?

  2. Jak wyszukiwać w polu daty dla ciągu znaków za pomocą interfejsu JPA Criteria API

  3. Wylicz wiersze w mysql na podstawie grup

  4. Wstawianie danych, jeśli liczba wierszy jest większa niż 0, nie działa

  5. W jaki sposób mysql odwraca rozwiązywanie adresów IP?