In multidimensjonale kapasiteitswachtrige ûntwerpe

Kapasiteit beheine

Hoewol't do dit miskien net beseffe, is ien fan de krêftichste funksjes fan de app foar itenbestellingen dy't ik makke haw eins de mooglikheid om it oantal bestellingen te beheinen. Dat klinkt kontra-yntuïtyf, mar troch it oantal bestellingen dat pleatst wurde kin te beheinen, kinne myn klanten (de restaurants en winkeleigners dy't myn app brûke) derfoar soargje dat bestellingen goed taret en ôflevere wurde.

Kompleksiteit fan trije pizza's

Sis dat do trije pizza’s bestelle wolst. De iten-app moat dan witte:

• Wolst do se ôfhelje of bringe litte?
• Op hokker tiid? wannear moatte se de oven yn?
• Is der genôch romte foar trije pizza’s yn de oven op dat momint?
• As do kieze hast foar ôfhelje: kinne wy dy op dat momint feilich ûntfange?
• As do kieze hast foar levering: is der in leveringsjonge of -faam beskikber om dyn pizza’s by dy te bringen?
• Ja op alles? Dan betelje asjebleaft wylst wy dyn pizza’s ynplanne hâlde yn de oven en by levering of ôfhelje. Net betelle? Twadde gedachten? Dan meitsje wy alle planning "ûngedien" en wachtsje wy op immen oars dy't pizza's bestelle wol!

Trije kapasiteitsdimensjes

Benammen om itenstiid hinne is der gefaar dat te folle minsken tagelyk iten bestelle. Hoewol't de app de ekstra drokte oan kin troch syn tige skaalbere arsjitektuer, bliuwe fysike beheiningen bestean, lykas:

• keukenkapasiteit: it oantal gerjochten dat do tagelyk klearmeitsje kinst
• ôfhelkapasiteit: it oantal minsken dat do tagelyk feilich ûntfange kinst mei it each op de COVID-19-beheiningen
• leveringskapasiteit: it oantal bestellingen dat do leverje kinst, rekken hâldend mei ferkear, ôfstân en rûte

Ûnderskieden mar ûnderling ôfhinklik

Dizze trije ferskillende soarten beheiningen binne ûnderling ôfhinklik. It is bygelyks mooglik dat ien grutte ôfhelbestelling alle keukenkapasiteit ynnimt, wat ek ta net-beskikberens foar levering liedt. Lytsere bestellingen koene noch akseptearre wurde om keukenkapasiteit te foljen, wylst der miskien gjin kapasiteit mear is foar grutte bestellingen. Dat betsjut dat do in meganisme nedich hast dat nei alle metriken tegearre sjocht om de beskikberens foar nije bestellingen te bepalen, ynklusyf de ynhâld fan in noch net pleatste bestelling (bygelyks wat yn dyn winkelwein sit).

Ferskillen yn tiidspanne-granulariteit

It is gewoan om in fysike beheining te definiearjen mei in tiidspanne, bygelyks "de keuken kin 10 gerjochten per 15 minuten produsearje". It wurdt útdaagjend as do oare fysike beheiningen definiearrest mei oare tiidspannelingten. Wylst de keuken beheind wurde kin per 15 minuten, kin de leveringskapasiteit in langere tiidspanne brûke (bygelyks 3 leveringen per 30 minuten). It meganisme moat op ien of oare manier mei dizze ferskillen yn tiidspanne-granulariteit omgean kinne.

Yn it foar bestelle

Wat it noch útdaagjender makket is de opsje foar minsken om harren bestellingen yn it foar te pleatsen. Minsken kinne in tiidslot yn de takomst kieze en de ferplichte kapasiteit reservearje litte. Soms sjoch ik minsken har bestelling dagen yn it foar pleatse om wis te wêzen dat se har iten op in bepaalde dei en tiid krije. Dat betsjut dat der (op syn minst) twa tiden by elke bestelling hearre: bestelmomint en leveringsmomint.

Kapasiteit reservearje en frijjaan

De measte bedriuwseigners fereaskje online betellingen foar online bestellingen, om wis te wêzen dat alle bestellingen echt binne en dat der gjin kapasiteit (of iten) fergriemd wurdt oan no-shows of spoekbestellingen. It probleem mei online betellingen is dat net alle transaksjes slagje. Soms wurdt in kredyt- of debitbetelling wegere (bygelyks troch te min saldo). Soms slute minsken de app gewoan foardat se de bestelling ôfmeitsje. It systeem moat de ferplichte kapasiteit foar in bestelling reservearje wylst it minsken de online betelling dwaan lit, en it moat de reservearre kapasiteit frijjaan as de bestelling ferlitten wurdt of de betelling mislearret.

Heech folume, heech tempo

Lêst mar net it minst moat it meganisme betrouber en fluch wêze. De beskikberens fan bestellingen moat binnen in pear millisekonden bepaald wurde, wylst der swiere parallelle belêsting is, want der binne yn de spits in protte ferskillende brûkers ferbûn mei de app. As immen in bestelling pleatst, beynfloedet dat de beskikberens foar alle oare (mooglike) bestellingen. Net elkenien is betrouber ferbûn, want guon minsken brûke de app op tillefoans mei min ûntfangst of wifi. It systeem moat goed wurkje ûnder wikseljende omstannichheden mei in protte ferskillende ferbûne minsken.

Lambda Architecture

De Lambda Architecture is ien manier om grutte hoemannichten gegevens te ferwurkjen troch sawol streamferwurking as batchferwurking te brûken. In lambda-arsjitektuer is ôfhinklik fan in gegevensmodel mei in allinnich-tafoegje, ûnferoarlike gegevensboarne, faak bestean út tiidstimpele barrens.

Ûnferoarlike gegevens

Dit is in tige wichtige basis foar it meganisme: alle gegevens binne tiidstimpele en feroarje nea. Yn stee fan besteande records te feroarjen, wurde nije records gewoan tafoege om de besteande te oerskriuwen. Dat makket hege parallelle ferwurking en ferdielde algoritmen mooglik, want syngronisaasje wurdt ienfâldiger omdat do allinnich nei nije gegevens sykje hoechst (yn stee fan nije en bywurke!).

Realtime / fluggenslaach

De streamferwurking, of realtime-/fluggenslaach, yn in lambda-arsjitektuer is ûntworpen om supersnelle antwurden te jaan op realtime gegevensbehoeften. It ûnderhâldt werjeften en metriken basearre op realtime ferwurking fan barrens.

Foarberekkeningslaach

De batchferwurking, of foarberekkeningslaach, jout in folsleine en krekte basis fan alle gegevens yn it systeem. Om't it ferwurkjen fan grutte hoemannichten gegevens tiid kostje kin, is de batchferwurking net fluch genôch om alles daliks te dwaan. Dêrom wurkje de twa lagen yn in lambda-arsjitektuer gear.

Ymplemintaasje

De backendservers dy't itenbestellingen fan de app ôfhannelje, wurkje mei in gegevensstream fan tiidstimpele barrens. Yn essinsje: elke bestelling is in barren yn it systeem. Elke bestelling wurdt opslein mei syn bestel-datum/tiid, ferstjoer-datum/tiid (plande levering of ôfhelltiid), klantgegevens en bestelynhâld (oantal gerjochten, ensfh.).

Kapasiteit reservearje en frijjaan

As de betelling mislearret of in bestelling ferlitten wurdt, wurdt der in "negative" bestelling tafoege oan de gegevensstream. Dy neutralisearret elk effekt op kapasiteitsbeheiningen troch syn negative metriken. Bygelyks: om in bestelling fan trije pizza’s te annulearjen, wurdt der in negative bestelling fan "min trije pizza’s" yn de gegevensstream makke mei deselde ferstjoer-tiidstimpel. Dit is in elegante manier om wis te wêzen dat kapasiteit sawol reservearre as frijjûn wurdt.

Multidimensjonale realtime metriken

Yn stee fan kapasiteit yn tellers te abstrahearjen, brûkt de backendserver de echte streamgegevens om fragen nei realtime metriken te beäntwurdzjen. Dat makket it systeem by steat om te gean mei ferskillen yn tiidspanne-granulariteit.

De earste kear dat der in fraach foar in bepaalde metryk ynkomt, laadt it systeem histoaryske gegevens fia in batchmeganisme om it model te inisjalisearjen dat it dan realtime bywurke hâlde kin. Dizze metryk wurdt bywurke hâlden troch nei alle nije bestellingen te sjen dy't yn it systeem komme, salang as der fragen foar in bepaalde metryk binne. Sadree't de gegevens net mear opfrege wurde, wurdt it model útlaad. As it wer nedich is, werhellet it proses him.

It geweldige oan dizze oanpak is dat de measte fragen binnen in pear millisekonden beäntwurde wurde, want se wurde direkt út RAM-ûnthâld lêzen sûnder databank- of skiifynteraksje. Dat makket ultrahege prestaasje mooglik op in "need to have"-basis. Dat wurket goed by de app foar itenbestellingen, want net alle tiidspannes binne like populêr.

De app foar itenbestellingen freget werhelle kearen in sintrale kapasiteitsserver dy't de wachtrigemetriken bywurket. Dy filteret dan de beskikbere tiidslots út troch te sjen nei de echte dingen dy't in persoan foar syn of har bestelling kiest. It kiezen fan in (wierskynlik) beskikber tiidslot bart dêrom oan de kant fan de brûker, wat de belêsting op de backend ferleget. Sadree't der in bestelling pleatst wurdt, reservearret de backend de kapasiteit troch de sintrale wachtrigemetriken by te wurkjen, sadat oare minsken net itselde plak yn de wachtrige claime kinne.

Konklúzje

Wachtrigemeganismen kinne útdaagjend wêze as do mei meardere metriken te meitsjen hast dy't de fluggens bepale. Do moatst echt de tiid nimme om it goed te modellearjen, tink oan de soarte gegevens dy’t do echt nedich hast om wachtrige-relatearre kontrôles út te fieren.

No witst do dat it bestellen fan trije pizza’s net sa ienfâldich is! Garandearje dat se waarm en op tiid betsjinne wurde kinne is in grutte technyske útdaging - neist in goede kok wêze. Gelokkich foar dy dat ik my net op dat lêste rjochtsje, ha!