Awgrymaf eich bod yn darllen trawsgrifiad y ddarlith "Hadoop. ZooKeeper" o'r gyfres "Dulliau ar gyfer prosesu dosbarthedig o symiau mawr o ddata yn Hadoop"
Beth yw ZooKeeper, ei le yn ecosystem Hadoop. Anwireddau am gyfrifiadura dosranedig. Diagram o system ddosbarthedig safonol. Anhawster wrth gydlynu systemau gwasgaredig. Problemau cydsymud nodweddiadol. Yr egwyddorion y tu ôl i ddyluniad ZooKeeper. Model data ZooKeeper. baneri znode. Sesiynau. API Cleient. Cyntefig (cyfluniad, aelodaeth grŵp, cloeon syml, ethol arweinydd, cloi heb effaith buches). Pensaernïaeth ZooKeeper. ZooCeidwad DB. ZAB. Triniwr cais.
Heddiw byddwn yn siarad am ZooKeeper. Mae'r peth hwn yn ddefnyddiol iawn. Mae ganddo, fel unrhyw gynnyrch Apache Hadoop, logo. Mae'n darlunio dyn.
Cyn hyn, buom yn siarad yn bennaf am sut y gellir prosesu data yno, sut i'w storio, hynny yw, sut i'w ddefnyddio rywsut a gweithio gydag ef rywsut. A heddiw hoffwn siarad ychydig am geisiadau a ddosbarthwyd gan adeiladau. Ac mae ZooKeeper yn un o'r pethau hynny sy'n eich galluogi i symleiddio'r mater hwn. Mae hwn yn fath o wasanaeth sydd wedi'i fwriadu ar gyfer rhyw fath o gydlynu rhyngweithio prosesau mewn systemau dosbarthedig, mewn cymwysiadau dosbarthedig.
Mae'r angen am geisiadau o'r fath yn dod yn fwyfwy bob dydd, dyna hanfod ein cwrs. Ar y naill law, mae MapReduce a'r fframwaith parod hwn yn caniatáu ichi lefelu'r cymhlethdod hwn a rhyddhau'r rhaglennydd rhag ysgrifennu cyntefigau fel rhyngweithio a chydlynu prosesau. Ond ar y llaw arall, nid oes neb yn gwarantu na fydd yn rhaid gwneud hyn beth bynnag. Nid yw MapReduce neu fframweithiau parod eraill bob amser yn disodli'n llwyr rai achosion na ellir eu gweithredu gan ddefnyddio hyn. Gan gynnwys MapReduce ei hun a chriw o brosiectau Apache eraill; maent, mewn gwirionedd, hefyd yn gymwysiadau dosranedig. Ac i wneud ysgrifennu'n haws, fe wnaethon nhw ysgrifennu ZooKeeper.
Fel pob rhaglen sy'n gysylltiedig â Hadoop, fe'i datblygwyd gan Yahoo! Mae bellach hefyd yn gais Apache swyddogol. Nid yw wedi'i ddatblygu mor weithredol â HBase. Os ewch chi i JIRA HBase, yna bob dydd mae yna griw o adroddiadau am fygiau, criw o gynigion i wneud y gorau o rywbeth, hy mae bywyd yn y prosiect yn mynd rhagddo'n barhaus. Ac mae ZooKeeper, ar y naill law, yn gynnyrch cymharol syml, ac ar y llaw arall, mae hyn yn sicrhau ei ddibynadwyedd. Ac mae'n eithaf hawdd ei ddefnyddio, a dyna pam ei fod wedi dod yn safon mewn cymwysiadau o fewn ecosystem Hadoop. Felly roeddwn i'n meddwl y byddai'n ddefnyddiol ei adolygu i ddeall sut mae'n gweithio a sut i'w ddefnyddio.
Dyma lun o ryw ddarlith a gawsom. Gallwn ddweud ei fod yn orthogonal i bopeth yr ydym wedi’i ystyried hyd yn hyn. Ac mae popeth a nodir yma, i raddau neu'i gilydd, yn gweithio gyda ZooKeeper, h.y., mae'n wasanaeth sy'n defnyddio'r holl gynhyrchion hyn. Nid yw HDFS na MapReduce yn ysgrifennu eu gwasanaethau tebyg eu hunain a fyddai'n gweithio'n benodol iddyn nhw. Yn unol â hynny, defnyddir ZooKeeper. Ac mae hyn yn symleiddio datblygiad a rhai pethau sy'n ymwneud â gwallau.
O ble mae hyn i gyd yn dod? Mae'n ymddangos ein bod wedi lansio dau gais yn gyfochrog ar wahanol gyfrifiaduron, yn eu cysylltu â llinyn neu mewn rhwyll, ac mae popeth yn gweithio. Ond y broblem yw bod y Rhwydwaith yn annibynadwy, ac os gwnaethoch chi arogli'r traffig neu edrych ar yr hyn sy'n digwydd yno ar lefel isel, sut mae cleientiaid yn rhyngweithio ar y Rhwydwaith, gallwch chi weld yn aml bod rhai pecynnau'n cael eu colli neu eu hail-anfon. Nid am ddim y ddyfeisiwyd protocolau TCP, sy'n eich galluogi i sefydlu sesiwn benodol a gwarantu y caiff negeseuon eu dosbarthu. Ond beth bynnag, ni all hyd yn oed TCP eich arbed bob amser. Mae gan bopeth seibiant. Efallai y bydd y rhwydwaith yn disgyn i ffwrdd am ychydig. Efallai ei fod yn blink. Ac mae hyn i gyd yn arwain at y ffaith na allwch ddibynnu ar y Rhwydwaith fod yn ddibynadwy. Dyma'r prif wahaniaeth o ysgrifennu cymwysiadau cyfochrog sy'n rhedeg ar un cyfrifiadur neu ar un uwchgyfrifiadur, lle nad oes Rhwydwaith, lle mae bws cyfnewid data mwy dibynadwy yn y cof. Ac mae hwn yn wahaniaeth sylfaenol.
Ymhlith pethau eraill, wrth ddefnyddio'r Rhwydwaith, mae rhywfaint o hwyrni bob amser. Mae gan y ddisg hefyd, ond mae gan y Rhwydwaith fwy ohono. Mae hwyrni yn beth amser oedi, a all fod naill ai'n fach neu'n eithaf sylweddol.
Mae topoleg y rhwydwaith yn newid. Beth yw topoleg - dyma leoliad ein hoffer rhwydwaith. Mae yna ganolfannau data, mae yna raciau sy'n sefyll yno, mae canhwyllau. Gellir ailgysylltu hyn i gyd, ei symud, ac ati. Mae angen cymryd hyn i gyd i ystyriaeth hefyd. Mae enwau IP yn newid, ac mae'r llwybr y mae ein traffig yn teithio drwyddo yn newid. Mae angen cymryd hyn i ystyriaeth hefyd.
Gall y rhwydwaith hefyd newid o ran offer. O ymarfer, gallaf ddweud bod ein peirianwyr rhwydwaith yn hoff iawn o ddiweddaru rhywbeth am y canhwyllau o bryd i'w gilydd. Yn sydyn daeth firmware newydd allan ac nid oedd ganddynt ddiddordeb arbennig mewn rhai clwstwr Hadoop. Mae ganddyn nhw eu swydd eu hunain. Ar eu cyfer, y prif beth yw bod y Rhwydwaith yn gweithio. Yn unol â hynny, maent am ail-lwytho rhywbeth yno, gwneud fflachio ar eu caledwedd, ac mae'r caledwedd hefyd yn newid o bryd i'w gilydd. Mae angen ystyried hyn i gyd rywsut. Mae hyn i gyd yn effeithio ar ein cais a ddosbarthwyd.
Fel arfer mae pobl sy'n dechrau gweithio gyda llawer iawn o ddata am ryw reswm yn credu bod y Rhyngrwyd yn ddiderfyn. Os oes ffeil o sawl terabytes yno, yna gallwch fynd ag ef i'ch gweinydd neu'ch cyfrifiadur a'i agor gan ddefnyddio cat a gwylio. Mae gwall arall i mewn Vim edrych ar y logiau. Peidiwch byth â gwneud hyn oherwydd ei fod yn ddrwg. Oherwydd bod Vim yn ceisio clustogi popeth, llwytho popeth i'r cof, yn enwedig pan fyddwn yn dechrau symud trwy'r log hwn a chwilio am rywbeth. Mae'r rhain yn bethau sy'n cael eu hanghofio, ond sy'n werth eu hystyried.
Mae'n haws ysgrifennu un rhaglen sy'n rhedeg ar un cyfrifiadur gydag un prosesydd.
Pan fydd ein system yn tyfu, rydym am gyfochri'r cyfan, a'i gyfochrog nid yn unig ar gyfrifiadur, ond hefyd ar glwstwr. Mae'r cwestiwn yn codi: sut i gydlynu'r mater hwn? Efallai na fydd ein cymwysiadau hyd yn oed yn rhyngweithio â'i gilydd, ond fe wnaethom redeg sawl proses ochr yn ochr ar sawl gweinydd. A sut i fonitro bod popeth yn mynd yn dda iddyn nhw? Er enghraifft, maen nhw'n anfon rhywbeth dros y Rhyngrwyd. Rhaid iddynt ysgrifennu am eu cyflwr yn rhywle, er enghraifft, mewn rhyw fath o gronfa ddata neu log, yna agregu'r log hwn ac yna ei ddadansoddi yn rhywle. Hefyd, mae angen inni gymryd i ystyriaeth fod y broses yn gweithio ac yn gweithio, yn sydyn ymddangosodd rhywfaint o wall ynddo neu fe ddamwain, yna pa mor gyflym y byddwn yn dod i wybod amdano?
Mae'n amlwg y gellir monitro hyn i gyd yn gyflym. Mae hyn hefyd yn dda, ond mae monitro yn beth cyfyngedig sy'n eich galluogi i fonitro rhai pethau ar y lefel uchaf.
Pan fyddwn am i'n prosesau ddechrau rhyngweithio â'i gilydd, er enghraifft, i anfon rhywfaint o ddata at ei gilydd, yna mae'r cwestiwn hefyd yn codi - sut bydd hyn yn digwydd? A fydd rhyw fath o gyflwr hil, a fyddant yn trosysgrifo ei gilydd, a fydd y data yn cyrraedd yn gywir, a fydd unrhyw beth yn cael ei golli ar hyd y ffordd? Mae angen inni ddatblygu rhyw fath o brotocol, ac ati.
Nid yw cydlynu'r holl brosesau hyn yn beth dibwys. Ac mae'n gorfodi'r datblygwr i fynd i lawr i lefel is fyth, ac ysgrifennu systemau naill ai o'r dechrau, neu ddim yn hollol o'r dechrau, ond nid yw hyn mor syml.
Os ydych chi'n meddwl am algorithm cryptograffig neu hyd yn oed yn ei weithredu, yna ei daflu i ffwrdd ar unwaith, oherwydd yn fwyaf tebygol ni fydd yn gweithio i chi. Mae'n debygol y bydd yn cynnwys criw o wallau yr ydych wedi anghofio darparu ar eu cyfer. Peidiwch byth â'i ddefnyddio ar gyfer unrhyw beth difrifol oherwydd mae'n debygol y bydd yn ansefydlog. Oherwydd bod yr holl algorithmau sy'n bodoli wedi'u profi gan amser am amser hir iawn. Mae'n cael ei fygio gan y gymuned. Mae hwn yn bwnc ar wahân. Ac mae'r un peth yma. Os yw'n bosibl peidio â gweithredu rhyw fath o gydamseriad proses eich hun, yna mae'n well peidio â gwneud hyn, oherwydd mae'n eithaf cymhleth ac yn eich arwain i lawr y llwybr sigledig o chwilio am wallau yn gyson.
Heddiw rydym yn sôn am ZooKeeper. Ar y naill law, mae'n fframwaith, ar y llaw arall, mae'n wasanaeth sy'n gwneud bywyd yn haws i'r datblygwr ac yn symleiddio gweithrediad rhesymeg a chydlynu ein prosesau cymaint â phosibl.
Gadewch i ni gofio sut olwg fyddai ar system ddosbarthedig safonol. Dyma beth y buom yn siarad amdano - HDFS, HBase. Mae yna broses Meistr sy'n rheoli prosesau gweithwyr a chaethweision. Mae'n gyfrifol am gydlynu a dosbarthu tasgau, ailgychwyn gweithwyr, lansio rhai newydd, a dosbarthu'r llwyth.
Peth mwy datblygedig yw'r Gwasanaeth Cydlynu, hynny yw, symudwch y dasg gydlynu ei hun i broses ar wahân, yn ogystal â rhedeg rhyw fath o Feistr wrth gefn neu wrth gefn yn gyfochrog, oherwydd efallai y bydd y Meistr yn methu. Ac os bydd y Meistr yn disgyn, yna ni fydd ein system yn gweithio. Rydym yn rhedeg copi wrth gefn. Mae rhai yn nodi bod angen ailadrodd y Meistr i wneud copi wrth gefn. Gellir ymddiried hyn hefyd i'r Gwasanaeth Cydlynu. Ond yn y diagram hwn, y Meistr ei hun sy'n gyfrifol am gydlynu'r gweithwyr; yma mae'r gwasanaeth yn cydlynu gweithgareddau atgynhyrchu data.
Opsiwn mwy datblygedig yw pan fydd ein gwasanaeth yn ymdrin â'r holl gydlynu, fel sy'n cael ei wneud fel arfer. Mae'n cymryd cyfrifoldeb am sicrhau bod popeth yn gweithio. Ac os nad yw rhywbeth yn gweithio, rydyn ni'n dod i wybod amdano ac yn ceisio mynd o gwmpas y sefyllfa hon. Mewn unrhyw achos, rydyn ni'n cael ein gadael gyda Meistr sydd rywsut yn rhyngweithio â chaethweision ac yn gallu anfon data, gwybodaeth, negeseuon, ac ati trwy rywfaint o wasanaeth.
Mae cynllun hyd yn oed yn fwy datblygedig, pan nad oes gennym Feistr, mae pob nod yn feistr-gaethweision, yn wahanol yn eu hymddygiad. Ond mae angen iddynt ryngweithio â'i gilydd o hyd, felly mae rhywfaint o wasanaeth ar ôl o hyd i gydlynu'r camau hyn. Yn ôl pob tebyg, mae Cassandra, sy'n gweithio ar yr egwyddor hon, yn cyd-fynd â'r cynllun hwn.
Mae’n anodd dweud pa un o’r cynlluniau hyn sy’n gweithio orau. Mae gan bob un ei fanteision a'i anfanteision ei hun.
Ac nid oes angen bod yn ofnus o rai pethau gyda'r Meistr, oherwydd, fel y mae arfer yn dangos, nid yw mor agored i wasanaethu yn gyson. Y prif beth yma yw dewis yr ateb cywir ar gyfer cynnal y gwasanaeth hwn ar nod pwerus ar wahân, fel bod ganddo ddigon o adnoddau, fel nad oes gan ddefnyddwyr fynediad yno, os yn bosibl, fel nad ydynt yn lladd y broses hon yn ddamweiniol. Ond ar yr un pryd, mewn cynllun o'r fath mae'n llawer haws rheoli gweithwyr o'r broses Meistr, h.y. mae'r cynllun hwn yn symlach o safbwynt gweithredu.
Ac mae'n debyg bod y cynllun hwn (uchod) yn fwy cymhleth, ond yn fwy dibynadwy.
Y brif broblem yw methiannau rhannol. Er enghraifft, pan fyddwn yn anfon neges dros y Rhwydwaith, mae rhyw fath o ddamwain yn digwydd, ac ni fydd yr un a anfonodd y neges yn gwybod a dderbyniwyd ei neges a beth ddigwyddodd ar ochr y derbynnydd, ni fydd yn gwybod a gafodd y neges ei phrosesu'n gywir. , h.y. ni fydd yn derbyn unrhyw gadarnhad.
Yn unol â hynny, rhaid inni brosesu'r sefyllfa hon. A'r peth symlaf yw ail-anfon y neges hon ac aros nes i ni dderbyn ymateb. Yn yr achos hwn, ni chymerir i ystyriaeth a yw cyflwr y derbynnydd wedi newid. Efallai y byddwn yn anfon neges ac yn ychwanegu'r un data ddwywaith.
Mae ZooKeeper yn cynnig ffyrdd o ddelio â gwrthodiadau o'r fath, sydd hefyd yn gwneud ein bywydau'n haws.
Fel y soniwyd ychydig yn gynharach, mae hyn yn debyg i ysgrifennu rhaglenni aml-edau, ond y prif wahaniaeth yw mai'r unig ffordd i gyfathrebu yw'r Rhwydwaith mewn cymwysiadau dosbarthedig yr ydym yn adeiladu ar wahanol beiriannau. Yn y bôn, pensaernïaeth a rennir yw hon. Mae gan bob proses neu wasanaeth sy'n rhedeg ar un peiriant ei gof ei hun, ei ddisg ei hun, ei brosesydd ei hun, nad yw'n ei rannu ag unrhyw un.
Os byddwn yn ysgrifennu rhaglen aml-edau ar un cyfrifiadur, yna gallwn ddefnyddio cof a rennir i gyfnewid data. Mae gennym ni switsh cyd-destun yno, gall prosesau newid. Mae hyn yn effeithio ar berfformiad. Ar y naill law, nid oes y fath beth yn y rhaglen ar glwstwr, ond mae problemau gyda’r Rhwydwaith.
Yn unol â hynny, y prif broblemau sy'n codi wrth ysgrifennu systemau gwasgaredig yw cyfluniad. Rydym yn ysgrifennu rhyw fath o gais. Os yw'n syml, yna rydym yn codio pob math o rifau yn y cod, ond mae hyn yn anghyfleus, oherwydd os ydym yn penderfynu yn lle amser allan o hanner eiliad ein bod am gael seibiant o un eiliad, yna mae angen i ni ail-grynhoi'r cais a rholio popeth allan eto. Mae'n un peth pan fydd ar un peiriant, pan allwch chi ei ailgychwyn, ond pan fydd gennym lawer o beiriannau, mae'n rhaid i ni gopïo popeth yn gyson. Rhaid inni geisio gwneud y rhaglen yn ffurfweddadwy.
Yma rydym yn sôn am gyfluniad statig ar gyfer prosesau system. Nid yw hyn yn gyfan gwbl, efallai o safbwynt y system weithredu, gall fod yn gyfluniad statig ar gyfer ein prosesau, hynny yw, mae hwn yn gyfluniad na ellir ei gymryd a'i ddiweddaru.
Mae yna hefyd gyfluniad deinamig. Dyma'r paramedrau yr ydym am eu newid ar y hedfan fel eu bod yn cael eu codi yno.
Beth yw'r broblem yma? Fe wnaethom ddiweddaru'r ffurfwedd, ei gyflwyno, felly beth? Efallai mai'r broblem yw ein bod ar y naill law wedi cyflwyno'r ffurfwedd, ond wedi anghofio am y peth newydd, arhosodd y ffurfwedd yno. Yn ail, tra roeddem yn cyflwyno, cafodd y cyfluniad ei ddiweddaru mewn rhai mannau, ond nid mewn mannau eraill. Ac ailddechreuwyd rhai prosesau o'n cymhwysiad sy'n rhedeg ar un peiriant gyda chyfluniad newydd, a rhywle gyda hen un. Gall hyn olygu bod ein cymhwysiad dosbarthedig yn anghyson o safbwynt cyfluniad. Mae'r broblem hon yn gyffredin. Ar gyfer cyfluniad deinamig, mae'n fwy perthnasol oherwydd ei fod yn awgrymu y gellir ei newid ar y hedfan.
Problem arall yw aelodaeth grŵp. Mae gennym ni bob amser set o weithwyr, rydyn ni bob amser eisiau gwybod pa un ohonyn nhw sy'n fyw, pa un ohonyn nhw sydd wedi marw. Os oes Meistr, yna mae'n rhaid iddo ddeall pa weithwyr y gellir eu hailgyfeirio i gleientiaid fel eu bod yn rhedeg cyfrifiadau neu'n gweithio gyda data, a pha rai na all. Problem sy’n codi’n gyson yw bod angen inni wybod pwy sy’n gweithio yn ein clwstwr.
Problem nodweddiadol arall yw etholiadau arweinwyr, pan fyddwn ni eisiau gwybod pwy sydd wrth y llyw. Un enghraifft yw atgynhyrchu, pan fydd gennym rywfaint o broses sy'n derbyn gweithrediadau ysgrifennu ac yna'n eu hailadrodd ymhlith prosesau eraill. Fe fydd yr arweinydd, bydd pawb arall yn ufuddhau iddo, yn ei ddilyn. Mae angen dewis proses fel ei bod yn ddiamwys i bawb, fel nad yw'n troi allan bod dau arweinydd yn cael eu dewis.
Mae mynediad hefyd yn annibynnol ar ei gilydd. Mae'r broblem yma yn fwy cymhleth. Mae yna'r fath beth â mutex, pan fyddwch chi'n ysgrifennu rhaglenni aml-edau ac eisiau mynediad i ryw adnodd, er enghraifft, cell cof, i'w gyfyngu a'i gyflawni gan un edefyn yn unig. Yma gallai'r adnodd fod yn rhywbeth mwy haniaethol. A dylai gwahanol gymwysiadau o wahanol nodau ein Rhwydwaith dderbyn mynediad unigryw i adnodd penodol yn unig, ac nid fel y gall pawb ei newid neu ysgrifennu rhywbeth yno. Dyma'r cloeon fel y'u gelwir.
Mae ZooKeeper yn caniatáu ichi ddatrys yr holl broblemau hyn i raddau. A byddaf yn dangos gydag enghreifftiau sut mae'n caniatáu ichi wneud hyn.
Nid oes unrhyw flocio cyntefig. Pan fyddwn yn dechrau defnyddio rhywbeth, ni fydd y cyntefig hwn yn aros i unrhyw ddigwyddiad ddigwydd. Yn fwyaf tebygol, bydd y peth hwn yn gweithio'n anghydamserol, a thrwy hynny ganiatáu i brosesau beidio â hongian tra'u bod yn aros am rywbeth. Mae hyn yn beth defnyddiol iawn.
Mae pob cais cleient yn cael ei brosesu yn nhrefn y ciw cyffredinol.
Ac mae cleientiaid yn cael y cyfle i dderbyn hysbysiad am newidiadau mewn rhai cyflwr, am newidiadau mewn data, cyn i'r cleient weld y data wedi'i newid eu hunain.
Gall ZooKeeper weithio mewn dau fodd. Mae'r cyntaf yn annibynnol, ar un nod. Mae hyn yn gyfleus ar gyfer profi. Gall hefyd weithredu yn y modd clwstwr ar unrhyw nifer o weinyddion. Os oes gennym glwstwr o 100 o beiriannau, yna nid oes angen iddo weithio ar 100 o beiriannau. Mae'n ddigon dewis sawl peiriant lle gallwch chi redeg ZooKeeper. Ac mae'n arddel yr egwyddor o argaeledd uchel. Ar bob achos rhedeg, mae ZooKeeper yn storio copi cyfan o'r data. Yn ddiweddarach byddaf yn dweud wrthych sut y mae'n ei wneud. Nid yw'n torri data nac yn ei rannu. Ar y naill law, mae'n minws na allwn storio llawer, ar y llaw arall, nid oes angen gwneud hyn. Nid dyna'r hyn y mae wedi'i gynllunio ar ei gyfer, nid cronfa ddata mohoni.
Gellir storio data ar ochr y cleient. Mae hon yn egwyddor safonol fel nad ydym yn torri ar draws y gwasanaeth ac nad ydym yn ei lwytho gyda'r un ceisiadau. Mae cleient smart fel arfer yn gwybod am hyn ac yn ei storio.
Er enghraifft, mae rhywbeth wedi newid yma. Mae rhyw fath o gais. Etholwyd arweinydd newydd, sy'n gyfrifol, er enghraifft, am brosesu gweithrediadau ysgrifennu. Ac rydym am ailadrodd y data. Un ateb yw ei roi mewn dolen. Ac rydym yn cwestiynu ein gwasanaeth yn gyson - a oes unrhyw beth wedi newid? Mae'r ail opsiwn yn fwy optimaidd. Mae hwn yn fecanwaith gwylio sy'n eich galluogi i hysbysu cleientiaid bod rhywbeth wedi newid. Mae hwn yn ddull llai costus o ran adnoddau ac yn fwy cyfleus i gleientiaid.
Cleient yw'r defnyddiwr sy'n defnyddio ZooKeeper.
Gweinydd yw'r broses ZooKeeper ei hun.
Znode yw'r peth allweddol yn ZooKeeper. Mae'r holl znodes yn cael eu storio yn y cof gan ZooKeeper ac yn cael eu trefnu ar ffurf diagram hierarchaidd, ar ffurf coeden.
Mae dau fath o lawdriniaeth. Y cyntaf yw diweddaru/ysgrifennu, pan fydd rhywfaint o weithrediad yn newid cyflwr ein coeden. Mae'r goeden yn gyffredin.
Ac mae'n bosibl nad yw'r cleient yn cwblhau un cais a'i fod wedi'i ddatgysylltu, ond yn gallu sefydlu sesiwn lle mae'n rhyngweithio â ZooKeeper.
Mae model data ZooKeeper yn debyg i system ffeiliau. Mae gwraidd safonol ac yna aethom fel pe bai drwy'r cyfeirlyfrau sy'n mynd o'r gwraidd. Ac yna y catalog y lefel gyntaf, ail lefel. Mae hyn i gyd yn znodes.
Gall pob znode storio rhywfaint o ddata, fel arfer nid yw'n fawr iawn, er enghraifft, 10 kilobytes. A gall pob znode gael nifer penodol o blant.
Daw Znodes mewn sawl math. Gellir eu creu. Ac wrth greu znode, rydym yn nodi'r math y dylai fod yn perthyn iddo.
Mae dau fath. Y gyntaf yw'r faner fyrhoedlog. Mae Znode yn byw o fewn sesiwn. Er enghraifft, mae'r cleient wedi sefydlu sesiwn. A chyn belled â bod y sesiwn hon yn fyw, bydd yn bodoli. Mae hyn yn angenrheidiol er mwyn peidio â chynhyrchu rhywbeth diangen. Mae hyn hefyd yn addas ar gyfer eiliadau pan mae'n bwysig i ni storio data cyntefig o fewn sesiwn.
Yr ail fath yw baner ddilyniannol. Mae'n cynyddu'r cownter ar y ffordd i'r znode. Er enghraifft, roedd gennym gyfeiriadur gyda chymhwysiad 1_5. A phan wnaethom greu'r nod cyntaf, derbyniodd p_1, yr ail - p_2. A phan fyddwn yn galw'r dull hwn bob tro, rydym yn pasio'r llwybr llawn, gan nodi rhan o'r llwybr yn unig, ac mae'r rhif hwn yn cael ei gynyddu'n awtomatig oherwydd ein bod yn nodi'r math o nod - dilyniannol.
znode rheolaidd. Bydd hi bob amser yn byw a bydd ganddi'r enw rydyn ni'n ei ddweud wrthi.
Peth defnyddiol arall yw baner yr oriawr. Os byddwn yn ei osod, yna gall y cleient danysgrifio i rai digwyddiadau ar gyfer nod penodol. Byddaf yn dangos i chi yn ddiweddarach gydag enghraifft sut y gwneir hyn. Mae ZooKeeper ei hun yn hysbysu'r cleient bod y data ar y nod wedi newid. Fodd bynnag, nid yw hysbysiadau yn gwarantu bod rhywfaint o ddata newydd wedi cyrraedd. Yn syml, maen nhw'n dweud bod rhywbeth wedi newid, felly mae'n rhaid i chi gymharu data yn ddiweddarach â galwadau ar wahân o hyd.
Ac fel y dywedais eisoes, mae trefn y data yn cael ei bennu gan kilobytes. Nid oes angen storio data testun mawr yno, oherwydd nid yw'n gronfa ddata, mae'n weinydd cydlynu gweithredu.
Dywedaf ychydig wrthych am y sesiynau. Os oes gennym weinyddion lluosog, yna gallwn symud yn dryloyw o weinydd i weinydd gan ddefnyddio'r dynodwr sesiwn. Mae'n eithaf cyfleus.
Mae rhyw fath o seibiant i bob sesiwn. Diffinnir sesiwn gan a yw'r cleient yn anfon unrhyw beth i'r gweinydd yn ystod y sesiwn honno. Os na fydd yn trosglwyddo unrhyw beth yn ystod y terfyn amser, mae'r sesiwn yn disgyn i ffwrdd, neu gall y cleient ei gau ei hun.
Nid oes ganddo gymaint o nodweddion, ond gallwch chi wneud pethau gwahanol gyda'r API hwn. Mae'r alwad honno a welsom yn creu yn creu znode ac yn cymryd tri pharamedr. Dyma'r llwybr i'r znode, a rhaid ei nodi'n llawn o'r gwraidd. A hefyd dyma rywfaint o ddata yr ydym am ei drosglwyddo yno. A'r math o faner. Ac ar ôl creu mae'n dychwelyd y llwybr i'r znode.
Yn ail, gallwch ei ddileu. Y tric yma yw y gall yr ail baramedr, yn ychwanegol at y llwybr i'r znode, nodi'r fersiwn. Yn unol â hynny, bydd y znode hwnnw'n cael ei ddileu os yw ei fersiwn a drosglwyddwyd gennym yn cyfateb i'r un sy'n bodoli mewn gwirionedd.
Os nad ydym am wirio'r fersiwn hon, yna yn syml rydym yn pasio'r ddadl "-1".
Yn drydydd, mae'n gwirio bodolaeth znode. Yn dychwelyd yn wir os yw'r nod yn bodoli, ffug fel arall.
Ac yna mae gwyliad baner yn ymddangos, sy'n eich galluogi i fonitro'r nod hwn.
Gallwch chi osod y faner hon hyd yn oed ar nod nad yw'n bodoli a derbyn hysbysiad pan fydd yn ymddangos. Gall hyn fod yn ddefnyddiol hefyd.
Mae cwpl o heriau eraill caelData. Mae'n amlwg y gallwn dderbyn data trwy znode. Gallwch hefyd ddefnyddio gwyliadwriaeth fflagiau. Yn yr achos hwn, ni fydd yn gosod os nad oes nod. Felly, mae angen i chi ddeall ei fod yn bodoli, ac yna derbyn data.
Mae yna hefyd SetData. Yma rydym yn pasio fersiwn. Ac os byddwn yn trosglwyddo hyn, bydd y data ar y znode o fersiwn benodol yn cael ei ddiweddaru.
Gallwch hefyd nodi "-1" i eithrio'r gwiriad hwn.
Dull defnyddiol arall yw caelPlant. Gallwn hefyd gael rhestr o'r holl znodes sy'n perthyn iddo. Gallwn fonitro hyn drwy osod gwyliadwriaeth fflagiau.
A dull cydamseru caniatáu i bob newid gael ei anfon ar unwaith, a thrwy hynny sicrhau eu bod yn cael eu cadw a bod yr holl ddata wedi'i newid yn llwyr.
Os ydym yn tynnu cyfatebiaethau â rhaglennu rheolaidd, yna pan fyddwch chi'n defnyddio dulliau megis ysgrifennu, sy'n ysgrifennu rhywbeth i ddisg, ac ar ôl iddo ddychwelyd ymateb i chi, nid oes unrhyw sicrwydd eich bod wedi ysgrifennu'r data i ddisg. A hyd yn oed pan fydd y system weithredu'n hyderus bod popeth wedi'i ysgrifennu, mae yna fecanweithiau yn y ddisg ei hun lle mae'r broses yn mynd trwy haenau o glustogau, a dim ond ar ôl hynny y gosodir y data ar y ddisg.
Defnyddir galwadau asyncronaidd yn bennaf. Mae hyn yn caniatáu i'r cleient weithio ochr yn ochr â gwahanol geisiadau. Gallwch ddefnyddio'r dull cydamserol, ond mae'n llai cynhyrchiol.
Y ddau weithrediad y buom yn siarad amdanynt yw diweddaru/ysgrifennu, sy'n newid data. Y rhain yw creu, setData, cysoni, dileu. Ac mae darllen yn bodoli, getData, getChildren.
Nawr rhai enghreifftiau o sut y gallwch wneud cyntefig ar gyfer gweithio mewn system ddosbarthedig. Er enghraifft, yn ymwneud â ffurfweddiad rhywbeth. Mae gweithiwr newydd wedi ymddangos. Fe wnaethom ychwanegu'r peiriant a dechrau'r broses. Ac mae'r tri chwestiwn canlynol. Sut mae'n cwestiynu ZooKeeper ar gyfer cyfluniad? Ac os ydym am newid y cyfluniad, sut ydym ni'n ei newid? Ac ar ôl i ni ei newid, sut mae'r gweithwyr hynny oedd gennym ni yn ei gael?
Mae ZooKeeper yn gwneud hyn yn gymharol hawdd. Er enghraifft, mae ein coeden znode. Mae nod ar gyfer ein cais yma, rydym yn creu nod ychwanegol ynddo, sy'n cynnwys data o'r ffurfweddiad. Gall y rhain fod yn baramedrau ar wahân neu beidio. Gan fod y maint yn fach, mae maint y cyfluniad fel arfer yn fach hefyd, felly mae'n eithaf posibl ei storio yma.
Rydych chi'n defnyddio'r dull caelData i gael y cyfluniad ar gyfer y gweithiwr o'r nod. Wedi'i osod yn wir. Os nad yw'r nod hwn yn bodoli am ryw reswm, byddwn yn cael gwybod amdano pan fydd yn ymddangos, neu pan fydd yn newid. Os ydym am wybod bod rhywbeth wedi newid, yna fe'i gosodwn yn wir. Ac os bydd y data yn y nod hwn yn newid, byddwn yn gwybod amdano.
SetData. Rydyn ni'n gosod y data, yn gosod "-1", h.y. nid ydym yn gwirio'r fersiwn, rydym yn tybio bod gennym ni un ffurfweddiad bob amser, nid oes angen i ni storio llawer o ffurfweddiadau. Os oes angen i chi storio llawer, bydd angen i chi ychwanegu lefel arall. Yma credwn mai dim ond un sydd, felly dim ond yr un diweddaraf rydyn ni'n ei ddiweddaru, felly nid ydym yn gwirio'r fersiwn. Ar hyn o bryd, mae pob cleient sydd wedi tanysgrifio o'r blaen yn derbyn hysbysiad bod rhywbeth wedi newid yn y nod hwn. Ac ar ôl iddynt ei dderbyn, rhaid iddynt hefyd ofyn am y data eto. Yr hysbysiad yw nad ydynt yn derbyn y data ei hun, ond dim ond hysbysiad o newidiadau. Ar ôl hyn rhaid iddynt ofyn am ddata newydd.
Yr ail opsiwn ar gyfer defnyddio'r cyntefig yw aelodaeth grŵp. Mae gennym ni gais wedi'i ddosbarthu, mae yna griw o weithwyr ac rydyn ni eisiau deall eu bod nhw i gyd yn eu lle. Felly, rhaid iddynt gofrestru eu hunain eu bod yn gweithio yn ein cais. Ac rydym hefyd am gael gwybod, naill ai o'r broses Meistr neu yn rhywle arall, am yr holl weithwyr gweithredol sydd gennym ar hyn o bryd.
Sut ydyn ni'n gwneud hyn? Ar gyfer y cais, rydym yn creu nod gweithwyr ac yn ychwanegu is-lefel yno gan ddefnyddio'r dull creu. Mae gennyf gamgymeriad ar y sleid. Yma mae angen dilyniannol nodi, yna bydd yr holl weithwyr yn cael eu creu fesul un. Ac mae'r cais, sy'n gofyn am yr holl ddata am blant y nod hwn, yn derbyn yr holl weithwyr gweithredol sy'n bodoli.
Mae hwn yn weithrediad mor ofnadwy o sut y gellir gwneud hyn mewn cod Java. Gadewch i ni ddechrau o'r diwedd, gyda'r prif ddull. Dyma ein dosbarth, gadewch i ni greu ei ddull. Fel y ddadl gyntaf rydym yn defnyddio gwesteiwr, lle rydym yn cysylltu, h.y. rydym yn ei osod fel dadl. A'r ail ddadl yw enw'r grŵp.
Sut mae'r cysylltiad yn digwydd? Dyma enghraifft syml o'r API a ddefnyddir. Mae popeth yn gymharol syml yma. Mae ZooCeidwad dosbarth safonol. Rydym yn trosglwyddo gwesteiwyr iddo. A gosodwch y terfyn amser, er enghraifft, i 5 eiliad. Ac mae gennym ni aelod o'r enw connectedSignal. Yn y bôn, rydym yn creu grŵp ar hyd y llwybr a drosglwyddir. Nid ydym yn ysgrifennu data yno, er y gallai rhywbeth fod wedi'i ysgrifennu. Ac mae'r nôd yma o'r math parhaus. Yn y bôn, mae hwn yn nod rheolaidd arferol a fydd yn bodoli drwy'r amser. Dyma lle mae'r sesiwn yn cael ei chreu. Dyma weithrediad y cleient ei hun. Bydd ein cleient yn adrodd o bryd i'w gilydd bod y sesiwn yn fyw. A phan rydyn ni'n gorffen y sesiwn, rydyn ni'n galw'n agos a dyna ni, mae'r sesiwn yn disgyn. Mae hyn rhag ofn i rywbeth ddisgyn oddi ar ein rhan, fel bod ZooKeeper yn dod i wybod amdano ac yn gorffen y sesiwn.
Sut i gloi adnodd? Yma mae popeth ychydig yn fwy cymhleth. Mae gennym set o weithwyr, mae rhywfaint o adnoddau yr ydym am eu cloi. I wneud hyn, rydym yn creu nod ar wahân, er enghraifft, o'r enw lock1. Pe baem yn gallu ei greu, yna cawsom glo yma. A phe na baem yn gallu ei greu, yna mae'r gweithiwr yn ceisio cael getData o'r fan hon, a chan fod y nod eisoes wedi'i greu, yna rydym yn rhoi gwyliwr yma a'r eiliad y mae cyflwr y nod hwn yn newid, byddwn yn gwybod amdano. A gallwn geisio cael amser i'w ail-greu. Pe baem yn cymryd y nod hwn, yn cymryd y clo hwn, yna ar ôl i ni beidio â bod angen y clo mwyach, byddwn yn rhoi'r gorau iddo, gan mai dim ond o fewn y sesiwn y mae'r nod yn bodoli. Yn unol â hynny, bydd yn diflannu. A bydd cleient arall, o fewn fframwaith sesiwn arall, yn gallu cymryd y clo ar y nod hwn, neu yn hytrach, bydd yn derbyn hysbysiad bod rhywbeth wedi newid a gall geisio ei wneud mewn pryd.
Enghraifft arall o sut y gallwch ddewis y prif arweinydd. Mae hyn ychydig yn fwy cymhleth, ond hefyd yn gymharol syml. Beth sy'n digwydd yma? Mae prif nôd yn agregu yr holl weithwyr. Rydym yn ceisio cael data am yr arweinydd. Pe bai hyn yn digwydd yn llwyddiannus, h.y. cawsom rywfaint o ddata, yna mae ein gweithiwr yn dechrau dilyn yr arweinydd hwn. Mae'n credu bod yna arweinydd yn barod.
Os bu farw'r arweinydd am ryw reswm, er enghraifft, yn disgyn i ffwrdd, yna rydym yn ceisio creu arweinydd newydd. Ac os byddwn yn llwyddo, yna mae ein gweithiwr yn dod yn arweinydd. Ac os yw rhywun ar hyn o bryd yn llwyddo i greu arweinydd newydd, yna rydyn ni'n ceisio deall pwy ydyw ac yna'n ei ddilyn.
Yma mae'r effaith buches fel y'i gelwir yn codi, h.y. effaith y fuches, oherwydd pan fydd arweinydd yn marw, yr un sydd gyntaf mewn amser fydd yr arweinydd.
Wrth gipio adnodd, gallwch geisio defnyddio dull ychydig yn wahanol, sydd fel a ganlyn. Er enghraifft, rydym am gael clo, ond heb yr effaith hert. Bydd yn cynnwys y ffaith bod ein cais yn gofyn am restrau o'r holl ddulliau adnabod nodau ar gyfer nod sy'n bodoli eisoes gyda chlo. Ac os cyn hynny y nod y gwnaethom greu clo ar ei gyfer yw'r lleiaf o'r set a gawsom, yna mae hyn yn golygu ein bod wedi dal y clo. Rydym yn gwirio ein bod wedi derbyn clo. Fel siec, bydd amod bod yr id a gawsom wrth greu clo newydd yn fach iawn. Ac os ydym yn ei dderbyn, yna rydym yn gweithio ymhellach.
Os oes yna ID penodol sy'n llai na'n clo, yna rydyn ni'n rhoi gwyliwr ar y digwyddiad hwn ac yn aros am hysbysiad nes bod rhywbeth yn newid. Hynny yw, cawsom y clo hwn. A hyd nes iddo ddisgyn, ni fyddwn yn dod yn isafswm id ac ni fyddwn yn derbyn y clo lleiaf, ac felly byddwn yn gallu mewngofnodi. Ac os na chaiff yr amod hwn ei fodloni, yna rydym yn mynd yma ar unwaith ac yn ceisio cael y clo hwn eto, oherwydd gallai rhywbeth fod wedi newid yn ystod yr amser hwn.
Beth mae ZooKeeper yn ei gynnwys? Mae 4 prif beth. Mae hyn yn prosesu prosesau - Cais. A hefyd Darllediad Atomig ZooKeeper. Mae Cofnod Ymrwymiad lle mae'r holl weithrediadau'n cael eu cofnodi. A'r DB Atgynhyrchedig Er cof ei hun, h.y. y gronfa ddata ei hun lle mae'r goeden gyfan hon yn cael ei storio.
Mae'n werth nodi bod yr holl weithrediadau ysgrifennu yn mynd trwy'r Prosesydd Cais. Ac mae gweithrediadau darllen yn mynd yn syth i'r gronfa ddata In-memory.
Mae'r gronfa ddata ei hun wedi'i hailadrodd yn llawn. Mae pob achos o ZooKeeper yn storio copi cyflawn o'r data.
Er mwyn adfer y gronfa ddata ar ôl damwain, mae log Commit. Yr arfer safonol yw, cyn i ddata fynd i'r cof, ei fod wedi'i ysgrifennu yno fel y gellir chwarae'r log hwn yn ôl ac adfer cyflwr y system os bydd yn damwain. A defnyddir cipluniau cyfnodol o'r gronfa ddata hefyd.
Mae Darllediad Atomig ZooKeeper yn beth sy'n cael ei ddefnyddio i gynnal data a ailadroddir.
Mae ZAB yn dewis arweinydd yn fewnol o safbwynt y nod ZooKeeper. Mae nodau eraill yn dod yn ddilynwyr iddi ac yn disgwyl rhai gweithredoedd ganddi. Os ydyn nhw'n derbyn cynigion, maen nhw'n eu hanfon ymlaen i gyd at yr arweinydd. Mae'n perfformio llawdriniaeth ysgrifennu yn gyntaf ac yna'n anfon neges am yr hyn sydd wedi newid i'w ddilynwyr. Rhaid i hyn, mewn gwirionedd, gael ei berfformio'n atomig, h.y. rhaid i weithrediad recordio a darlledu'r holl beth gael ei berfformio'n atomig, a thrwy hynny warantu cysondeb data.
Mae'n prosesu ceisiadau ysgrifennu yn unig. Ei brif dasg yw ei fod yn trawsnewid y llawdriniaeth yn ddiweddariad trafodaethol. Mae hwn yn gais a gynhyrchwyd yn arbennig.
Ac yma mae'n werth nodi bod analluedd diweddariadau ar gyfer yr un llawdriniaeth wedi'i warantu. Beth yw e? Bydd gan y peth hwn, os caiff ei weithredu ddwywaith, yr un cyflwr, h.y. ni fydd y cais ei hun yn newid. Ac mae angen gwneud hyn er mwyn i chi allu ailgychwyn y llawdriniaeth rhag ofn y bydd damwain, a thrwy hynny symud yn ôl y newidiadau sydd wedi disgyn i ffwrdd ar hyn o bryd. Yn yr achos hwn, bydd cyflwr y system yn dod yr un fath, h.y. ni ddylai fod yn wir bod cyfres o'r un peth, er enghraifft, prosesau diweddaru, wedi arwain at wahanol gyflwr terfynol y system.
Ffynhonnell: hab.com