Introduktion til Big Queue

1. Oversigt

I denne tutorial tager vi et hurtigt kig på Big Queue, en Java-implementering af en vedvarende kø.

Vi snakker lidt om dens arkitektur, og så lærer vi, hvordan vi bruger den gennem hurtige og praktiske eksempler.

2. Anvendelse

Vi bliver nødt til at tilføje bigqueue afhængighed af vores projekt:

 com.leansoft bigqueue 0.7.0 

Vi skal også tilføje dets lager:

 github.release.repo //raw.github.com/bulldog2011/bulldog-repo/master/repo/releases/ 

Hvis vi er vant til at arbejde med grundlæggende køer, vil det være en leg at tilpasse sig Big Queue, da API'et er meget ens.

2.1. Initialisering

Vi kan initialisere vores kø ved simpelthen at kalde sin konstruktør:

@Før offentlig ugyldig opsætning () {String queueDir = System.getProperty ("user.home"); String kønavn = "baeldung-kø"; bigQueue = ny BigQueueImpl (køDir, kønavn); }

Det første argument er hjemmekataloget til vores kø.

Det andet argument repræsenterer vores køs navn. Det opretter en mappe inde i vores køs hjemmekatalog, hvor vi kan vedvare data.

Vi skal huske at lukke vores kø, når vi er færdige for at forhindre hukommelseslækage:

bigQueue.close ();

2.2. Indsættelse

Vi kan tilføje elementer til halen ved blot at kalde enqueue metode:

@Test offentligt ugyldigt nårAddingRecords_ThenTheSizeIsCorrect () {for (int i = 1; i <= 100; i ++) {bigQueue.enqueue (String.valueOf (i) .getBytes ()); } assertEquals (100, bigQueue.size ()); }

Vi skal bemærke, at Big Queue kun understøtter byte [] datatype, så vi er ansvarlige for at serialisere vores poster, når vi indsætter.

2.3. Læsning

Som vi måske havde forventet, er læsning af data lige så let at bruge dequeue metode:

@Test offentligt ugyldigt nårAddingRecords_ThenTheyCanBeRetrieved () {bigQueue.enqueue (String.valueOf ("new_record"). GetBytes ()); String record = new String (bigQueue.dequeue ()); assertEquals ("new_record", record); }

Vi skal også være forsigtige med at deserialisere vores data korrekt, når vi læser.

Læsning fra en tom kø kaster en NullPointerException.

Vi bør kontrollere, at der er værdier i vores kø ved hjælp af er tom metode:

hvis (! bigQueue.isEmpty ()) {// læse}

For at tømme vores kø uden at skulle gennemgå hver post, kan vi bruge Fjern alt metode:

bigQueue.removeAll ();

2.4. Kigger

Når vi kigger, læser vi simpelthen en post uden at forbruge den:

@Test offentlig ugyldig nårPeekingRecords_ThenSizeDoesntChange () {for (int i = 1; i <= 100; i ++) {bigQueue.enqueue (String.valueOf (i) .getBytes ()); } Streng firstRecord = ny streng (bigQueue.peek ()); assertEquals ("1", firstRecord); assertEquals (100, bigQueue.size ()); }

2.5. Sletning af forbrugte poster

Når vi ringer til dequeue metode fjernes poster fra vores kø, men de forbliver vedvarende på disken.

Dette kan potentielt fylde vores disk med unødvendige data.

Heldigvis kan vi slette de forbrugte poster ved hjælp af gc metode:

bigQueue.gc ();

Ligesom skraldopsamleren i Java rydder op i ikke-henviste genstande fra dyngen, gc renser forbrugte poster fra vores disk.

3. Arkitektur og funktioner

Hvad der er interessant ved Big Queue er, at dens codebase er ekstremt lille - kun 12 kildefiler, der optager omkring 20 KB diskplads.

På et højt niveau er det bare en vedvarende kø, der udmærker sig ved håndtering af store mængder data.

3.1. Håndtering af store datamængder

Køens størrelse er kun begrænset af vores samlede tilgængelige diskplads. Hver post inde i vores kø er vedvarende på disken for at være kollisionsresistent.

Vores flaskehals vil være disk I / O, hvilket betyder, at en SSD forbedrer den gennemsnitlige gennemstrømning betydeligt over en harddisk.

3.2. Adgang til data ekstremt hurtigt

Hvis vi ser på kildekoden, bemærker vi, at køen bakkes op af en hukommelseskortet fil. Den tilgængelige del af vores kø (hovedet) opbevares i RAM, så adgang til poster vil være ekstremt hurtig.

Selvom vores kø ville vokse ekstremt stor og ville optage terabyte diskplads, ville vi stadig være i stand til at læse data i O (1) tidskompleksitet.

Hvis vi har brug for at læse mange meddelelser, og hastighed er et kritisk problem, bør vi overveje at bruge en SSD over en harddisk, da flytning af data fra disk til hukommelse ville være meget hurtigere.

3.3. Fordele

En stor fordel er dens evne til at vokse meget stor i størrelse. Vi kan skalere det til teoretisk uendelighed ved blot at tilføje mere lagerplads, deraf navnet "Big".

I et samtidig miljø kan Big Queue producere og forbruge omkring 166 Mbps data på en råvaremaskine.

Hvis vores gennemsnitlige beskedstørrelse er 1 KB, kan den behandle 166k meddelelser pr. Sekund.

Det kan gå op til 333k beskeder pr. Sekund i et enkelt trådmiljø - ret imponerende!

3.4. Ulemper

Vores meddelelser forbliver vedvarende til disk, selv efter at vi har brugt dem, så vi skal tage os af skraldindsamlingsdata, når vi ikke længere har brug for det.

Vi er også ansvarlige for serialisering og deserialisering af vores meddelelser.

4. Konklusion

I denne hurtige vejledning lærte vi om Big Queue, og hvordan vi kan bruge den som en skalerbar og vedvarende kø.

Som altid er koden tilgængelig på Github.


$config[zx-auto] not found$config[zx-overlay] not found