Kokkuvõte: BIO ja NIO mõistmine
Hiljuti vaatasin ilmselt ZooKeeperi ja Mina lähtekoodi ning leidsin, et mõlemad on Java NIO keeles implementeeritud, seega on vaja välja selgitada, mis NIO on. Järgnev on minu enda kokkuvõte, mis põhineb veebipõhisel teabel; aja säästmiseks joonistasin diagrammi juhuslikult, kui suudan tähenduse saavutada.
Sissejuhatus:
BIO: Sünkroonse blokeerimise IO, serveri rakendusrežiim on ühendada üks lõim korraga, st kui kliendil on ühendustaotlus, peab server käivitama lõime töötlemiseks, kui see ühendus midagi ei tee, põhjustab see tarbetut lõimekoormust, muidugi saab seda parandada lõimepooli mehhanismi abil.
NIO: Sünkroonne mitteblokeeriv IO, serveri rakendusrežiim on üks päring iga lõime kohta, st kliendi saadetud ühenduspäring registreeritakse multiplekseris ning multiplexer alustab lõime töötlemiseks, kui ühendusel on I/O päring.
AIO (NIO.2): Asünkroonne mitteblokeeriv IO, serveri rakendusrežiim on sisuliselt ühe lõime taotlemine ning kliendi I/O päringud täidab OS esmalt ja seejärel teavitab serverirakendust, et lõime töötlemiseks alustada.
BIO
Sünkroonse blokeerimise IO, usun, et kõik, kes on õppinud operatsioonisüsteemi võrguprogrammeerimist või mõne muu keele võrguprogrammeerimist, on tuttav, while-tsüklis kutsub server aktsepteerimise meetodi, et oodata vastuvõtva kliendi ühendustaotlust; kui ühenduspäring on vastu võetud, saab sellel sidepesasil luua sidepesa lugemis- ja kirjutamistoimingute jaoks, sel hetkel ei saa ta enam vastu võtta teisi kliendi ühendustaotlusi, vaid oodata operatsiooni täitmist hetkel ühendatud kliendiga.
Kui BIO soovib korraga töödelda mitut kliendipäringut, peab ta kasutama mitmelõimelist lahendust, st iga kord, kui aktsepteerimisplokid ootavad kliendi päringut, kui ühenduspäring on vastu võetud, luuakse sidepesa ja avatakse uus lõim, et töödelda selle sokli andmete lugemis- ja kirjutamistaotlusi, ning seejärel jätkata kohe teiste kliendiühenduse päringute aktsepteerimist ja ootamist, st iga kliendiühenduse päringu jaoks luuakse lõim, mida tuleb individuaalselt töödelda, skeem on tõenäoliselt selline:
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/8107c3f773ad4d2aa1a5a476e650ef84/094528_zqyy.jpeg
Kuigi serveril on praegu kõrge samaaegsus, st ta suudab korraga hallata mitut kliendipäringut, tekitab see probleemi – avatud lõimede arvu suurenedes kulutab see liiga palju mäluressursse, põhjustades serveri aeglustumist või isegi kokkujooksmist, ning NIO suudab seda probleemi teatud määral lahendada.
NIO
Sünkroonse mitteblokeeriva IO võti on sündmuspõhise idee kasutuselevõtt multiplekseri rakendamiseks.
Suurim erinevus NIO ja BIO vahel on see, et IO sündmuste haldamiseks mitme kliendi jaoks piisab lõime avamisest.
See on multiplexer, mis suudab kuulata IO sündmusi mitmelt kliendilt:
V. Kui server kuulab kliendi ühenduse päringut, loob ta selle jaoks sidepesa (Java kanal) ja jätkab kuulamist.
B. Kui server kuulab kliendilt, kes on loonud sidepesa, saadetud andmeid, kutsub ta vastava liidese vastuvõetud andmete töötlemiseks ning kui korraga on mitu klienti, saab andmeid ka omakorda töödelda.
C. Kuula mitme kliendi ühendustaotlusi ja võta vastu andmepäringuid ning kuula, millal sul on andmeid saata.
C:/Users/kevin/AppData/Local/YNote/data/kevinsir2003@163.com/41709898aa0a4f8a830d7c348ed05fbb/094528_of9c.jpeg
Lühidalt, ühes lõimes saad kutsuda multipleksimise liidest (select javas), et blokeerida ja kuulata IO-päringuid mitmelt kliendilt samaaegselt, ning kui IO päring on vastu võetud, kutsutakse vastav funktsioon selle töötlemiseks.
Vastavad rakendusstsenaariumid
Selleks ajaks oled ilmselt märganud, et kui päring saabub (olgu see siis mitu korraga või ainult üks), kutsutakse vastav IO töötlemisfunktsioon selle haldamiseks, seega:
(1) NIO sobib olukordade käsitlemiseks, kus on palju ühendusi, kuid ühendused on suhteliselt lühikesed (kerge tööga), nagu Jetty, Mina, ZooKeeper jne, mis kõik on rakendatud java nio baasil.
(2) BIO meetod sobib olukordadeks, kus ühenduste arv on suhteliselt väike ja fikseeritud, mis nõuab suuri serveriressursse ja piirdub rakendustega.
|
Postitatud 17.05.2019 15:34:50
|
|
|
Õpi õppima