Rezumat: Înțelegerea BIO și NIO
Recent, probabil că m-am uitat la codul sursă al ZooKeeper și Mina și am descoperit că ambele sunt implementate în Java NIO, deci este necesar să înțeleg ce este NIO. Următorul este un rezumat al meu, bazat pe informații online; pentru a economisi timp, am desenat diagrama casual, atâta timp cât reușesc să înțeleg sensul.
Introducere:
BIO: Blocarea sincronă a IO-ului, modul de implementare al serverului este să conecteze un fir de execuție pe rând, adică atunci când clientul are o cerere de conexiune, serverul trebuie să pornească un fir pentru procesare, iar dacă această conexiune nu face nimic, va cauza o suprasolicitare inutilă a firului, desigur, poate fi îmbunătățită prin mecanismul pool-ului de fire.
NIO: IO-ul sincron neblocant, modul de implementare al serverului este o cerere per thread, adică cererea de conexiune trimisă de client va fi înregistrată pe multiplexor, iar multiplexorul va porni un fir pentru procesare atunci când conexiunea are o cerere I/O.
AIO (NIO.2): IO-uri asincrone și neblocante, modul de implementare al serverului este de a solicita efectiv un fir de execuție, iar cererile de I/O ale clientului sunt completate mai întâi de sistemul de operare, apoi notifică aplicația server să pornească firul pentru procesare.
BIO
Blocarea sincronă a IO-ului, cred că toți cei care au învățat programarea rețelelor sistemului de operare sau orice limbaj sunt familiarizați, în bucla while serverul va chema metoda accept pentru a aștepta cererea de conexiune a clientului receptor, odată ce cererea de conexiune este primită, se poate stabili un soclu de comunicații pe acest soclu pentru operațiuni de citire și scriere, iar în acest moment nu mai poate primi alte cereri de conexiune client, poate doar aștepta execuția operațiunii cu clientul conectat în prezent.
Dacă BIO dorește să poată procesa mai multe cereri client simultan, trebuie să folosească multi-threading, adică de fiecare dată când accept blocuri să aștepte o cerere client, odată ce o cerere de conexiune este primită, se stabilește un socket de comunicații și se deschide un nou fir pentru a procesa cererea de citire și scriere a datelor a acestui socket, apoi să continue imediat să accepte și să aștepte alte cereri de conexiune client, adică se creează un fir pentru fiecare cerere de conexiune client care să fie procesată individual, schema fiind probabil următoarea:
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/8107c3f773ad4d2aa1a5a476e650ef84/094528_zqyy.jpeg
Deși serverul are o concurență ridicată în acest moment, adică poate gestiona mai multe cereri ale clienților simultan, acest lucru aduce o problemă: pe măsură ce numărul de fire deschise crește, va consuma prea multe resurse de memorie, ceea ce va încetini sau chiar bloca serverul, iar NIO poate rezolva această problemă într-o anumită măsură.
NIO
Cheia pentru o IO sincronă și neblocantă este adoptarea unei idei bazate pe evenimente pentru a implementa un multiplexor.
Cea mai mare diferență între NIO și BIO este că trebuie doar să deschizi un fir de discuție pentru a gestiona evenimentele IO de la mai mulți clienți.
Este un multiplexor care poate asculta evenimente IO de la mai mulți clienți:
A. Dacă serverul ascultă cererea de conexiune a clientului, va stabili un socket de comunicație pentru aceasta (canal în Java), apoi va reveni pentru a continua asculta.
B. Dacă serverul ascultă datele trimise de clientul care a creat un socket de comunicații, va apela interfața corespunzătoare pentru a procesa datele primite, iar dacă există mai mulți clienți simultan, datele pot fi procesate la rândul lor.
C. Ascultă cererile de conexiune ale mai multor clienți și primește cereri de date, precum și când ai date de trimis.
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/41709898aa0a4f8a830d7c348ed05fbb/094528_of9c.jpeg
Pe scurt, într-un fir de discuție, poți chema interfața de multiplexare (select în Java) pentru a bloca și asculta cererile IO de la mai mulți clienți simultan, iar odată ce o cerere IO este primită, funcția corespunzătoare va fi apelată pentru a o procesa.
Scenarii de aplicație respective
Până în acest moment, probabil ai observat că, odată ce o cerere sosește (fie că sunt mai multe simultan sau doar una), funcția corespunzătoare de procesare IO va fi chemată să o gestioneze, deci:
(1) NIO este potrivit pentru a gestiona scenarii cu un număr mare de conexiuni, dar conexiunile sunt relativ scurte (operațiuni ușoare), cum ar fi Jetty, Mina, ZooKeeper etc., toate implementate pe baza java nio.
(2) Metoda BIO este potrivită pentru scenarii în care numărul de conexiuni este relativ mic și fix, ceea ce necesită resurse mari de server și este limitat la aplicații.
|
Postat pe 17.05.2019 15:34:50
|
|
|
Învață să înveți