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 "add_like_{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.

#systemdesign #programowanie
def userbar
545180c8-59c1-4dce-b714-e893311c959a
parapet-inferno

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

wombatDaiquiri

@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?

cododiaska

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

wombatDaiquiri

@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 (?)

def

@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)

Mr_Swistak

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

Mr_Swistak

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

def

@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

Zaloguj się aby komentować