Warunki usługi i wyścigu REST

Question

Wyobraźmy sobie problem: Mam usługę REST, która jest implementowana za pomocą technologii Java/MySQL/Spring i HTTP/JSON. Klientami usługi REST są aplikacje mobilne. Jest więc możliwe, że ktoś zdekompiluje kod i otrzyma interfejs API usługi REST. (Tak, kod jest zaciemniony itp., Ale tak).

Problem: istnieje metoda POST wysyłania pieniędzy do innego użytkownika aplikacji. Martwię się, że ktoś może uzyskać API, napisać bota i wysłać żądanie POST 500 lub 5000 lub nawet 50 000 razy na sekundę. W rezultacie może wysłać więcej pieniędzy niż ma, ponieważ jeśli 1000 zgłoszeń jest przetwarzanych jednocześnie, sprawdzanie salda może być udane dla wszystkich 1000 zgłoszeń, jednak prawdziwa kwota na koncie może być wystarczająca tylko dla, powiedzmy, 50 wniosków.

Zasadniczo bardziej przypomina standardową "rasę" z wieloma wątkami. Problem polega na tym, że mam wiele serwerów i nie są one ze sobą powiązane. Tak więc, 300 żądań może przyjść do serwera A, 300 żądań może przyjść do serwera B, a żądania reszty mogą przyjść na serwer C.

Najlepszym pomysłem jaki mam, jest użycie czegoś takiego jak "WYBIERZ ... DO AKTUALIZACJI" i synchronizuj na poziomie bazy danych. Chciałbym jednak rozważyć inne rozwiązania.

Wszelkie pomysły lub sugestie?

Answer 1

Masz kilka opcji:

1. polegać na realizacji ACID bazy danych (MySQL w Twoim przypadku). Zakładając, że korzystasz z silnika InnoDB, musisz wybrać właściwy poziom izolacji transakcji (SET TRANSACTION syntax) w połączeniu z odpowiednim mechanizmem blokowania odczytów (SELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODE Locking Reads). Musisz dobrze zrozumieć te koncepcje, aby dokonać właściwego wyboru. Może się zdarzyć, że samo użycie właściwego poziomu izolacji zapobiegnie już wyścigowi nawet bez odczytu blokującego. Wady są niezgodne z skalowalnością i wiązaniem aplikacji z bazą danych RDBMS, więc na przykład trudniej będzie przenieść się do NoSQL.

2. Rozwiń swój koniec z powrotem do warstwy sieci i warstwy usług (opcja sugerowana przez atk w komentarzach). Pozwoli to na skalowanie instancji warstwy sieci niezależnie, zachowując jednocześnie jedną instancję warstwy usług. Posiadanie pojedynczej instancji warstwy usług umożliwia korzystanie z mechanizmów synchronizacji Java, takich jak bloki synchronised lub ReadWriteLock. Chociaż to rozwiązanie zadziała, nie polecam go, ponieważ zmniejsza skalowalność warstwy usług.

3. To jest ulepszenie poprzedniej opcji. Zamiast wbudowanych mechanizmów synchronizacji Java można użyć Distributed lock manager. Pozwoli to na skalowanie warstwy sieci i poziomu usług niezależnie.

Answer 2

W przypadku aplikacji o znaczeniu krytycznym najlepiej jest mieć wiele poziomów mechanizmów blokujących.

"SELECT ... FOR UPDATE" to dobry sposób na zrobienie tego, ale są one dość drogie, a kiedy spróbujesz zbombardować to z Charlesem, zobaczysz, że twój górny stos API będzie cierpieć, i ten prosty mechanizm dość łatwo okaleczy twoją infrastrukturę, podobnie jak wydarzenie DDoS.

Najpierw zaimplementuj go w warstwie Load Balancer/Proxy, aby zmniejszyć liczbę żądań na określone interwały z jednego adresu IP.

Następnie zastosuj blokadę współdzielonej warstwy pamięci podręcznej, w której wszystkie skrzynki są synchronizowane na niektórych klawiszach w zależności od tego, która krytyczna transakcja ma zostać zablokowana. Na przykład możesz użyć funkcji Redis GETSET lub INCR do atomistycznego ustawienia flagi przed wejściem do krytycznej ścieżki kodu. Odrzuć cokolwiek innego, aby uniknąć sytuacji, w której ci źli aktorzy będą trzymać się procesora/pamięci.

Możesz także zaimplementować takie rzeczy, jak pamięć podręczna APC (przed naciśnięciem klastra Redis/Memcache), aby wykonać podobne blokowanie w zależności od skrzynki. Jest to szybsze, ponieważ nie ma opóźnień w sieci.

Powyższy są niezbędne na górze za pomocą „SELECT ... FOR UPDATE”