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é read/write zámky
• Slouží jako centrální synchronizační bod
• Může běžet jako single-node nebo multi-node cluster

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í:

• postačuje jedna instance Hazelcast Locks Server
• server běží v Dockeru
• klienti se připojují přes interní síť

Architektura umožňuje horizontální škálování, avšak z důvodu jednoduchosti je preferováno single-node řešení, pokud nejsou kladeny vyšší nároky na dostupnost.

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.