Jeg ser ved jobannoncer, at ansøgeren skal have erfaring med at skrive “skalerbare” applikationer. Hvad gør en applikation skalerbar, og hvordan ved jeg, at min kode kan skaleres til millioner af brugere?
Jeg antager, at en bedre måde at formulere dette spørgsmål på er: Hvordan kan jeg skrive min kode med skalerbarhed i tankerne? Så at koden kan skaleres fra starten, i modsætning til en eftertanke. Er der visse designmetoder? Eller er det simpelthen et spørgsmål om at vælge de rigtige algoritmer til jobbet?
Svar
Der er to retninger til skalerbarhed:
- lodret (aka skalering op): hurtigere CPU, mere RAM, mere diskplads;
- vandret (aka skalering ud): flere kerner i CPU, flere CPUer, flere servere ;
For det første skal du bare passe på, at du ikke har nogen vilkårlige begrænsninger. Disse enten på grund af for små heltalstørrelser eller strukturer med fast / begrænset længde. Disse strukturer kan være relateret til underliggende operativsystem. For eksempel hvis du prøver at skalere op ved hjælp af flere tråde eller processer, vil du på et tidspunkt nå OSs grænser. Derfor er det i øjeblikket servere, der bygger til høj skalerbarhed, udfører samtidighed baseret på asynkrone begivenheder. Dette problem er beskrevet i berømte C10K dokument .
Den anden er sværere. Det kræver programmering med to ting i tankerne: data behandles parallelt, og data kan være fysisk distribueret. Kommunikationen mellem noderne skal være begrænset. I praksis betyder det normalt at ofre nogle dele af ACID (det er bevist, at du ikke kan have fuld ACID og evne til at skalere ud på samme tid). Den mest kendte løsning til data lagring i dette paradigme er NoSQL -løsninger. De spænder fra meget enkle nøgleværdilagre til RDBMS-lignende systemer, kun frataget evnen til at gøre sammenføjninger. div id = “73fab16cf2”>
nøgleværdilagre er ultra-skalerbare, men det kommer som en pris. Du kan stort set kun spørge på den primære nøgle. Der er dog en løsning til at det “s kort reducerer . Det kan virke meget suboptimalt, hvis du ser på kumulativt kompleksitetsperspektiv, men du skal huske på, at det kører massivt parallelt.
Hvis du vil læse mere om skalerbarhed med eksempler fra det virkelige liv , tjek HighScalability.com blog .
Kommentarer
- +1 for at nævne skalering. Tilføjelse af flere ressourcer er meget hurtig og attraktiv for beslutningstagere (køb nogle hex-kerner og fordoblet hukommelsen! Men hvis applikationen ikke kan ‘ ikke lægge pres på dem, har du et større problem.
Svar
Skalerbarhed måles i form af kapacitet baseret på en variabel. F.eks. antal anmodninger / sekund med X brugere. Den enkleste måde at beskrive skalerbarhed på er:
Et mål for effektivitet når belastningen stiger.
Den første ting, du skal forstå i designet til skalerbarhed, er hvilken måling der er vigtigst for din applikation? Der er flere måder at måle effektivitet som er en nøglekomponent i skalerbarhed:
- Samtidige anmodninger pr. Sekund
- Gennemsnitlig responstid pr. Anmodning
- Antal behandlede poster pr. sekund / minut
Der er flere effektivitetsmålinger, der kan bruges, men disse er almindelige for webbaserede systemer eller batchbehandlingssystemer.
Det næste aspekt af skalerbarhed er at måle, hvad der sker med din effektivitet, når belastningen øges. Almindelige måder, hvorpå belastning kan øges, er:
- Flere brugere rammer serveren (dvs. mere webtrafik)
- Flere data i databasen (dvs. forespørgsler tager længere tid, eller behandling tager længere)
- Harddiskfejl i en RAID (lagringsydelse / pålidelighed påvirkes)
- Netværksmætning
Målet for en skalerbar applikation er til enten at opretholde eller forbedre effektiviteten, når vi håndterer belastningsproblemet. Kort sagt, hvis svartiden tager for lang tid, kan vi tilføje en anden server for at fordele belastningen jævnt? Denne fremgangsmåde reducerer mængden af arbejde, som en server skal udføre, og holder serverne i den “søde plet” for effektivitet.
Din applikation skal designes specifikt til skalering. Det betyder, at du skal være forsigtige med sessionsdata, dirigere anmodninger til den rigtige server, reducere flaskehalse, der begrænser applikationens evne til at skalere.
Svar
Du vil dybest set undgå præstationsflaskehalse, når du øger antallet af brugere og / eller behandler et større datasæt , og / eller tilbyde din grænseflade på flere sprog osv.
Du ser grundlæggende på dit databaseskema, dine algoritmer og din softwareudviklingsproces og forsøger at forudsige fremtidige problemer. Du vil også konfigurere overvågning af ydeevne for at identificere problemer, når de begynder at opbygge.
Jeg hentede disse tip, når jeg læste Opbygning af skalerbare websteder (link til amazon).
Håber det hjælper!
Svar
Den eneste måde, applikationer på kan være virkelig skalerbar, er ved ikke at have nogen begrænsninger, der ikke kan overføres (eller kun meget dyre).
Et typisk eksempel er, hvad der sker, når du løber tør for tilgængelige CPU-cyklusser? Hvis dit program er multi-treaded, kan du køre på en kasse med flere kerner, men hvad sker der, når du ikke længere kan købe en større kasse? Din applikation kan simpelthen ikke vokse længere, og er derfor ikke skalerbar.
Enhver virkelig skalerbar applikation skal kunne sprede sig over flere computere på en gennemsigtig måde og gøre det uden mærkbare bump. DET er ikke let, og det er en af grundene til, at Google har haft så stor succes.
Svar
Der er unikke problemer der kommer med understøttelse af store skalerede applikationer. Jobannoncen søger ansøgere, der har arbejdet i dette miljø og har måttet løse sådanne problemer.
Fra et højt niveau gøres applikationer skalerbare ved konstant at stille spørgsmålet, hvad der ville ske, hvis dette stykke kode blev anmodet om at blive kørt tusinder af gange i en meget lille periode. Dette betyder at administrere dine hukommelsesfodspor , ved hjælp af caching af totaler og data, ved hjælp af datakilder, der selv er skalerbare osv.
Svar
Hvis du var opbygning af en søgefunktion, der klarede sig godt, når den har 100 rækker i DBen til at søge og 10 brugere, der bruger den ad gangen. Hvor godt ville det fungere, når 100 brugere brugte den på samme tid, og der er 100K rækker til at slå op.
Hvis det udfører det samme uanset hvad, så er det meget godt. det hvis det udfører proportionalt med mængden af brugere / data (hvilket betyder 10 gange flere data == 10 gange længere at behandle) det er godt. Hvis det udfører meget sænk jo flere data den har (10x mode data == 10x ^ 10 længere at behandle) så skaleres den ikke godt.
Mine eksempler skal virkelig vises i Big O notation men jeg cu kender det ikke godt nok til at skrive eksemplerne ud i Big O.
Du kan simulere flere data ved at dumpe dummy-data til din DB, og der er værktøjer til at simulere flere brugere som Apache AB.