Jest to wpis testowy, więc nie bijcie W pracy często spotykam się z brakiem zrozumienia problemu latencji w - def

defGruba ryba

Jest to wpis testowy, więc nie bijcie

W pracy często spotykam się z brakiem zrozumienia problemu latencji w replikacji danych. Wyobraźmy sobie sytuację: mamy aplikacje hejto, która zapisuje piorun użytkownika w bazie, mamy 5 instancji MySQL w konfiguracji master-master. Przyjmijmy, że mamy tabelkę user_post_likes która ma pola user_id, post_id. Endopoint wygląda następująco:

Header: Authorization Bearer ...
POST /posts/{id}/like

Endpoint najpierw sprawdza czy użytkownik nie dodał już wpisu przez zapytanie do sql, jeśli nie to dodaje w tabelce wpis, wszystko dzieje się w transakcji, bo developer był sprytny.

Użytkownik szybko klika 2 razy pioruna: robią się 2 wpisy w tabelce, zdziwiony developer nie wie jak to się mogło stać, przecież użył transakcji.

Pierwszy request przez load balancer połaczył się z instnacją aplikacji połączonej do instancji A bazy danych, natomiast drugi do instancji B, gdzie dane nie zostały jeszcze zsynchronizowane.

Aby uniknąć takiej sytuacji używam redisa z dość krótkim trzymaniej danych i kluczem "addlike{id_post}.{id_usera}", jeśli znajdzie taki wpis, to nie dodaje jeszcze raz wpisu do bazy. Przed taką sytuacją uchroni też index unique, ale powoduje to zazwyczaj inne problemy.

Komentarze (8)

Mr_SwistakInspirator2 lata temu0

Totalnie nie siedzę w bazach danych, jestem samoukiem robiącym gry zawodowo w unity więc bazy danych których używam to w większości proste kwestie, a jak już się robi poważniej to mam backendowca w zespole xd

Ten problem który opisałeś, rozwiązałbym prostą kolejką operacji, gdzie user wrzuca request na bęben i czeka na odpowiedź. Rozumiem że tak działa transakcja?
W kwestii tych lajkow to nie kumam dokładnie gdzie jest problem, sprawdzałbym poprawność requestow. Jeden z warunków, który i tak musiałby być w jakimś zabezpieczeniu antyfloodowym, to właśnie odrzucanie wielokrotnych zapytań w danym okresie czasu

defGruba ryba2 lata temu0

@Mr_Hardy jak pisalem wyzej problem wlasnie pojawia sie u mnie kiedy na kolejce musialem przerzucic duze ilosci danych, popchnac informacje i np popchnac informacje o zmianach na webosocket, gdzie okazalo sie ze klient dostal odpowiedz z serwera mysql, ktory jeszcze nie zdazyl sie zsynchronizowac

Mr_SwistakInspirator2 lata temu0

Jeżeli masz ochotę wytłumaczyć laikowi gdzie jest faktycznie problem w tym co opisujesz, to chętnie bym to zrozumiał xD

wombatDaiquiriGruba ryba2 lata temu1

@def

Przed taką sytuacją uchroni też index unique, ale powoduje to zazwyczaj inne problemy.

Tzn. jakie? Masz realnie produkcyjnie ruch taki że MySQL nie wyrabia z opierdoleniem lajków? Pracujesz w Facebooku?

defGruba ryba2 lata temu1

@wombatDaiquiri to nie byl realny przyklad, ale w codziennej pracy kam problem, gdzie na kolejkach przerzucamy duze ilosci rekordow, index unique powoduje wtedy wywalenie sie polaczenia z baza (kwestia ftameworka)

wombatDaiquiriGruba ryba2 lata temu0

@cododiaska wątpię. Wydaje mi się że mówimy o dziesiątkach tysięcy operacji na sekundę. W Polsce jestem prawie pewien że żaden portal nie ma takiego ruchu. Albo mówimy o naprawdę masywnych tabelach bez indeksów (?)

cododiaskaAutorytet2 lata temu0

@wombatDaiquiri wystarczy, że z rana odpalą trollom nowy przekaz dnia z Nowogrodzkiej. Albo pojawią się nieprzychylne Partii sondaże :smiley:

parapet-infernoKoneser2 lata temu0

@def oooo będę to przerabiał niego, dzięki xd

Wpis użytkownika def w Hydepark

Komentarze (8)