[rysi3k_]

Szukam jakiś patternów, koncepcji pomysłów na rozwiązanie takiego problemu z #microservices:
0. (przykład nieco uproszczony, dla ułatwienia)
1. serwis przyjmuje po http request wykonania zadania, nie czeka na zakończenie
2. zadanie może trwać kilka godzin
3. każde zadanie polega na cyklicznym odpytywaniu zewnętrznego serwisu po http
4. gdy się zakonczy, zapisujemy status do bazy danych
5. może przyjśc po http żądanie przerwania pracy lub zrestartowania
Ogólnie mam do tego jeden serwis w #nodejs i do około 10000 jednoczesnych zadań, na kilku wątkach jestem w stanie obsługiwać. Jednak to za mało, potrzebujemy się skalować by móc wspierać więcej. No i tu natrafiam na problemy w stylu:
- procesowanie zadania odbywa się na instancji A
- request przerwania (poprzez balancer z przodu) trafia na instancję B

Jakie techniki polecacie wykorzystać? Jakieć pomysły jak podobne problemy rozwiazać? #programowanie #programista15k

[Verbatino]

@rysi3k_: Message queues.

[scriptkitty]

@rysi3k_: Zapisuj taski w redisie, jest superszybki. Do tego osobne workery pobierające z redisa, wykonujące zapytania i zapisujące wynik w bazie.

[rysi3k_]

@scriptkitty: Mniej więcej to mam. A co z przerwaniem joba?

[scriptkitty]

@rysi3k_: A to są długotrwające taski? Jeśli nie to usunięcie z redisa wystarczy. Jeśli tak to ustawiasz jakąś flagę w redisie i długotrwający task będzie musiał co jakiś czas sprawdzać czy nie powinien być przerwany.

[rysi3k_]

@zibizz1: na szybko patrząc to googlowe? Siedzimy na AWS więc jakiegoś odpowiednika bym potrzebował. Kojarzysz?

[rysi3k_]

@scriptkitty: No kilka godzin może być...

[scriptkitty]

@rysi3k_: No to tak jak napisałem wyżej

[zibizz1]

@rysi3k_: szukaj pod nazwa realtime db ale to bardzo mało popularny typ bazy NoSQL, gdzie całyczas utrzymujesz połączenie TCP i możesz nasłuchiwać na zmiany dokumentów

[zibizz1]

@rysi3k_: DynamoDB też to ma
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html

[zibizz1]

@rysi3k_: Taka rada odnośnie dynamoDB to trzymać małe dokumeny(rekordy w tabeli) i używać krótkich nazw pól. W jednym projekcie w którym robiłem jeden model był rozbity na kilkanascie tabeli i nazwy pól były max 2 literowe. Płaci się za każdy read/writeCapacityUnit czyli najlepiej pilnować żeby dokumenty miały <4KB