30. december 2003 - 22:06Der er
17 kommentarer og 2 løsninger
Design-knude i clustret server-system
Jeg har en clustret server kørende, der dækker over et antal slaver og én master. De egentlige klienter er fordelt mellem slave-serverne. Hver klient har et tilknyttet objekt med en lang række data, der er persisteret i en database. Når klienten logger på en slave eller hvis klientens data skal bruges i en anden sammenhæng, indlæses og caches pt. data-objektet på en slave og hvilken slave der har hvilke klienters data-objekter cached, registreres på master-serveren. Logger en klient af en slave-server, forbliver data-objektet chached et stykke tid efter.
Andre del-komponenter i det samlede system, andre end de egentlige klienter, kan tilgå og manipulere med klienternes data-objekter. Disse manipulationer sendes altid til master-serveren, som sender forespørgslerne videre til den slave der har det ønskede data-objekt liggende; har ingen slave det ønskede objekt, vælges en tilfældig slave, som så indlæser det fra databasen.
Mit problem er håndteringen af klienternes data-objekter, som kan være spredt over forskellige slaver, men kan tilgås via master-serveren eller slaven selv. Hvis nu en manipulations-forespørgsel modtages på masteren og data-objektet ikke findes på nogen slaver, beordres en slave til at indlæse objektet, men hvis en masteren modtager endnu en forespørgsel hurtigt efter, vil slaven forsøge at indlæse objektet igen. Læsninger fra databasen foregår asynkront, idet en database-pool med egne tråde kører alle statements og returnerer resultatet. Flere situationer kan resulterer i at data-objekter indlæses fra databasen to gange, hvilket ikke må ske.
Der gives point for ideer der kan hjælpe til at forenkle håndteringen af data-objekterne i clusteret. Håber det jeg har skrevet er til at forstå.
Nej jeg tænker på klasserne: LockManager DistributedLockManager
Jeg har faktisk aldrig brugt den, men jeg kender DLM fra andre sammenhænge.
Princippet i en DLM er den samme som du kender fra multithreaded app, hvor du kan synchronize på et objekt for at forhindre uhensigtsmæssige samtidigheds problemer. Her synkroniserer du bare ikke mellem tråde i samme JVM men mellem forskellige JVM's på forskellige maskiner.
Jeg har som sagt aldrig brugt denne DLM. Men det må vel være til at finde ud af at bruge.
Hvad med at låse data når en 'slave' læser det ind. SELECT ... FOR UPDATE.. Er data låst ved du at det er ved at blive læst ind. Er data ikke låst er det enten tilgængeligt på en slave - eller skal læses ind af en?
Det kan gøres let eller svært - lidt afhængig af din platform og hvilken transaktionsstyring den stiller til rådighed..
Jeg kører mod MySQL, så der er ikke adgang til transaktionsstyring gerigennem; jeg er dog ikke klar over om den låser tabellerne ved læsning, eller om den er smart nok til at lade være. Det er egentlig en pointe jeg ikke lige har været opmærksom ellers...
Hvis serverne indbyrdes skal arbejde med transaktioner, så kan de det ikke pt., men der lyder JGroups til at kunne gøre det.
Jeg arbejder normalt i J2EE-verdenen hvor platformen (applikationsserveren) stiller en række services til rådighed. Et eksempel på en central service er transaktionsstyring en anden er styring af 'isolation-levels'.
Uden en applikationsserver (eller noget andet der stiller de ting til rådighed) kommer du til selv at implementere det.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
