așa că haideți să facem față, există două tipuri de sarcini:
- CPU obligatoriu - diverse algoritmi, matematică, codare / decodare / criptare. spune tot ceea ce încarcă procesorul.
- I / O legat - de fapt, atunci când avem o mulțime de operațiuni cu I / O, undeva 90% din sarcinile legate de dezvoltarea de WEB-uri și de servere.
Pentru CPU, merită să folosiți limbi precum C, Rust, Dlang, Go, etc. Într-un cuvânt, limbile care sunt compilate în cod mașină eficient.
Pentru I / O legat - Go, NodeJS, Erlang, Java. Da, în principiu, nu contează care limbă, principala este că apelurile deblocate sunt folosite și nu există blocări.
Totuși există cozi de sarcini, scalare orizontală etc. Arhitectura și algoritmii utilizați în sistem afectează adesea mult mai mult decât limbile de programare.
Ce limbi sunt mai bine folosite pentru asta? Care dintre ele nu ar trebui utilizate?
Nici o restricție, doar bunul simț. Adică, este puțin probabil să scriem matematică complexă la node.js, dar sarcinile asociate cu aceasta sunt mult mai puțin. De asemenea, nimeni nu vorbește despre faptul că sistemul ar trebui să fie scris strict într-o singură limbă. Acum, este la modă utilizarea micro-serviciilor, fiecare dintre acestea putând fi implementată în propria sa limbă și în baza sa de date, ideală pentru o anumită sarcină.
Nu uitați de algoritmi. Ei, de asemenea, ar trebui să fie optim. De exemplu, luați o sarcină simplă - gruparea etichetelor pe hartă. Imaginați-vă că aveți un milion de obiecte în baza de date, pe care trebuie să le afișăm pe hartă. Pentru că a face acest lucru pe client va fi problematică - trebuie să facem acest lucru pe server și să returnăm exact acele date de care are nevoie clientului.
Și pe astfel de volume, chiar dacă am luat C, dacă algoritmul nostru are complexitate O (N ^ 2) atunci nu este nimic de făcut. Și așa va fi atât de încet. Dar dacă luăm algoritmi care au complexitatea O (NLogN) atunci este posibil ca acest algoritm să poată fi aplicat cel puțin la php / python / ruby. Deci, de exemplu, am implementat acest algoritm în Java și nu în cel mai eficient mod. COPES.
Încă afectat de viteza de dezvoltare (orice rubin / Python / nod în acest sens sunt bune), costurile de asistență (C menține mult mai scumpe decât Du-te, de exemplu, deși este întotdeauna posibil să se scrie atât de rău că este mai ușor să se mențină decât să arunce), costurile de dezvoltare. Să spunem că pentru a găsi dezvoltatori ieftini puternici pe Go sau Rust va fi foarte problematică.
Doar nu uitați că serverul nu este atât de scump acum. Uneori este mai ușor pentru companii să plătească pentru o duzină de mai multe servere decât să scrie totul despre plusuri.
De fapt, regula principală a sistemelor cu încărcătură ridicată este testarea încărcării și apoi optimizarea
> Serializarea binară nu va genera o plată decât dacă este un format de date nativ în memoria V8 sau alt motor.
Bănuiesc că ceva nu este mai mic decât cel obișnuit de analiză JSON. Dar avem nevoie de repere. În general, ideea este interesantă și o voi încerca cumva.
Articole similare
Trimiteți-le prietenilor: