streamalism.org

1. Oversikt

I denne opplæringen skal vi se raskt på Big Queue, en Java-implementering av en vedvarende kø.

Vi snakker litt om arkitekturen, og så lærer vi hvordan vi bruker den gjennom raske og praktiske eksempler.

2. Bruk

Vi må legge til bigqueue avhengighet av prosjektet vårt:

 com.leansoft bigqueue 0.7.0 

Vi må også legge til depotet:

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

Hvis vi er vant til å jobbe med grunnleggende køer, vil det være en lek å tilpasse seg Big Queue, da API-en er ganske lik.

2.1. Initialisering

Vi kan initialisere køen vår ved å enkelt ringe konstruktøren:

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

Det første argumentet er hjemmekatalogen for køen vår.

Det andre argumentet representerer køens navn. Det oppretter en mappe i køens hjemmekatalog der vi kan vedvare data.

Vi bør huske å lukke køen når vi er ferdige for å forhindre minnelekkasjer:

bigQueue.close ();

2.2. Setter inn

Vi kan legge til elementer i halen ved ganske enkelt å ringe enqueue metode:

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

Vi bør merke oss at Big Queue bare støtter byte [] datatype, så vi er ansvarlige for å serialisere våre poster når vi setter inn.

2.3. Lesning

Som vi kanskje hadde forventet, er det like enkelt å lese data dequeue metode:

@Test offentlig ugyldig nårAddingRecords_ThenTheyCanBeRetrieved () {bigQueue.enqueue (String.valueOf ("new_record"). GetBytes ()); Strengrekord = ny streng (bigQueue.dequeue ()); assertEquals ("new_record", post); }

Vi må også være forsiktige med å deserialisere dataene våre riktig når vi leser.

Å lese fra en tom kø kaster a NullPointerException.

Vi bør bekrefte at det er verdier i køen vår ved hjelp av er tom metode:

hvis (! bigQueue.isEmpty ()) {// lese}

For å tømme køen vår uten å måtte gå gjennom hver post, kan vi bruke Fjern alle metode:

bigQueue.removeAll ();

2.4. Titter

Når vi titter, leser vi ganske enkelt en plate uten å konsumere 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. Slette forbrukte poster

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

Dette kan potensielt fylle opp disken vår med unødvendige data.

Heldigvis kan vi slette de konsumerte postene ved hjelp av gc metode:

bigQueue.gc ();

Akkurat som søppeloppsamleren i Java rydder opp objekter som ikke er referert fra dyngen, gc renser forbrukte poster fra disken vår.

3. Arkitektur og funksjoner

Det som er interessant med Big Queue er det faktum at kodebasen er ekstremt liten - bare 12 kildefiler som tar omtrent 20 KB diskplass.

På høyt nivå er det bare en vedvarende kø som utmerker seg ved håndtering av store datamengder.

3.1. Håndtere store datamengder

Størrelsen på køen er bare begrenset av vår totale tilgjengelige diskplass. Hver plate i køen vår er vedvarende på disken for å være kollisjonsbestandig.

Flaskehalsen vår vil være diskens I / O, noe som betyr at en SSD vil forbedre den gjennomsnittlige gjennomstrømningen over en harddisk betydelig.

3.2. Få tilgang til data ekstremt raskt

Hvis vi tar en titt på kildekoden, vil vi legge merke til at køen støttes av en minnekartet fil. Den tilgjengelige delen av køen vår (hodet) holdes i RAM, slik at tilgang til poster vil være ekstremt rask.

Selv om køen vår ville bli ekstremt stor og ville oppta terabyte diskplass, ville vi fortsatt kunne lese data i O (1) tidskompleksitet.

Hvis vi trenger å lese mange meldinger, og hastighet er en kritisk bekymring, bør vi vurdere å bruke en SSD over en harddisk, da flytting av data fra disk til minne vil være mye raskere.

3.3. Fordeler

En stor fordel er dens evne til å bli veldig stor i størrelse. Vi kan skalere den til teoretisk uendelig ved å bare legge til mer lagringsplass, derav navnet "Big".

I et samtidig miljø kan Big Queue produsere og forbruke rundt 166 Mbps data på en varemaskin.

Hvis den gjennomsnittlige meldingsstørrelsen vår er 1 KB, kan den behandle 166 000 meldinger per sekund.

Det kan gå opp til 333k meldinger per sekund i et miljø med en tråd - ganske imponerende!

3.4. Ulemper

Meldingene våre forblir vedvarende til disken, selv etter at vi har konsumert dem, så vi må ta vare på data som samler inn søppel når vi ikke lenger trenger det.

Vi er også ansvarlige for serialisering og deserialisering av meldingene våre.

4. Konklusjon

I denne raske opplæringen lærte vi om Big Queue og hvordan vi kan bruke den som en skalerbar og vedvarende kø.

Som alltid er koden tilgjengelig på Github.