Architecture

Architektura

Tento dokument popisuje architekturu Hazelcast Locks Server a jeho roli v systémech, jako jsou Kramerius a Akubra.

Přehled

Hazelcast Locks Server běží jako samostatný Hazelcast server node. Aplikace, například Akubra, se k němu připojují jako Hazelcast klienti a využívají jej pro získávání distribuovaných read/write zámků.

Server samotný neobsahuje žádnou aplikační logiku. Jeho jedinou odpovědností je správa stavu zámků a koordinace souběžného přístupu mezi klienty.

Role komponent

Hazelcast Locks Server

• Běží jako samostatný Java proces
• Hostuje Hazelcast datové struktury
• Spravuje distribuované zámky
• Slouží jako centrální synchronizační bod

Klientské aplikace (např. Akubra)

• Připojují se pomocí Hazelcast klientské konfigurace
• Získávají a uvolňují zámky
• Neukládají žádný stav zámků lokálně
• Předpokládají dostupnost serveru před vlastním startem

Server–klient model

Architektura je postavena na jasném modelu server–klient:

• Server vlastní všechny synchronizační primitivy
• Klienti jsou z hlediska zamykání bezstavoví
• Konzistence zámků je garantována Hazelcastem

Tento přístup eliminuje potřebu:

• zamykání na úrovni filesystemu
• synchronizace pomocí databáze
• těsné vazby mezi jednotlivými klienty

Model nasazení

Ve většině nasazení:

• server běží v Dockeru
• klienti se připojují přes interní síť

Vztah k Akubře

Akubra využívá Hazelcast Locks Server k:

• synchronizaci přístupu ke sdílenému úložišti
• prevenci souběžných zápisů
• koordinaci dlouhotrvajících operací

Z pohledu Akubry je Hazelcast Locks Server externí infrastrukturní závislost, která musí být spuštěna dříve než samotná aplikace Akubra.