Distribuirano zaključavanje za rojeve agenata: sprječavanje sukoba u Postgresu

U svijetu modernih aplikacija, agent swarms (rojevi agenata) postaju sve češći obrazac za izvođenje paralelnih zadataka. No, kada više agenata istovremeno pokušava ažurirati taj redak u bazi podataka, dolazi do ozbiljnih problema s konzistencijom. U ovom članku objašnjavamo kako smo riješili taj problem koristeći Postgres advisory locks i row-level FOR UPDATE.

Problem: istovremeno uređivanje istog retka

Zamislite scenarij u kojem dva agenta dobivaju zadatak ažurirati taj redak u tablici 'orders'. Bez odgovarajuće koordinacije, oba agenta mogu pročitati staru vrijednost, izračunati novu i zapisati je, pri čemu će jedan od njih prepisati rad drugog. To dovodi do gubitka podataka i netočnih stanja.

Rješenje: Postgres advisory locks

Postgres nudi ugrađeni mehanizam za distribuirano zaključavanje putem advisory locks. Ovi lockovi nisu vezani ni za jedan redak ili tablicu, već su definirani proizvoljnim ključem (npr. ID retka). Agent koji želi urediti redak prvo mora dobiti advisory lock na ključ koji odgovara ID-u tog retka. Ako je lock već zauzet, agent čeka ili odustaje.

Implementacija: row-level FOR UPDATE

Osim advisory locks, koristili smo i FOR UPDATE klauzulu u SELECT upitu. Ova klauzula zaključava redak na razini baze podataka, sprječavajući druge transakcije da ga istovremeno mijenjaju. Kombinacija ova dva pristupa osigurava da samo jedan agent može uređivati redak u bilo kojem trenutku.

Primjer koda

Evo kako izgleda implementacija u Pythonu s psycopg2:

• Agent generira jedinstveni ključ za redak (npr. 'order_123')
• Pokušava dobiti advisory lock: SELECT pg_try_advisory_lock(hashtext('order_123'))
• Ako lock nije dobiven, agent odustaje ili ponovno pokušava nakon čekanja
• Ako lock jest dobiven, agent izvršava SELECT ... FOR UPDATE na retku
• Nakon ažuriranja, agent oslobađa lock: SELECT pg_advisory_unlock(hashtext('order_123'))

Prednosti i mane

Prednosti: jednostavnost implementacije, nema potrebe za vanjskim servisom (npr. Redis), izvrsna izvedba za male do srednje velike sustave. Mane: advisory locks su specifični za Postgres, pa migracija na drugu bazu podataka zahtijeva promjenu pristupa. Također, lockovi se ne oslobađaju automatski ako agent padne, stoga je potrebno implementirati timeout ili heartbeat mehanizam.

Zaključak

Distribuirano zaključavanje pomoću Postgres advisory locks i row-level FOR UPDATE pruža robustno rješenje za sprječavanje sukoba u agent swarms. Iako nije univerzalno rješenje, za većinu scenarija s Postgresom ono je dovoljno jednostavno i učinkovito.