Inleiding tot Big Queue

1. Overzicht

In deze tutorial gaan we snel kijken naar Big Queue, een Java-implementatie van een permanente wachtrij.

We zullen een beetje praten over de architectuur, en dan zullen we leren hoe we het kunnen gebruiken aan de hand van snelle en praktische voorbeelden.

2. Gebruik

We moeten het bigqueue afhankelijkheid van ons project:

 com.leansoft bigqueue 0.7.0 

We moeten ook zijn repository toevoegen:

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

Als we gewend zijn om met standaardwachtrijen te werken, is het een fluitje van een cent om ons aan te passen aan Big Queue, omdat de API vrij gelijkaardig is.

2.1. Initialisatie

We kunnen onze wachtrij initialiseren door eenvoudig de constructor aan te roepen:

@Before public void setup () {String queueDir = System.getProperty ("user.home"); String queueName = "baeldung-wachtrij"; bigQueue = nieuwe BigQueueImpl (queueDir, queueName); }

Het eerste argument is de homedirectory voor onze wachtrij.

Het tweede argument vertegenwoordigt de naam van onze wachtrij. Het maakt een map aan in de homedirectory van onze wachtrij waar we gegevens kunnen bewaren.

We moeten onthouden om onze wachtrij te sluiten als we klaar zijn om geheugenlekken te voorkomen:

bigQueue.close ();

2.2. Invoegen

We kunnen elementen aan de staart toevoegen door simpelweg de in de wachtrij plaatsen methode:

@Test openbare leegte whenAddingRecords_ThenTheSizeIsCorrect () {voor (int i = 1; i <= 100; i ++) {bigQueue.enqueue (String.valueOf (i) .getBytes ()); } assertEquals (100, bigQueue.size ()); }

We moeten opmerken dat Big Queue alleen de byte[] gegevenstype, dus we zijn verantwoordelijk voor het serialiseren van onze records bij het invoegen.

2.3. Lezing

Zoals we misschien hadden verwacht, is het lezen van gegevens net zo eenvoudig met de de wachtrij methode:

@Test openbare leegte whenAddingRecords_ThenTheyCanBeRetrieved () {bigQueue.enqueue (String.valueOf ("nieuw_record"). GetBytes ()); String record = nieuwe String (bigQueue.dequeue ()); assertEquals ("new_record", record); }

We moeten ook voorzichtig zijn om onze gegevens correct te deserialiseren tijdens het lezen.

Bij het lezen vanuit een lege wachtrij wordt een NullPointerException.

We moeten controleren of er waarden in onze wachtrij staan ​​met behulp van de is leeg methode:

if (! bigQueue.isEmpty ()) {// read}

Om onze wachtrij leeg te maken zonder elk record te hoeven doorlopen, kunnen we de Verwijder alles methode:

bigQueue.removeAll ();

2.4. Gluren

Als we gluren, lezen we gewoon een record zonder het te consumeren:

@Test openbare leegte whenPeekingRecords_ThenSizeDoesntChange () {voor (int i = 1; i <= 100; i ++) {bigQueue.enqueue (String.valueOf (i) .getBytes ()); } String firstRecord = nieuwe String (bigQueue.peek ()); assertEquals ("1", firstRecord); assertEquals (100, bigQueue.size ()); }

2.5. Verbruikte records verwijderen

Als we de de wachtrij methode, worden records verwijderd uit onze wachtrij, maar blijven ze bewaard op schijf.

Dit kan onze schijf mogelijk vullen met onnodige gegevens.

Gelukkig kunnen we de verbruikte records verwijderen met de gc methode:

bigQueue.gc ();

Net zoals de garbage collector in Java niet-gerefereerde objecten uit de hoop opruimt, gc schoont verbruikte records van onze schijf op.

3. Architectuur en kenmerken

Wat interessant is aan Big Queue is het feit dat de codebase extreem klein is - slechts 12 bronbestanden die ongeveer 20 KB schijfruimte innemen.

Op een hoog niveau is het gewoon een aanhoudende wachtrij die uitblinkt in het verwerken van grote hoeveelheden gegevens.

3.1. Omgaan met grote hoeveelheden gegevens

De grootte van de wachtrij wordt alleen beperkt door onze totale beschikbare schijfruimte. Elk record in onze wachtrij wordt op schijf bewaard om crashbestendig te zijn.

Ons knelpunt is de schijf-I / O, wat betekent dat een SSD de gemiddelde doorvoer ten opzichte van een HDD aanzienlijk zal verbeteren.

3.2. Toegang tot gegevens extreem snel

Als we de broncode bekijken, zullen we zien dat de wachtrij wordt ondersteund door een geheugen toegewezen bestand. Het toegankelijke deel van onze wachtrij (het hoofd) wordt in RAM bewaard, dus het openen van records gaat extreem snel.

Zelfs als onze wachtrij extreem groot zou worden en terabytes aan schijfruimte zou innemen, zouden we nog steeds in staat zijn om gegevens in O (1) tijdcomplexiteit te lezen.

Als we veel berichten moeten lezen en snelheid een cruciale zorg is, zouden we moeten overwegen om een ​​SSD via een harde schijf te gebruiken, omdat het verplaatsen van gegevens van schijf naar geheugen veel sneller zou zijn.

3.3. Voordelen

Een groot voordeel is het vermogen om erg groot te worden. We kunnen het opschalen naar theoretische oneindigheid door gewoon meer opslagruimte toe te voegen, vandaar de naam "Big".

In een gelijktijdige omgeving kan Big Queue ongeveer 166 MBps aan gegevens produceren en verbruiken op een standaardmachine.

Als onze gemiddelde berichtgrootte 1 KB is, kan het 166.000 berichten per seconde verwerken.

Het kan tot 333.000 berichten per seconde gaan in een omgeving met één thread - behoorlijk indrukwekkend!

3.4. Nadelen

Onze berichten blijven op schijf staan, zelfs nadat we ze hebben opgebruikt, dus we moeten zorgen voor het verzamelen van gegevens wanneer we deze niet langer nodig hebben.

We zijn ook verantwoordelijk voor het serialiseren en deserialiseren van onze berichten.

4. Conclusie

In deze korte tutorial hebben we geleerd over Big Queue en hoe we het kunnen gebruiken als een schaalbare en permanente wachtrij.

Zoals altijd is de code beschikbaar op Github.


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