"ហាដូប។ ZooKeeper" ពីស៊េរី Mail.Ru Group Technostream "វិធីសាស្រ្តសម្រាប់ដំណើរការចែកចាយនៃទិន្នន័យដ៏ធំនៅក្នុង Hadoop"

ខ្ញុំស្នើឱ្យអ្នកអានប្រតិចារឹកនៃការបង្រៀន "Hadoop. ZooKeeper" ពីស៊េរី "វិធីសាស្រ្តសម្រាប់ដំណើរការចែកចាយនៃទិន្នន័យដ៏ធំនៅក្នុង Hadoop"

តើ ZooKeeper ជាកន្លែងរបស់វានៅក្នុងប្រព័ន្ធអេកូឡូស៊ី Hadoop ។ ភាពមិនពិតអំពីការគណនាចែកចាយ។ ដ្យាក្រាមនៃប្រព័ន្ធចែកចាយស្តង់ដារ។ ភាពលំបាកក្នុងការសម្របសម្រួលប្រព័ន្ធចែកចាយ។ បញ្ហាសំរបសំរួលធម្មតា។ គោលការណ៍នៅពីក្រោយការរចនា ZooKeeper ។ គំរូទិន្នន័យ ZooKeeper ទង់ znode ។ វគ្គ។ API អតិថិជន។ បុព្វកាល (ការកំណត់រចនាសម្ព័ន្ធ សមាជិកភាពក្រុម ការចាក់សោសាមញ្ញ ការបោះឆ្នោតមេដឹកនាំ ការចាក់សោដោយគ្មានឥទ្ធិពលហ្វូង)។ ស្ថាបត្យកម្ម ZooKeeper ។ ZooKeeper DB ។ ZAB ស្នើសុំអ្នកដោះស្រាយ។

ថ្ងៃនេះយើងនឹងនិយាយអំពី ZooKeeper ។ រឿងនេះមានប្រយោជន៍ណាស់។ វាដូចជាផលិតផល Apache Hadoop ណាមួយមានឡូហ្គោ។ វាពិពណ៌នាអំពីបុរសម្នាក់។

មុននេះ យើងបាននិយាយជាចំបងអំពីរបៀបដែលទិន្នន័យអាចត្រូវបានដំណើរការនៅទីនោះ របៀបរក្សាទុកវា នោះគឺជារបៀបប្រើវា និងធ្វើការជាមួយវាដូចម្ដេច។ ហើយថ្ងៃនេះខ្ញុំចង់និយាយបន្តិចអំពីការកសាងកម្មវិធីចែកចាយ។ ហើយ ZooKeeper គឺជាវត្ថុមួយក្នុងចំណោមវត្ថុទាំងនោះដែលអនុញ្ញាតឱ្យអ្នកធ្វើឱ្យរឿងនេះសាមញ្ញ។ នេះគឺជាប្រភេទនៃសេវាកម្មដែលមានបំណងសម្រាប់ប្រភេទនៃការសម្របសម្រួលនៃអន្តរកម្មនៃដំណើរការនៅក្នុងប្រព័ន្ធចែកចាយ នៅក្នុងកម្មវិធីដែលបានចែកចាយ។

តម្រូវការសម្រាប់កម្មវិធីបែបនេះកាន់តែមានកាន់តែច្រើនឡើងជារៀងរាល់ថ្ងៃ នោះហើយជាអ្វីដែលវគ្គសិក្សារបស់យើងគឺទាំងអស់អំពី។ ម៉្យាងវិញទៀត MapReduce និងក្របខ័ណ្ឌដែលត្រៀមរួចជាស្រេចនេះអនុញ្ញាតឱ្យអ្នកកម្រិតភាពស្មុគស្មាញនេះ និងដោះលែងអ្នកសរសេរកម្មវិធីពីការសរសេរបុព្វកាលដូចជាអន្តរកម្ម និងការសម្របសម្រួលនៃដំណើរការ។ ប៉ុន្តែ​ផ្ទុយ​ទៅ​វិញ គ្មាន​នរណា​ធានា​ថា​នឹង​មិន​ត្រូវ​ធ្វើ​បែប​នេះ​ឡើយ។ MapReduce ឬក្របខ័ណ្ឌដែលត្រៀមរួចជាស្រេចផ្សេងទៀតមិនតែងតែជំនួសទាំងស្រុងនូវករណីមួយចំនួនដែលមិនអាចត្រូវបានអនុវត្តដោយប្រើវានោះទេ។ រួមទាំង MapReduce ខ្លួនវាផ្ទាល់ និងគម្រោង Apache មួយចំនួនទៀត តាមពិតពួកគេក៏ត្រូវបានចែកចាយកម្មវិធីផងដែរ។ ហើយដើម្បីធ្វើឱ្យការសរសេរកាន់តែងាយស្រួល ពួកគេបានសរសេរ ZooKeeper ។

ដូចកម្មវិធីទាំងអស់ដែលទាក់ទងនឹង Hadoop វាត្រូវបានបង្កើតឡើងដោយ Yahoo! ឥឡូវនេះវាក៏ជាកម្មវិធី Apache ផ្លូវការផងដែរ។ វាមិនត្រូវបានអភិវឌ្ឍយ៉ាងសកម្មដូច HBase ទេ។ ប្រសិនបើអ្នកទៅ JIRA HBase នោះរាល់ថ្ងៃមានរបាយការណ៍អំពីបញ្ហាជាច្រើន សំណើមួយចំនួនដើម្បីបង្កើនប្រសិទ្ធភាពអ្វីមួយ ពោលគឺជីវិតនៅក្នុងគម្រោងកំពុងដំណើរការឥតឈប់ឈរ។ ហើយ ZooKeeper នៅលើដៃម្ខាងគឺជាផលិតផលសាមញ្ញហើយម្យ៉ាងវិញទៀតវាធានានូវភាពជឿជាក់របស់វា។ ហើយវាពិតជាងាយស្រួលប្រើ ដែលនេះជាមូលហេតុដែលវាបានក្លាយជាស្តង់ដារនៅក្នុងកម្មវិធីនៅក្នុងប្រព័ន្ធអេកូ Hadoop ។ ដូច្នេះ ខ្ញុំ​គិត​ថា វា​នឹង​មាន​ប្រយោជន៍​ក្នុង​ការ​ពិនិត្យ​មើល​វា​ដើម្បី​យល់​ពី​របៀប​ដែល​វា​ដំណើរការ និង​របៀប​ប្រើ​វា។

នេះ​ជា​រូបភាព​ដែល​យើង​បាន​បង្រៀន។ យើង​អាច​និយាយ​បាន​ថា វា​ជា​រាង​មូល​ចំពោះ​អ្វី​គ្រប់​យ៉ាង​ដែល​យើង​បាន​ពិចារណា​រហូត​មក​ដល់​ពេល​នេះ។ ហើយអ្វីគ្រប់យ៉ាងដែលត្រូវបានចង្អុលបង្ហាញនៅទីនេះ ក្នុងកម្រិតមួយ ឬមួយផ្សេងទៀត ដំណើរការជាមួយ ZooKeeper ពោលគឺវាគឺជាសេវាកម្មដែលប្រើប្រាស់ផលិតផលទាំងអស់នេះ។ ទាំង HDFS និង MapReduce មិនសរសេរសេវាកម្មស្រដៀងគ្នាផ្ទាល់ខ្លួនរបស់ពួកគេដែលនឹងធ្វើការជាពិសេសសម្រាប់ពួកគេ។ ដូច្នោះហើយ ZooKeeper ត្រូវបានប្រើ។ ហើយនេះជួយសម្រួលដល់ការអភិវឌ្ឍន៍ និងរឿងមួយចំនួនដែលទាក់ទងនឹងកំហុស។

តើទាំងអស់នេះមកពីណា? វាហាក់បីដូចជាយើងបានបើកដំណើរការកម្មវិធីពីរស្របគ្នានៅលើកុំព្យូទ័រផ្សេងៗគ្នា ដោយភ្ជាប់ពួកវាជាមួយខ្សែអក្សរ ឬក្នុងសំណាញ់ ហើយអ្វីៗដំណើរការ។ ប៉ុន្តែបញ្ហាគឺថា បណ្តាញមិនគួរឱ្យទុកចិត្ត ហើយប្រសិនបើអ្នកស្រូបចរាចរ ឬមើលអ្វីដែលកំពុងកើតឡើងនៅទីនោះក្នុងកម្រិតទាប របៀបដែលអតិថិជនធ្វើអន្តរកម្មនៅលើបណ្តាញ អ្នកអាចមើលឃើញជាញឹកញាប់ថាកញ្ចប់ព័ត៌មានមួយចំនួនត្រូវបានបាត់បង់ ឬផ្ញើឡើងវិញ។ វាមិនមែនសម្រាប់អ្វីទាំងអស់ដែលពិធីការ TCP ត្រូវបានបង្កើតឡើង ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតវគ្គជាក់លាក់មួយ និងធានាការបញ្ជូនសារ។ ប៉ុន្តែក្នុងករណីណាក៏ដោយ សូម្បីតែ TCP ក៏មិនអាចជួយសង្រ្គោះអ្នកបានដែរ។ អ្វី​គ្រប់​យ៉ាង​មាន​ពេល​វេលា។ បណ្តាញអាចនឹងរលត់មួយរយៈ។ វាប្រហែលជាគ្រាន់តែព្រិចភ្នែក។ ហើយទាំងអស់នេះនាំឱ្យការពិតដែលថាអ្នកមិនអាចពឹងផ្អែកលើបណ្តាញដែលអាចទុកចិត្តបាន។ នេះគឺជាភាពខុសគ្នាដ៏សំខាន់ពីការសរសេរកម្មវិធីប៉ារ៉ាឡែលដែលដំណើរការលើកុំព្យូទ័រមួយ ឬនៅលើកុំព្យូទ័រទំនើបមួយ ដែលមិនមានបណ្តាញ ដែលជាកន្លែងដែលមានឡានក្រុងផ្លាស់ប្តូរទិន្នន័យដែលអាចទុកចិត្តបានជាងនៅក្នុងអង្គចងចាំ។ ហើយនេះគឺជាភាពខុសគ្នាជាមូលដ្ឋាន។

ក្នុងចំណោមរបស់ផ្សេងទៀត នៅពេលប្រើបណ្តាញ តែងតែមាន latency ជាក់លាក់។ ថាសក៏មានវាដែរ ប៉ុន្តែបណ្តាញមានច្រើនជាងនេះ។ Latency គឺ​ជា​ពេល​វេលា​ពន្យារ​ពេល​មួយ​ចំនួន ដែល​អាច​មាន​ទំហំ​តូច ឬ​សំខាន់។

បណ្តាញ topology កំពុងផ្លាស់ប្តូរ។ តើអ្វីទៅជា topology - នេះគឺជាការដាក់ឧបករណ៍បណ្តាញរបស់យើង។ មានមជ្ឈមណ្ឌលទិន្នន័យ មានរ៉ាកែតដែលឈរនៅទីនោះ មានទៀន។ ទាំងអស់នេះអាចត្រូវបានតភ្ជាប់ឡើងវិញ ផ្លាស់ទី។ល។ ទាំងអស់នេះក៏ត្រូវយកមកពិចារណាផងដែរ។ ឈ្មោះ IP ផ្លាស់ប្តូរ ផ្លូវដែលចរាចរណ៍របស់យើងផ្លាស់ប្តូរ។ នេះក៏ចាំបាច់ត្រូវយកមកពិចារណាផងដែរ។

បណ្តាញក៏អាចផ្លាស់ប្តូរផងដែរនៅក្នុងលក្ខខណ្ឌនៃឧបករណ៍។ ពីការអនុវត្ត ខ្ញុំអាចនិយាយបានថាវិស្វករបណ្តាញរបស់យើងពិតជាចូលចិត្តធ្វើបច្ចុប្បន្នភាពអ្វីមួយនៅលើទៀនជាទៀងទាត់។ ភ្លាមៗនោះកម្មវិធីបង្កប់ថ្មីមួយបានចេញមក ហើយពួកគេមិនចាប់អារម្មណ៍ជាពិសេសទៅលើក្រុម Hadoop មួយចំនួនទេ។ ពួកគេមានការងារផ្ទាល់ខ្លួន។ សម្រាប់ពួកគេរឿងសំខាន់គឺថាបណ្តាញដំណើរការ។ ដូច្នោះហើយ ពួកគេចង់បង្ហោះអ្វីមួយឡើងវិញនៅទីនោះ ធ្វើពន្លឺលើផ្នែករឹងរបស់ពួកគេ ហើយផ្នែករឹងក៏ផ្លាស់ប្តូរតាមកាលកំណត់ផងដែរ។ ទាំងអស់នេះ ដូចម្ដេចត្រូវយកមកពិចារណា។ ទាំងអស់នេះប៉ះពាល់ដល់កម្មវិធីដែលបានចែកចាយរបស់យើង។

ជាធម្មតាមនុស្សដែលចាប់ផ្តើមធ្វើការជាមួយទិន្នន័យដ៏ធំសម្រាប់ហេតុផលមួយចំនួនជឿថាអ៊ីនធឺណិតគ្មានដែនកំណត់។ ប្រសិនបើមានឯកសារជាច្រើន terabytes នៅទីនោះ អ្នកអាចយកវាទៅ server ឬកុំព្យូទ័ររបស់អ្នក ហើយបើកវាដោយប្រើ ឆ្មា និងមើល។ កំហុសមួយទៀតគឺនៅក្នុង Vim មើលកំណត់ហេតុ។ កុំធ្វើបែបនេះព្រោះវាអាក្រក់។ ដោយសារតែ Vim ព្យាយាមរារាំងអ្វីៗគ្រប់យ៉ាង ផ្ទុកអ្វីៗគ្រប់យ៉ាងទៅក្នុងការចងចាំ ជាពិសេសនៅពេលដែលយើងចាប់ផ្តើមឆ្លងកាត់កំណត់ហេតុនេះ ហើយស្វែងរកអ្វីមួយ។ ទាំងនេះជារឿងដែលគេបំភ្លេចចោល ប៉ុន្តែគួរពិចារណា។

វាកាន់តែងាយស្រួលក្នុងការសរសេរកម្មវិធីមួយដែលដំណើរការលើកុំព្យូទ័រមួយជាមួយនឹង processor មួយ។

នៅពេលដែលប្រព័ន្ធរបស់យើងរីកចម្រើន យើងចង់ប៉ារ៉ាឡែលវាទាំងអស់ ហើយប៉ារ៉ាឡែលវាមិនត្រឹមតែនៅលើកុំព្យូទ័រប៉ុណ្ណោះទេ ប៉ុន្តែក៏នៅលើចង្កោមផងដែរ។ សំណួរកើតឡើង៖ របៀបសម្របសម្រួលបញ្ហានេះ? កម្មវិធីរបស់យើងប្រហែលជាមិនមានអន្តរកម្មជាមួយគ្នាទេ ប៉ុន្តែយើងបានដំណើរការដំណើរការជាច្រើនស្របគ្នានៅលើម៉ាស៊ីនមេជាច្រើន។ ហើយ​ធ្វើ​ដូចម្តេច​ដើម្បី​ត្រួត​ពិនិត្យ​ថា​អ្វី​គ្រប់​យ៉ាង​គឺ​ល្អ​សម្រាប់​ពួក​គេ? ឧទាហរណ៍ ពួកគេផ្ញើអ្វីមួយតាមអ៊ីនធឺណិត។ ពួកគេត្រូវតែសរសេរអំពីរដ្ឋរបស់ពួកគេនៅកន្លែងណាមួយ ឧទាហរណ៍ នៅក្នុងប្រភេទនៃមូលដ្ឋានទិន្នន័យ ឬកំណត់ហេតុមួយចំនួន បន្ទាប់មកប្រមូលផ្តុំកំណត់ហេតុនេះ ហើយបន្ទាប់មកវិភាគវានៅកន្លែងណាមួយ។ លើសពីនេះ យើងត្រូវពិចារណាថា ដំណើរការនេះដំណើរការហើយដំណើរការ ស្រាប់តែមានកំហុសខ្លះលេចឡើងនៅក្នុងវា ឬវាគាំង តើយើងនឹងដឹងអំពីវាលឿនប៉ុណ្ណា?

វាច្បាស់ណាស់ថាអ្វីៗទាំងអស់នេះអាចត្រូវបានត្រួតពិនិត្យយ៉ាងឆាប់រហ័ស។ នេះក៏ល្អផងដែរ ប៉ុន្តែការត្រួតពិនិត្យគឺជារឿងមានកំណត់ដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យរឿងមួយចំនួននៅកម្រិតខ្ពស់បំផុត។

នៅពេលដែលយើងចង់ឱ្យដំណើរការរបស់យើងចាប់ផ្តើមធ្វើអន្តរកម្មគ្នាទៅវិញទៅមក ឧទាហរណ៍ បញ្ជូនទិន្នន័យមួយចំនួនទៅគ្នាទៅវិញទៅមក នោះសំណួរក៏កើតឡើងផងដែរ - តើវានឹងកើតឡើងដោយរបៀបណា? តើ​នឹង​មាន​លក្ខខណ្ឌ​ការ​ប្រណាំង​មួយ​ចំនួន​ដែរ​ទេ តើ​ពួកគេ​នឹង​សរសេរ​ជាន់​លើ​គ្នា​នឹង​ទិន្នន័យ​មក​ដល់​ត្រឹម​ត្រូវ​ដែរ​ឬ​ទេ តើ​នឹង​មាន​អ្វី​បាត់​បង់​តាម​ផ្លូវ​ដែរ​ឬ​ទេ? យើង​ត្រូវ​បង្កើត​ពិធីការ​មួយ​ចំនួន។ល។

ការសម្របសម្រួលនៃដំណើរការទាំងអស់នេះមិនមែនជារឿងតូចតាចទេ។ ហើយ​វា​បង្ខំ​ឱ្យ​អ្នក​អភិវឌ្ឍន៍​ចុះ​ទៅ​កម្រិត​ទាប​ជាង​មុន ហើយ​សរសេរ​ប្រព័ន្ធ​ទាំង​ពី​ដើម ឬ​មិន​មែន​ពី​ដំបូង​ឡើយ ប៉ុន្តែ​នេះ​មិន​សាមញ្ញ​ប៉ុន្មាន​ទេ។

ប្រសិនបើអ្នកបង្កើតក្បួនដោះស្រាយគ្រីបគ្រីប ឬសូម្បីតែអនុវត្តវា សូមបោះវាចោលភ្លាមៗ ព្រោះវាទំនងជាមិនដំណើរការសម្រាប់អ្នកទេ។ វាទំនងជាមានកំហុសជាច្រើនដែលអ្នកភ្លេចផ្ដល់ជូន។ កុំប្រើវាសម្រាប់អ្វីដែលធ្ងន់ធ្ងរព្រោះវាទំនងជាមិនស្ថិតស្ថេរ។ ព្រោះ​រាល់​ក្បួន​ដោះស្រាយ​ទាំង​អស់​ដែល​មាន​ត្រូវ​បាន​សាកល្បង​ដោយ​ពេល​វេលា​ជា​យូរ​មក​ហើយ។ វាត្រូវបានរំខានដោយសហគមន៍។ នេះគឺជាប្រធានបទដាច់ដោយឡែកមួយ។ ហើយវាដូចគ្នានៅទីនេះ។ ប្រសិនបើមិនអាចអនុវត្តប្រភេទនៃការធ្វើសមកាលកម្មដោយខ្លួនឯងបានទេនោះ វាជាការប្រសើរជាងកុំធ្វើបែបនេះព្រោះវាស្មុគស្មាញណាស់ ហើយនាំអ្នកទៅកាន់ផ្លូវរង្គោះរង្គើនៃការស្វែងរកកំហុសជានិច្ច។

ថ្ងៃនេះយើងកំពុងនិយាយអំពី ZooKeeper ។ ម៉្យាងវិញទៀតវាគឺជាក្របខ័ណ្ឌមួយ ម្យ៉ាងវិញទៀតវាគឺជាសេវាកម្មដែលធ្វើឱ្យជីវិតកាន់តែងាយស្រួលសម្រាប់អ្នកអភិវឌ្ឍន៍ និងសម្រួលដល់ការអនុវត្តតក្កវិជ្ជា និងការសម្របសម្រួលនៃដំណើរការរបស់យើងតាមដែលអាចធ្វើទៅបាន។

ចូរយើងចងចាំថាតើប្រព័ន្ធចែកចាយស្តង់ដារអាចមើលទៅដូចម្ដេច។ នេះគឺជាអ្វីដែលយើងបាននិយាយ - HDFS, HBase ។ មានដំណើរការមេដែលគ្រប់គ្រងកម្មករ និងដំណើរការទាសករ។ គាត់មានទំនួលខុសត្រូវក្នុងការសម្របសម្រួល និងចែកចាយការងារ ចាប់ផ្តើមកម្មករឡើងវិញ បើកដំណើរការថ្មី និងចែកចាយបន្ទុក។

ភាពជឿនលឿនជាងនេះទៅទៀតគឺ សេវាកម្មសម្របសម្រួល ពោលគឺផ្លាស់ទីកិច្ចការសំរបសំរួលខ្លួនវាទៅក្នុងដំណើរការដាច់ដោយឡែក បូកនឹងដំណើរការប្រភេទនៃការបម្រុងទុកមួយចំនួន ឬ stanby Master ស្របគ្នា ពីព្រោះ Master អាចនឹងបរាជ័យ។ ហើយប្រសិនបើ Master ធ្លាក់នោះប្រព័ន្ធរបស់យើងនឹងមិនដំណើរការទេ។ យើងកំពុងដំណើរការការបម្រុងទុក។ បញ្ជាក់ខ្លះថា Master ត្រូវតែចម្លងទៅបម្រុងទុក។ នេះក៏អាចត្រូវបានប្រគល់ឱ្យសេវាកម្មសម្របសម្រួលផងដែរ។ ប៉ុន្តែនៅក្នុងដ្យាក្រាមនេះ ចៅហ្វាយនាយផ្ទាល់ជាអ្នកទទួលខុសត្រូវក្នុងការសម្របសម្រួលកម្មករនៅទីនេះ សេវាកំពុងសម្របសម្រួលសកម្មភាពចម្លងទិន្នន័យ។

ជម្រើសកម្រិតខ្ពស់ជាងនេះគឺនៅពេលដែលការសម្របសម្រួលទាំងអស់ត្រូវបានគ្រប់គ្រងដោយសេវាកម្មរបស់យើង ដូចដែលត្រូវបានធ្វើជាធម្មតា។ គាត់ទទួលខុសត្រូវក្នុងការធ្វើឱ្យប្រាកដថាអ្វីៗដំណើរការ។ ហើយប្រសិនបើមានអ្វីមួយមិនដំណើរការ យើងស្វែងយល់អំពីវា ហើយព្យាយាមជុំវិញស្ថានភាពនេះ។ ក្នុងករណីណាក៏ដោយ យើងនៅសល់តែចៅហ្វាយនាយដែលធ្វើអន្តរកម្មជាមួយទាសករ ហើយអាចផ្ញើទិន្នន័យ ព័ត៌មាន សារជាដើម តាមរយៈសេវាកម្មមួយចំនួន។

មានគ្រោងការណ៍កាន់តែជឿនលឿនជាងនេះទៅទៀត នៅពេលដែលយើងមិនមាន Master ទេ គ្រប់ថ្នាំងទាំងអស់សុទ្ធតែជាទាសករមេ ខុសពីអាកប្បកិរិយារបស់ពួកគេ។ ប៉ុន្តែពួកគេនៅតែត្រូវការប្រាស្រ័យទាក់ទងគ្នាទៅវិញទៅមក ដូច្នេះនៅមានសេវាកម្មមួយចំនួនទៀតដែលនៅសេសសល់ដើម្បីសម្របសម្រួលសកម្មភាពទាំងនេះ។ ប្រហែលជា Cassandra ដែលធ្វើការលើគោលការណ៍នេះសមនឹងគ្រោងការណ៍នេះ។

វាពិបាកក្នុងការនិយាយថាគ្រោងការណ៍ទាំងនេះមួយណាដំណើរការប្រសើរជាង។ ម្នាក់ៗមានគុណសម្បត្តិ និងគុណវិបត្តិរៀងៗខ្លួន។

ហើយមិនចាំបាច់ខ្លាចរឿងខ្លះជាមួយចៅហ្វាយទេ ពីព្រោះដូចការអនុវត្តបង្ហាញថា គាត់មិនងាយនឹងបម្រើជានិច្ចនោះទេ។ រឿងសំខាន់នៅទីនេះគឺជ្រើសរើសដំណោះស្រាយត្រឹមត្រូវសម្រាប់ការបង្ហោះសេវាកម្មនេះនៅលើថ្នាំងដែលមានអនុភាពដាច់ដោយឡែក ដើម្បីឱ្យវាមានធនធានគ្រប់គ្រាន់ ដូច្នេះប្រសិនបើអាចធ្វើទៅបាន អ្នកប្រើប្រាស់មិនមានសិទ្ធិចូលប្រើនៅទីនោះ ដើម្បីកុំឱ្យពួកគេសម្លាប់ដំណើរការនេះដោយចៃដន្យ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ ក្នុងគ្រោងការណ៍បែបនេះ វាកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រងកម្មករពីដំណើរការ Master ពោលគឺគ្រោងការណ៍នេះគឺសាមញ្ញជាងពីទស្សនៈនៃការអនុវត្ត។

ហើយគ្រោងការណ៍នេះ (ខាងលើ) ប្រហែលជាស្មុគស្មាញជាង ប៉ុន្តែអាចទុកចិត្តបានជាង។

បញ្ហាចម្បងគឺការបរាជ័យដោយផ្នែក។ ឧទាហរណ៍៖ នៅពេលដែលយើងផ្ញើសារតាមបណ្តាញ គ្រោះថ្នាក់មួយចំនួនកើតឡើង ហើយអ្នកដែលផ្ញើសារនោះនឹងមិនដឹងថាសាររបស់គាត់ត្រូវបានទទួល ហើយមានអ្វីកើតឡើងនៅខាងអ្នកទទួលនោះ នឹងមិនដឹងថាសារត្រូវបានដំណើរការត្រឹមត្រូវឬអត់។ ពោលគឺគាត់នឹងមិនទទួលបានការបញ្ជាក់ណាមួយឡើយ។

ដូច្នោះហើយ យើងត្រូវតែដំណើរការស្ថានភាពនេះ។ ហើយ​អ្វី​ដែល​សាមញ្ញ​បំផុត​គឺ​ត្រូវ​ផ្ញើ​សារ​នេះ​ឡើង​វិញ ហើយ​រង់ចាំ​រហូត​ដល់​យើង​ទទួល​បាន​ការ​ឆ្លើយតប។ ក្នុងករណីនេះវាមិនត្រូវបានគេយកទៅក្នុងគណនីថាតើស្ថានភាពរបស់អ្នកទទួលបានផ្លាស់ប្តូរទេ។ យើងអាចផ្ញើសារ និងបន្ថែមទិន្នន័យដូចគ្នាពីរដង។

ZooKeeper ផ្តល់នូវវិធីដើម្បីដោះស្រាយជាមួយនឹងការបដិសេធបែបនេះ ដែលធ្វើអោយជីវិតរបស់យើងកាន់តែងាយស្រួលផងដែរ។

ដូចដែលបានរៀបរាប់មុននេះបន្តិច នេះគឺស្រដៀងនឹងការសរសេរកម្មវិធីពហុខ្សែ ប៉ុន្តែភាពខុសគ្នាសំខាន់គឺថានៅក្នុងកម្មវិធីចែកចាយដែលយើងបង្កើតនៅលើម៉ាស៊ីនផ្សេងគ្នា វិធីតែមួយគត់ដើម្បីទំនាក់ទំនងគឺបណ្តាញ។ សំខាន់ នេះ​គឺ​ជា​ស្ថាបត្យកម្ម​ដែល​គ្មាន​ការ​ចែករំលែក។ ដំណើរការ ឬសេវាកម្មនីមួយៗដែលដំណើរការលើម៉ាស៊ីនមួយមានអង្គចងចាំរបស់វា ថាសផ្ទាល់ខ្លួន ខួរក្បាលរបស់វា ដែលវាមិនចែករំលែកជាមួយនរណាម្នាក់ឡើយ។

ប្រសិនបើយើងសរសេរកម្មវិធីពហុខ្សែនៅលើកុំព្យូទ័រមួយ នោះយើងអាចប្រើអង្គចងចាំរួមគ្នាដើម្បីផ្លាស់ប្តូរទិន្នន័យ។ យើងមានកុងតាក់បរិបទនៅទីនោះ ដំណើរការអាចប្តូរបាន។ នេះប៉ះពាល់ដល់ដំណើរការ។ ម៉្យាងវិញទៀតមិនមានរឿងបែបនេះនៅក្នុងកម្មវិធីនៅលើចង្កោមទេ ប៉ុន្តែមានបញ្ហាជាមួយបណ្តាញ។

ដូច្នោះហើយបញ្ហាចម្បងដែលកើតឡើងនៅពេលសរសេរប្រព័ន្ធចែកចាយគឺការកំណត់រចនាសម្ព័ន្ធ។ យើងកំពុងសរសេរកម្មវិធីមួយចំនួន។ ប្រសិនបើវាសាមញ្ញ នោះយើង hardcode គ្រប់ប្រភេទនៃលេខនៅក្នុងកូដ ប៉ុន្តែនេះជាការរអាក់រអួល ព្រោះប្រសិនបើយើងសម្រេចថា ជំនួសឱ្យការអស់ពេលកន្លះវិនាទី យើងចង់អស់ពេលមួយវិនាទី នោះយើងត្រូវចងក្រងកម្មវិធីឡើងវិញ ហើយ រមៀលអ្វីៗទាំងអស់ចេញម្តងទៀត។ វាជារឿងមួយនៅពេលដែលវានៅលើម៉ាស៊ីនតែមួយ នៅពេលដែលអ្នកអាចចាប់ផ្តើមវាឡើងវិញបាន ប៉ុន្តែនៅពេលដែលយើងមានម៉ាស៊ីនជាច្រើន យើងត្រូវចម្លងអ្វីៗគ្រប់យ៉ាងជានិច្ច។ យើងត្រូវតែព្យាយាមធ្វើឱ្យកម្មវិធីអាចកំណត់រចនាសម្ព័ន្ធបាន។

នៅទីនេះយើងកំពុងនិយាយអំពីការកំណត់រចនាសម្ព័ន្ធឋិតិវន្តសម្រាប់ដំណើរការប្រព័ន្ធ។ នេះមិនមែនទាំងស្រុងទេ ប្រហែលជាមកពីទស្សនៈរបស់ប្រព័ន្ធប្រតិបត្តិការ វាអាចជាការកំណត់រចនាសម្ព័ន្ធឋិតិវន្តសម្រាប់ដំណើរការរបស់យើង ពោលគឺនេះគឺជាការកំណត់ដែលមិនអាចត្រូវបានយក និងធ្វើបច្ចុប្បន្នភាព។

ក៏មានការកំណត់រចនាសម្ព័ន្ធថាមវន្តផងដែរ។ ទាំងនេះគឺជាប៉ារ៉ាម៉ែត្រដែលយើងចង់ផ្លាស់ប្តូរភ្លាមៗ ដើម្បីឱ្យពួកវាត្រូវបានជ្រើសរើសនៅទីនោះ។

តើមានបញ្ហាអ្វីនៅទីនេះ? យើងបានអាប់ដេតការកំណត់ បើកវាចេញ ដូច្នេះតើមានអ្វីកើតឡើង? បញ្ហាអាចថានៅលើដៃមួយដែលយើងដាក់ចេញ config ប៉ុន្តែភ្លេចអំពីរឿងថ្មី config នៅតែមាន។ ទីពីរ ខណៈពេលដែលយើងកំពុងដាក់ឱ្យដំណើរការ ការកំណត់រចនាសម្ព័ន្ធត្រូវបានធ្វើបច្ចុប្បន្នភាពនៅកន្លែងខ្លះ ប៉ុន្តែមិនមែននៅកន្លែងផ្សេងទៀតទេ។ ហើយដំណើរការមួយចំនួននៃកម្មវិធីរបស់យើងដែលដំណើរការលើម៉ាស៊ីនមួយត្រូវបានចាប់ផ្តើមឡើងវិញជាមួយនឹងការកំណត់ថ្មី ហើយនៅកន្លែងណាមួយជាមួយនឹងម៉ាស៊ីនចាស់។ នេះអាចបណ្តាលឱ្យកម្មវិធីដែលបានចែកចាយរបស់យើងមិនស្របគ្នាតាមទស្សនៈនៃការកំណត់រចនាសម្ព័ន្ធ។ បញ្ហានេះគឺជារឿងធម្មតា។ សម្រាប់ការកំណត់រចនាសម្ព័ន្ធថាមវន្ត វាមានភាពពាក់ព័ន្ធជាងព្រោះវាបង្កប់ន័យថាវាអាចត្រូវបានផ្លាស់ប្តូរភ្លាមៗ។

បញ្ហាមួយទៀតគឺសមាជិកភាពក្រុម។ យើង​តែង​តែ​មាន​ក្រុម​កម្មករ​ខ្លះ យើង​តែង​តែ​ចង់​ដឹង​ថា​តើ​ពួក​គេ​មួយ​ណា​នៅ​រស់ តើ​មួយ​ណា​ស្លាប់។ ប្រសិនបើមាន Master នោះគាត់ត្រូវតែយល់ថាកម្មករណាខ្លះអាចត្រូវបានបញ្ជូនបន្តទៅអតិថិជនដើម្បីឱ្យពួកគេដំណើរការការគណនាឬធ្វើការជាមួយទិន្នន័យហើយអ្វីដែលមិនអាច។ បញ្ហា​ដែល​កើត​ឡើង​ឥត​ឈប់ឈរ​គឺ​យើង​ត្រូវ​ដឹង​ថា​អ្នក​ណា​កំពុង​ធ្វើ​ការ​ក្នុង​ក្រុម​របស់​យើង។

បញ្ហាធម្មតាមួយទៀតគឺការបោះឆ្នោតមេដឹកនាំ នៅពេលដែលយើងចង់ដឹងថាអ្នកណាជាអ្នកទទួលខុសត្រូវ។ ឧទាហរណ៍មួយគឺការចម្លង នៅពេលដែលយើងមានដំណើរការមួយចំនួនដែលទទួលប្រតិបត្តិការសរសេរ ហើយបន្ទាប់មកចម្លងពួកវាក្នុងចំណោមដំណើរការផ្សេងទៀត។ គាត់​នឹង​ធ្វើ​ជា​អ្នក​ដឹក​នាំ អ្នក​ផ្សេង​ទៀត​នឹង​ស្តាប់​បង្គាប់​គាត់ នឹង​ធ្វើ​តាម​គាត់។ វាចាំបាច់ក្នុងការជ្រើសរើសដំណើរការមួយ ដូច្នេះវាមានភាពមិនច្បាស់លាស់សម្រាប់មនុស្សគ្រប់គ្នា ដូច្នេះវាមិនអាចបង្ហាញថាអ្នកដឹកនាំពីរនាក់ត្រូវបានជ្រើសរើសនោះទេ។

វាក៏មានការចូលប្រើប្រាស់ផ្តាច់មុខទៅវិញទៅមក។ បញ្ហានៅទីនេះគឺស្មុគស្មាញជាង។ មានរឿងដូចជា mutex នៅពេលអ្នកសរសេរកម្មវិធីពហុខ្សែ ហើយចង់ចូលប្រើធនធានមួយចំនួន ឧទាហរណ៍ ក្រឡាអង្គចងចាំ ត្រូវបានកំណត់ និងអនុវត្តដោយខ្សែស្រឡាយតែមួយប៉ុណ្ណោះ។ នៅទីនេះធនធានអាចជាអ្វីដែលអរូបីជាងនេះ។ ហើយកម្មវិធីផ្សេងគ្នាពីថ្នាំងផ្សេងគ្នានៃបណ្តាញរបស់យើងគួរតែទទួលបានសិទ្ធិចូលប្រើផ្តាច់មុខទៅកាន់ធនធានដែលបានផ្តល់ឱ្យប៉ុណ្ណោះ ហើយមិនមែនដូច្នេះអ្នកគ្រប់គ្នាអាចផ្លាស់ប្តូរវា ឬសរសេរអ្វីមួយនៅទីនោះនោះទេ។ ទាំងនេះគឺជាអ្វីដែលគេហៅថាសោ។

ZooKeeper អនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហាទាំងអស់នេះដល់កម្រិតមួយឬមួយផ្សេងទៀត។ ហើយខ្ញុំនឹងបង្ហាញជាមួយឧទាហរណ៍អំពីរបៀបដែលវាអនុញ្ញាតឱ្យអ្នកធ្វើរឿងនេះ។

មិនមានបុព្វហេតុរារាំងទេ។ នៅពេលដែលយើងចាប់ផ្តើមប្រើប្រាស់អ្វីមួយ បុព្វបទនេះនឹងមិនរង់ចាំព្រឹត្តិការណ៍ណាមួយកើតឡើងនោះទេ។ ភាគច្រើន រឿងនេះនឹងដំណើរការដោយអសមកាល ដោយហេតុនេះអនុញ្ញាតឱ្យដំណើរការមិនព្យួរខណៈពេលដែលពួកគេកំពុងរង់ចាំអ្វីមួយ។ នេះគឺជារឿងមានប្រយោជន៍ណាស់។

សំណើរបស់អតិថិជនទាំងអស់ត្រូវបានដំណើរការតាមលំដាប់នៃជួរទូទៅ។

ហើយអតិថិជនមានឱកាសទទួលបានការជូនដំណឹងអំពីការផ្លាស់ប្តូរនៅក្នុងរដ្ឋមួយចំនួន អំពីការផ្លាស់ប្តូរទិន្នន័យ មុនពេលអតិថិជនឃើញទិន្នន័យដែលបានផ្លាស់ប្តូរដោយខ្លួនឯង។

ZooKeeper អាចដំណើរការជាពីររបៀប។ ទីមួយគឺដំណើរការដោយឯករាជ្យ នៅលើណូតតែមួយ។ វាងាយស្រួលសម្រាប់ការសាកល្បង។ វាក៏អាចដំណើរការក្នុងរបៀបចង្កោម នៅលើណូតចំនួនណាមួយក៏បាន។ ម៉ាស៊ីនបម្រើប្រសិនបើយើងមានចង្កោមម៉ាស៊ីន 100 វាមិនចាំបាច់ដំណើរការលើម៉ាស៊ីន 100 នោះទេ។ វាគ្រប់គ្រាន់ហើយក្នុងការបែងចែកម៉ាស៊ីនមួយចំនួនដែល ZooKeeper អាចដំណើរការបាន។ ហើយវាប្រកាន់ខ្ជាប់នូវគោលការណ៍នៃភាពអាចរកបានខ្ពស់។ ZooKeeper រក្សាទុកច្បាប់ចម្លងពេញលេញនៃទិន្នន័យនៅលើ instance នីមួយៗដែលកំពុងដំណើរការ។ ខ្ញុំនឹងពន្យល់ពីរបៀបដែលវាធ្វើបែបនេះនៅពេលក្រោយ។ វាមិនបំបែក ឬបែងចែកទិន្នន័យទេ។ ម៉្យាងវិញទៀត នេះគឺជាគុណវិបត្តិមួយ ពីព្រោះយើងមិនអាចរក្សាទុកបានច្រើនទេ ប៉ុន្តែម៉្យាងវិញទៀត វាមិនចាំបាច់ទេ។ វាមិនត្រូវបានរចនាឡើងសម្រាប់រឿងនោះទេ វាមិនមែនជាមូលដ្ឋានទិន្នន័យទេ។

ទិន្នន័យអាចត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់នៅខាងអតិថិជន។ នេះគឺជាគោលការណ៍ស្ដង់ដារ ដើម្បីកុំឱ្យយើងរំខានសេវាកម្ម ហើយកុំផ្ទុកវាជាមួយនឹងសំណើដូចគ្នា។ អតិថិជនឆ្លាតវៃជាធម្មតាដឹងអំពីបញ្ហានេះ ហើយរក្សាទុកវា។

ជាឧទាហរណ៍ មានអ្វីមួយបានផ្លាស់ប្តូរនៅទីនេះ។ មានកម្មវិធីមួយចំនួន។ អ្នកដឹកនាំថ្មីត្រូវបានជ្រើសរើស ដែលទទួលខុសត្រូវ ឧទាហរណ៍សម្រាប់ដំណើរការប្រតិបត្តិការសរសេរ។ ហើយយើងចង់ចម្លងទិន្នន័យ។ ដំណោះស្រាយមួយគឺត្រូវដាក់វានៅក្នុងរង្វិលជុំ។ ហើយ​យើង​ចោទ​សួរ​សេវាកម្ម​របស់​យើង​ឥត​ឈប់ឈរ - តើ​មាន​អ្វី​ផ្លាស់​ប្តូរ? ជម្រើសទីពីរគឺល្អបំផុត។ នេះគឺជាយន្តការនាឡិកាដែលអនុញ្ញាតឱ្យអ្នកជូនដំណឹងដល់អតិថិជនថាមានអ្វីមួយបានផ្លាស់ប្តូរ។ នេះគឺជាវិធីសាស្ត្រដែលមានតម្លៃថោកជាងទាក់ទងនឹងធនធាន និងកាន់តែងាយស្រួលសម្រាប់អតិថិជន។

អតិថិជនគឺជាអ្នកប្រើប្រាស់ដែលប្រើ ZooKeeper ។

Server គឺជាដំណើរការ ZooKeeper ខ្លួនវាផ្ទាល់។

Znode គឺជារឿងសំខាន់នៅក្នុង ZooKeeper ។ znodes ទាំងអស់ត្រូវបានរក្សាទុកក្នុងសតិដោយ ZooKeeper ហើយត្រូវបានរៀបចំក្នុងទម្រង់នៃដ្យាក្រាមឋានានុក្រមក្នុងទម្រង់ជាមែកធាង។

មានប្រតិបត្តិការពីរប្រភេទ។ ទីមួយគឺការធ្វើបច្ចុប្បន្នភាព/សរសេរ នៅពេលដែលប្រតិបត្តិការមួយចំនួនផ្លាស់ប្តូរស្ថានភាពនៃមែកធាងរបស់យើង។ ដើមឈើគឺជារឿងធម្មតា។

ហើយវាអាចទៅរួចដែលម៉ាស៊ីនភ្ញៀវមិនបំពេញសំណើមួយ ហើយត្រូវបានផ្តាច់ ប៉ុន្តែអាចបង្កើតវគ្គដែលវាធ្វើអន្តរកម្មជាមួយ ZooKeeper ។

គំរូទិន្នន័យរបស់ ZooKeeper ប្រហាក់ប្រហែលនឹងប្រព័ន្ធឯកសារ។ មានឫសស្ដង់ដារហើយបន្ទាប់មកយើងបានទៅដូចជាប្រសិនបើតាមរយៈថតដែលចេញពីឫស។ ហើយបន្ទាប់មកកាតាឡុកនៃកម្រិតទីមួយកម្រិតទីពីរ។ នេះគឺជា znodes ទាំងអស់។

znode នីមួយៗអាចផ្ទុកទិន្នន័យមួយចំនួន ជាធម្មតាមិនមានទំហំធំទេ ឧទាហរណ៍ 10 គីឡូបៃ។ ហើយ znode នីមួយៗអាចមានកូនចំនួនជាក់លាក់។

Znodes មានច្រើនប្រភេទ។ ពួកគេអាចត្រូវបានបង្កើត។ ហើយនៅពេលបង្កើត znode យើងបញ្ជាក់ប្រភេទដែលវាគួរតែជាកម្មសិទ្ធិ។

មានពីរប្រភេទ។ ទីមួយគឺទង់ជាតិអព្យាក្រឹត។ Znode រស់នៅក្នុងវគ្គមួយ។ ឧទាហរណ៍ អតិថិជនបានបង្កើតវគ្គមួយ។ ហើយដរាបណាវគ្គនេះនៅរស់ វានឹងមាន។ នេះគឺចាំបាច់ដើម្បីកុំឱ្យផលិតអ្វីមួយដែលមិនចាំបាច់។ នេះក៏សមរម្យសម្រាប់គ្រាដែលវាមានសារៈសំខាន់សម្រាប់យើងក្នុងការរក្សាទុកទិន្នន័យបឋមនៅក្នុងវគ្គមួយ។

ប្រភេទទីពីរគឺទង់ជាតិជាប់គ្នា។ វាបង្កើនការរាប់នៅតាមផ្លូវទៅ znode ។ ឧទាហរណ៍ យើងមានថតជាមួយកម្មវិធី 1_5។ ហើយនៅពេលដែលយើងបង្កើតថ្នាំងទីមួយ វាទទួលបាន p_1 ទីពីរ - p_2 ។ ហើយនៅពេលដែលយើងហៅវិធីសាស្ត្រនេះរាល់ពេល យើងឆ្លងកាត់ផ្លូវពេញ ដោយបង្ហាញតែផ្នែកនៃផ្លូវប៉ុណ្ណោះ ហើយលេខនេះត្រូវបានបង្កើនដោយស្វ័យប្រវត្តិ ព្រោះយើងបង្ហាញពីប្រភេទថ្នាំង - បន្តបន្ទាប់គ្នា។

znode ធម្មតា។ នាងនឹងតែងតែរស់នៅ ហើយមានឈ្មោះដែលយើងប្រាប់នាង។

អ្វីដែលមានប្រយោជន៍មួយទៀតគឺទង់នាឡិកា។ ប្រសិនបើយើងដំឡើងវា នោះអតិថិជនអាចជាវព្រឹត្តិការណ៍មួយចំនួនសម្រាប់ថ្នាំងជាក់លាក់មួយ។ ខ្ញុំនឹងបង្ហាញអ្នកនៅពេលក្រោយជាមួយនឹងឧទាហរណ៍អំពីរបៀបដែលវាត្រូវបានធ្វើ។ ZooKeeper ខ្លួនវាជូនដំណឹងដល់អតិថិជនថាទិន្នន័យនៅលើថ្នាំងបានផ្លាស់ប្តូរ។ ទោះជាយ៉ាងណាក៏ដោយ ការជូនដំណឹងមិនធានាថាទិន្នន័យថ្មីមួយចំនួនបានមកដល់ទេ។ ពួកគេគ្រាន់តែនិយាយថាមានអ្វីមួយបានផ្លាស់ប្តូរ ដូច្នេះអ្នកនៅតែត្រូវប្រៀបធៀបទិន្នន័យនៅពេលក្រោយជាមួយនឹងការហៅដាច់ដោយឡែក។

ហើយដូចដែលខ្ញុំបាននិយាយរួចហើយ លំដាប់នៃទិន្នន័យត្រូវបានកំណត់ដោយគីឡូបៃ។ មិនចាំបាច់រក្សាទុកទិន្នន័យអត្ថបទធំនៅទីនោះទេ ព្រោះវាមិនមែនជាមូលដ្ឋានទិន្នន័យ វាគឺជាម៉ាស៊ីនមេសម្របសម្រួលសកម្មភាព។

សូមអនុញ្ញាតឱ្យខ្ញុំប្រាប់អ្នកបន្តិចអំពីវគ្គ។ ប្រសិនបើយើងមានម៉ាស៊ីនមេច្រើន យើងអាចប្តូរពីម៉ាស៊ីនមេមួយទៅម៉ាស៊ីនមេមួយទៀតបានយ៉ាងច្បាស់លាស់។ ម៉ាស៊ីនបម្រើដោយប្រើលេខសម្គាល់វគ្គ។ នេះងាយស្រួលណាស់។

វគ្គនីមួយៗមានប្រភេទនៃការអស់ពេល។ វគ្គមួយត្រូវបានកំណត់ដោយថាតើម៉ាស៊ីនភ្ញៀវផ្ញើអ្វីទៅម៉ាស៊ីនមេក្នុងអំឡុងពេលវគ្គនោះ។ ប្រសិនបើគាត់មិនបានបញ្ជូនអ្វីមួយក្នុងអំឡុងពេលអស់ពេលទេ វគ្គនឹងរលត់ ឬអតិថិជនអាចបិទវាដោយខ្លួនឯងបាន។

វាមិនមានលក្ខណៈពិសេសច្រើននោះទេ ប៉ុន្តែអ្នកអាចធ្វើរឿងផ្សេងគ្នាជាមួយ API នេះ។ ការហៅដែលយើងបានឃើញបង្កើតបង្កើត znode ហើយយកប៉ារ៉ាម៉ែត្របី។ នេះគឺជាផ្លូវទៅកាន់ znode ហើយវាត្រូវតែបញ្ជាក់ពេញលេញពីឫស។ ហើយនេះគឺជាទិន្នន័យមួយចំនួនដែលយើងចង់ផ្ទេរនៅទីនោះ។ និងប្រភេទនៃទង់ជាតិ។ ហើយបន្ទាប់ពីបង្កើតវាត្រឡប់ផ្លូវទៅកាន់ znode ។

ទីពីរអ្នកអាចលុបវាបាន។ ល្បិចនៅទីនេះគឺថាប៉ារ៉ាម៉ែត្រទីពីរបន្ថែមលើផ្លូវទៅកាន់ znode អាចបញ្ជាក់កំណែ។ ដូច្នោះហើយ znode នោះនឹងត្រូវបានលុប ប្រសិនបើកំណែរបស់វាដែលយើងបានផ្ទេរគឺស្មើនឹងកំណែដែលមានស្រាប់។

ប្រសិនបើយើងមិនចង់ពិនិត្យមើលកំណែនេះទេ យើងគ្រាន់តែឆ្លងកាត់អាគុយម៉ង់ "-1" ។

ទីបី វាពិនិត្យរកអត្ថិភាពនៃ znode មួយ។ ត្រឡប់ពិត ប្រសិនបើថ្នាំងមាន មិនពិត។

ហើយបន្ទាប់មកនាឡិកាទង់លេចឡើង ដែលអនុញ្ញាតឱ្យអ្នកត្រួតពិនិត្យថ្នាំងនេះ។

អ្នកអាចកំណត់ទង់នេះសូម្បីតែនៅលើថ្នាំងដែលមិនមាន ហើយទទួលបានការជូនដំណឹងនៅពេលវាលេចឡើង។ នេះក៏អាចមានប្រយោជន៍ផងដែរ។

បញ្ហាប្រឈមពីរបីទៀត។ ទទួលទិន្នន័យ. វាច្បាស់ណាស់ថាយើងអាចទទួលទិន្នន័យតាមរយៈ znode ។ អ្នកក៏អាចប្រើនាឡិកាទង់ជាតិផងដែរ។ ក្នុងករណីនេះវានឹងមិនដំឡើងទេប្រសិនបើគ្មានថ្នាំង។ ដូច្នេះអ្នកត្រូវយល់ថាវាមាន ហើយបន្ទាប់មកទទួលទិន្នន័យ។

ក៏មានដែរ។ កំណត់ទិន្នន័យ. នៅទីនេះយើងឆ្លងកាត់កំណែ។ ហើយប្រសិនបើយើងឆ្លងកាត់វា ទិន្នន័យនៅលើ znode នៃកំណែជាក់លាក់មួយនឹងត្រូវបានអាប់ដេត។

អ្នកក៏អាចបញ្ជាក់ "-1" ដើម្បីដកការត្រួតពិនិត្យនេះផងដែរ។

វិធីសាស្រ្តមានប្រយោជន៍មួយទៀតគឺ ទទួលបានកុមារ. យើងក៏អាចទទួលបានបញ្ជីនៃ znodes ទាំងអស់ដែលជាកម្មសិទ្ធិរបស់វាផងដែរ។ យើង​អាច​ត្រួត​ពិនិត្យ​វា​ដោយ​កំណត់​នាឡិកា​ទង់ជាតិ។

និងវិធីសាស្រ្ត ធ្វើសមកាលកម្ម អនុញ្ញាតឱ្យការផ្លាស់ប្តូរទាំងអស់ត្រូវបានផ្ញើក្នុងពេលតែមួយ ដោយហេតុនេះធានាថាពួកវាត្រូវបានរក្សាទុក ហើយទិន្នន័យទាំងអស់ត្រូវបានផ្លាស់ប្តូរទាំងស្រុង។

ប្រសិនបើយើងគូរភាពស្រដៀងគ្នាជាមួយនឹងការសរសេរកម្មវិធីធម្មតា នោះនៅពេលដែលអ្នកប្រើវិធីសាស្រ្តដូចជាសរសេរ ដែលសរសេរអ្វីមួយទៅឌីស ហើយបន្ទាប់ពីវាត្រឡប់ការឆ្លើយតបមកអ្នកវិញ វាមិនមានការធានាថាអ្នកបានសរសេរទិន្នន័យទៅឌីសនោះទេ។ ហើយសូម្បីតែនៅពេលដែលប្រព័ន្ធប្រតិបត្តិការមានទំនុកចិត្តថាអ្វីគ្រប់យ៉ាងត្រូវបានសរសេរក៏ដោយក៏មានយន្តការនៅក្នុងថាសខ្លួនវាដែលដំណើរការឆ្លងកាត់ស្រទាប់នៃសតិបណ្ដោះអាសន្នហើយមានតែបន្ទាប់ពីនោះទិន្នន័យត្រូវបានដាក់នៅលើថាស។

ភាគច្រើនប្រើការហៅអសមកាល។ នេះអនុញ្ញាតឱ្យអតិថិជនធ្វើការស្របគ្នាជាមួយនឹងសំណើផ្សេងៗ។ អ្នកអាចប្រើវិធីសាស្រ្តធ្វើសមកាលកម្មប៉ុន្តែវាមិនសូវមានផលិតភាពទេ។

ប្រតិបត្តិការពីរដែលយើងបាននិយាយគឺធ្វើបច្ចុប្បន្នភាព/សរសេរ ដែលផ្លាស់ប្តូរទិន្នន័យ។ ទាំងនេះគឺជា បង្កើត កំណត់ទិន្នន័យ ធ្វើសមកាលកម្ម លុប។ ហើយអានគឺមាន, getData, getChildren ។

ឥឡូវនេះឧទាហរណ៍មួយចំនួននៃរបៀបដែលអ្នកអាចបង្កើតបុព្វបទសម្រាប់ធ្វើការនៅក្នុងប្រព័ន្ធចែកចាយមួយ។ ឧទាហរណ៍ទាក់ទងទៅនឹងការកំណត់រចនាសម្ព័ន្ធនៃអ្វីមួយ។ កម្មករថ្មីបានបង្ហាញខ្លួន។ យើងបានបន្ថែមម៉ាស៊ីនហើយចាប់ផ្តើមដំណើរការ។ ហើយមានសំណួរបីដូចខាងក្រោម។ តើវាសួរ ZooKeeper ដើម្បីកំណត់រចនាសម្ព័ន្ធដោយរបៀបណា? ហើយ​ប្រសិន​បើ​យើង​ចង់​ផ្លាស់​ប្តូ​រ​ការ​កំណត់​រចនា​សម្ព័ន្ធ​តើ​យើង​ផ្លាស់​ប្តូ​រ​វា​ដោយ​របៀប​ណា​? ហើយ​បន្ទាប់​ពី​យើង​ផ្លាស់​ប្តូរ​វា​ហើយ តើ​កម្មករ​ទាំង​នោះ​យើង​ទទួល​បាន​យ៉ាង​ណា?

ZooKeeper ធ្វើឱ្យវាងាយស្រួល។ ឧទាហរណ៍មានមែកធាង znode របស់យើង។ មានថ្នាំងសម្រាប់កម្មវិធីរបស់យើងនៅទីនេះ យើងបង្កើតថ្នាំងបន្ថែមនៅក្នុងវាដែលមានទិន្នន័យពីការកំណត់រចនាសម្ព័ន្ធ។ ទាំងនេះអាចជាប៉ារ៉ាម៉ែត្រដាច់ដោយឡែក។ ដោយសារទំហំតូច ការកំណត់រចនាសម្ព័ន្ធជាធម្មតាតូចពេក ដូច្នេះវាពិតជាអាចទៅរួចក្នុងការរក្សាទុកវានៅទីនេះ។

អ្នកកំពុងប្រើវិធីសាស្ត្រ ទទួលទិន្នន័យ ដើម្បីទទួលបានការកំណត់រចនាសម្ព័ន្ធសម្រាប់កម្មករពីថ្នាំង។ កំណត់ទៅពិត។ ប្រសិនបើសម្រាប់ហេតុផលមួយចំនួនថ្នាំងនេះមិនមានទេ យើងនឹងត្រូវបានជូនដំណឹងអំពីវានៅពេលដែលវាលេចឡើង ឬនៅពេលដែលវាផ្លាស់ប្តូរ។ បើ​យើង​ចង់​ដឹង​ថា​មាន​អ្វី​មួយ​បាន​ផ្លាស់​ប្តូរ យើង​កំណត់​វា​ទៅ​ពិត។ ហើយប្រសិនបើទិន្នន័យនៅក្នុងថ្នាំងនេះផ្លាស់ប្តូរ យើងនឹងដឹងអំពីវា។

កំណត់ទិន្នន័យ. យើងកំណត់ទិន្នន័យ កំណត់ “-1” ពោលគឺយើងមិនពិនិត្យកំណែទេ យើងសន្មត់ថាយើងតែងតែមានការកំណត់រចនាសម្ព័ន្ធតែមួយ យើងមិនចាំបាច់រក្សាទុកការកំណត់ច្រើននោះទេ។ ប្រសិនបើអ្នកត្រូវការផ្ទុកច្រើន អ្នកនឹងត្រូវបន្ថែមកម្រិតមួយទៀត។ នៅទីនេះយើងជឿថាមានតែមួយ ដូច្នេះយើងធ្វើបច្ចុប្បន្នភាពតែកំណែចុងក្រោយបំផុត ដូច្នេះយើងមិនពិនិត្យមើលកំណែនោះទេ។ នៅពេលនេះ អតិថិជនទាំងអស់ដែលបានជាវពីមុនទទួលបានការជូនដំណឹងថាមានអ្វីមួយបានផ្លាស់ប្តូរនៅក្នុងថ្នាំងនេះ។ ហើយ​បន្ទាប់​ពី​ពួក​គេ​បាន​ទទួល​ហើយ គេ​ក៏​ត្រូវ​តែ​ស្នើ​សុំ​ទិន្នន័យ​ម្ដង​ទៀត។ ការ​ជូន​ដំណឹង​គឺ​ថា​ពួក​គេ​មិន​បាន​ទទួល​ទិន្នន័យ​ដោយ​ខ្លួន​វា​ទេ​គឺ​មាន​តែ​ការ​ជូន​ដំណឹង​នៃ​ការ​ផ្លាស់​ប្តូ​រ​។ បន្ទាប់ពីនេះពួកគេត្រូវតែស្នើសុំទិន្នន័យថ្មី។

ជម្រើសទីពីរសម្រាប់ការប្រើប្រាស់បឋមគឺ សមាជិកភាពក្រុម. យើង​មាន​កម្មវិធី​ចែក​ចាយ មាន​កម្មករ​ច្រើន ហើយ​យើង​ចង់​យល់​ថា​គេ​នៅ​នឹង​កន្លែង។ ដូច្នេះ ពួកគេត្រូវតែចុះឈ្មោះដោយខ្លួនឯងថាពួកគេធ្វើការនៅក្នុងពាក្យសុំរបស់យើង។ ហើយយើងក៏ចង់ស្វែងយល់ផងដែរ ទាំងពីដំណើរការ Master ឬកន្លែងផ្សេងទៀតអំពីកម្មករសកម្មទាំងអស់ដែលយើងមាននាពេលបច្ចុប្បន្ននេះ។

តើ​យើង​ធ្វើ​បែប​នេះ​ដោយ​របៀប​ណា? សម្រាប់កម្មវិធី យើងបង្កើតថ្នាំងកម្មករ ហើយបន្ថែមកម្រិតរងនៅទីនោះ ដោយប្រើវិធីសាស្ត្របង្កើត។ ខ្ញុំមានកំហុសនៅលើស្លាយ។ នៅទីនេះអ្នកត្រូវការ តគ្នា បញ្ជាក់ បន្ទាប់មកកម្មករទាំងអស់នឹងត្រូវបានបង្កើតម្តងមួយៗ។ ហើយកម្មវិធីដែលស្នើសុំទិន្នន័យទាំងអស់អំពីកូនរបស់ថ្នាំងនេះ ទទួលបានកម្មករសកម្មទាំងអស់ដែលមាន។

នេះគឺជាការអនុវត្តដ៏គួរឱ្យភ័យខ្លាចនៃរបៀបដែលវាអាចធ្វើបាននៅក្នុងកូដ Java ។ ចូរចាប់ផ្តើមពីចុងបញ្ចប់ជាមួយនឹងវិធីសាស្រ្តសំខាន់។ នេះជាថ្នាក់របស់យើង តោះបង្កើតវិធីសាស្រ្តរបស់វា។ ក្នុងនាមជាអាគុយម៉ង់ដំបូងដែលយើងប្រើម៉ាស៊ីន ដែលជាកន្លែងដែលយើងកំពុងភ្ជាប់ ពោលគឺយើងកំណត់វាជាអាគុយម៉ង់មួយ។ ហើយអាគុយម៉ង់ទីពីរគឺឈ្មោះក្រុម។

តើការតភ្ជាប់កើតឡើងយ៉ាងដូចម្តេច? នេះគឺជាឧទាហរណ៍សាមញ្ញនៃ API ដែលត្រូវបានប្រើ។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅទីនេះ។ មានថ្នាក់ស្តង់ដារ ZooKeeper ។ យើងបញ្ជូនម្ចាស់ផ្ទះទៅវា។ ហើយកំណត់ពេលវេលាអស់ឧទាហរណ៍ 5 វិនាទី។ ហើយយើងមានសមាជិកម្នាក់ហៅថា ConnectSignal សំខាន់យើងបង្កើតក្រុមតាមផ្លូវបញ្ជូន។ យើង​មិន​សរសេរ​ទិន្នន័យ​នៅ​ទី​នោះ​ទេ ទោះ​បី​ជា​អ្វី​មួយ​អាច​ត្រូវ​បាន​សរសេរ​ក៏​ដោយ។ ហើយថ្នាំងនៅទីនេះគឺជាប្រភេទជាប់លាប់។ សំខាន់នេះគឺជាថ្នាំងធម្មតាធម្មតាដែលនឹងមានគ្រប់ពេលវេលា។ នេះជាកន្លែងដែលវគ្គត្រូវបានបង្កើត។ នេះជាការអនុវត្តរបស់អតិថិជនខ្លួនឯង។ អតិថិជនរបស់យើងនឹងរាយការណ៍ជាទៀងទាត់ថាវគ្គនេះនៅរស់។ ហើយ​ពេល​យើង​បញ្ចប់​វគ្គ យើង​ហៅ​ថា​ជិត​ហើយ នោះ​វគ្គ​ក៏​ធ្លាក់។ នេះ​ជា​ករណី​ដែល​មាន​អ្វី​មួយ​ធ្លាក់​សម្រាប់​យើង ដូច្នេះ​ ZooKeeper ស្វែង​យល់​អំពី​វា ហើយ​កាត់​ផ្តាច់​វគ្គ។

តើធ្វើដូចម្តេចដើម្បីចាក់សោធនធាន? នៅទីនេះអ្វីគ្រប់យ៉ាងគឺស្មុគស្មាញបន្តិច។ យើង​មាន​សំណុំ​កម្មករ មាន​ធនធាន​មួយ​ចំនួន​ដែល​យើង​ចង់​ចាក់សោ។ ដើម្បីធ្វើដូចនេះយើងបង្កើតថ្នាំងដាច់ដោយឡែកឧទាហរណ៍ហៅថា lock1 ។ ប្រសិនបើយើងអាចបង្កើតវាបាន នោះយើងទទួលបានសោនៅទីនេះ។ ហើយប្រសិនបើយើងមិនអាចបង្កើតវាបានទេ នោះកម្មករព្យាយាមទាញយកទិន្នន័យពីទីនេះ ហើយចាប់តាំងពីថ្នាំងត្រូវបានបង្កើតរួចហើយ នោះយើងដាក់អ្នកឃ្លាំមើលនៅទីនេះ ហើយពេលដែលស្ថានភាពនៃថ្នាំងនេះផ្លាស់ប្តូរ យើងនឹងដឹងអំពីវា។ ហើយយើងអាចព្យាយាមមានពេលដើម្បីបង្កើតវាឡើងវិញ។ ប្រសិនបើយើងយកថ្នាំងនេះ យកសោនេះ បន្ទាប់មកបន្ទាប់ពីយើងលែងត្រូវការសោ យើងនឹងបោះបង់វាចោល ព្រោះថ្នាំងនេះមានតែនៅក្នុងវគ្គប៉ុណ្ណោះ។ ដូច្នោះហើយវានឹងបាត់ទៅវិញ។ ហើយម៉ាស៊ីនភ្ញៀវផ្សេងទៀត ក្នុងក្របខ័ណ្ឌនៃវគ្គមួយផ្សេងទៀត នឹងអាចចាក់សោរនៅលើថ្នាំងនេះ ឬផ្ទុយទៅវិញ គាត់នឹងទទួលបានការជូនដំណឹងថាមានអ្វីមួយបានផ្លាស់ប្តូរ ហើយគាត់អាចព្យាយាមធ្វើវាទាន់ពេល។

ឧទាហរណ៍មួយទៀតអំពីរបៀបដែលអ្នកអាចជ្រើសរើសអ្នកដឹកនាំសំខាន់។ នេះគឺស្មុគស្មាញបន្តិច ប៉ុន្តែក៏សាមញ្ញផងដែរ។ តើមានអ្វីកើតឡើងនៅទីនេះ? មានថ្នាំងសំខាន់ដែលប្រមូលផ្តុំកម្មករទាំងអស់។ យើងកំពុងព្យាយាមយកទិន្នន័យអំពីអ្នកដឹកនាំ។ ប្រសិនបើរឿងនេះកើតឡើងដោយជោគជ័យ ពោលគឺយើងបានទទួលទិន្នន័យមួយចំនួន នោះបុគ្គលិករបស់យើងចាប់ផ្តើមធ្វើតាមអ្នកដឹកនាំនេះ។ គាត់ជឿថាមានអ្នកដឹកនាំរួចហើយ។

ឧទាហរណ៍ បើអ្នកដឹកនាំស្លាប់ដោយសារមូលហេតុខ្លះ ធ្លាក់ចេញ យើងព្យាយាមបង្កើតអ្នកដឹកនាំថ្មី។ ហើយ​ប្រសិនបើ​យើង​ជោគជ័យ នោះ​អ្នកធ្វើការ​របស់​យើង​ក្លាយជា​អ្នកដឹកនាំ​។ ហើយប្រសិនបើនរណាម្នាក់នៅពេលនេះអាចបង្កើតអ្នកដឹកនាំថ្មីបាន នោះយើងព្យាយាមយល់ថាវាជានរណា ហើយធ្វើតាមគាត់។

ត្រង់នេះហៅថា ឥទ្ធិពលហ្វូងកើតឡើង ពោលគឺឥទ្ធិពលហ្វូង ព្រោះកាលណាអ្នកដឹកនាំស្លាប់ អ្នកណាមុនគេ នឹងក្លាយជាអ្នកដឹកនាំ។

នៅពេលចាប់យកធនធាន អ្នកអាចព្យាយាមប្រើវិធីសាស្រ្តខុសគ្នាបន្តិចបន្តួច ដែលមានដូចខាងក្រោម។ ឧទាហរណ៍ យើង​ចង់​បាន​សោ​មួយ ប៉ុន្តែ​មិន​មាន​ឥទ្ធិពល hert ។ វានឹងមាននៅក្នុងការពិតដែលថាកម្មវិធីរបស់យើងស្នើសុំបញ្ជីលេខសម្គាល់ថ្នាំងទាំងអស់សម្រាប់ថ្នាំងដែលមានស្រាប់ជាមួយនឹងសោ។ ហើយប្រសិនបើមុននោះថ្នាំងដែលយើងបានបង្កើតសោគឺតូចបំផុតនៃសំណុំដែលយើងបានទទួល នោះមានន័យថាយើងបានចាប់យកសោ។ យើងពិនិត្យមើលថាយើងបានទទួលសោ។ ជាការត្រួតពិនិត្យ នឹងមានលក្ខខណ្ឌមួយដែលលេខសម្គាល់ដែលយើងបានទទួលនៅពេលបង្កើតសោថ្មីគឺតិចតួចបំផុត។ ហើយ​ប្រសិន​បើ​យើង​ទទួល​បាន​ហើយ យើង​នឹង​ធ្វើ​ការ​បន្ថែម​ទៀត។

ប្រសិនបើមានលេខសម្គាល់ជាក់លាក់ដែលតូចជាងសោរបស់យើង នោះយើងដាក់អ្នកឃ្លាំមើលព្រឹត្តិការណ៍នេះ ហើយរង់ចាំការជូនដំណឹងរហូតដល់មានការផ្លាស់ប្តូរ។ នោះគឺយើងបានទទួលសោនេះ។ ហើយរហូតដល់វាធ្លាក់ចេញ យើងនឹងមិនក្លាយជាលេខសម្គាល់អប្បបរមា ហើយនឹងមិនទទួលបានសោអប្បបរមាទេ ដូច្នេះហើយយើងនឹងអាចចូលបាន។ ហើយប្រសិនបើលក្ខខណ្ឌនេះមិនត្រូវបានបំពេញ នោះយើងទៅទីនេះភ្លាមៗ ហើយព្យាយាមយកសោនេះម្តងទៀត ព្រោះថាមានអ្វីមួយបានផ្លាស់ប្តូរក្នុងអំឡុងពេលនេះ។

តើ ZooKeeper មានអ្វីខ្លះ? មាន ៤ យ៉ាង។ នេះគឺជាដំណើរការដំណើរការ - សំណើ។ ហើយក៏ ZooKeeper Atomic Broadcast ផងដែរ។ មាន Commit Log ដែលប្រតិបត្តិការទាំងអស់ត្រូវបានកត់ត្រា។ ហើយ In-memory Replicated DB ខ្លួនវា ពោលគឺ មូលដ្ឋានទិន្នន័យខ្លួនវា ដែលដើមឈើទាំងមូលនេះត្រូវបានរក្សាទុក។

គួរកត់សម្គាល់ថាប្រតិបត្តិការសរសេរទាំងអស់ឆ្លងកាត់ដំណើរការស្នើសុំ។ ហើយការអានប្រតិបត្តិការទៅកាន់មូលដ្ឋានទិន្នន័យក្នុងអង្គចងចាំដោយផ្ទាល់។

មូលដ្ឋានទិន្នន័យខ្លួនវាត្រូវបានចម្លងយ៉ាងពេញលេញ។ គ្រប់ករណីទាំងអស់របស់ ZooKeeper រក្សាទុកច្បាប់ចម្លងពេញលេញនៃទិន្នន័យ។

ដើម្បីស្តារមូលដ្ឋានទិន្នន័យឡើងវិញបន្ទាប់ពីគាំង មានកំណត់ហេតុ Commit ។ ការអនុវត្តស្តង់ដារគឺថា មុនពេលទិន្នន័យចូលទៅក្នុងអង្គចងចាំ វាត្រូវបានសរសេរនៅទីនោះ ដូច្នេះប្រសិនបើវាគាំង កំណត់ហេតុនេះអាចត្រូវបានចាក់ឡើងវិញ ហើយស្ថានភាពប្រព័ន្ធអាចត្រូវបានស្ដារឡើងវិញ។ ហើយការថតរូបតាមកាលកំណត់នៃមូលដ្ឋានទិន្នន័យក៏ត្រូវបានប្រើប្រាស់ផងដែរ។

ZooKeeper Atomic Broadcast គឺជាវត្ថុដែលត្រូវបានប្រើដើម្បីរក្សាទិន្នន័យចម្លង។

ZAB ជ្រើសរើសអ្នកដឹកនាំពីចំណុចនៃទិដ្ឋភាពនៃថ្នាំង ZooKeeper នៅខាងក្នុង។ ថ្នាំងផ្សេងទៀតក្លាយជាអ្នកដើរតាមរបស់នាង ហើយរំពឹងថានឹងមានសកម្មភាពមួយចំនួនពីនាង។ ប្រសិនបើពួកគេទទួលបានធាតុ ពួកគេបញ្ជូនពួកគេទាំងអស់ទៅអ្នកដឹកនាំ ដំបូងគាត់ធ្វើប្រតិបត្តិការសរសេរ ហើយបន្ទាប់មកផ្ញើសារអំពីអ្វីដែលបានផ្លាស់ប្តូរទៅកាន់អ្នកដើរតាមរបស់គាត់។ តាមពិត នេះត្រូវតែត្រូវបានអនុវត្តតាមលក្ខណៈអាតូម ពោលគឺប្រតិបត្តិការថត និងផ្សាយនៃរឿងទាំងមូលត្រូវតែអនុវត្តតាមអាតូម ដោយហេតុនេះធានានូវភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ។

វាដំណើរការតែការសរសេរសំណើប៉ុណ្ណោះ។ ភារកិច្ចចម្បងរបស់វាគឺថាវាបំប្លែងប្រតិបត្តិការទៅជាការធ្វើបច្ចុប្បន្នភាពប្រតិបត្តិការ។ នេះគឺជាសំណើដែលបានបង្កើតជាពិសេស។

ហើយនៅទីនេះវាគួរឱ្យកត់សម្គាល់ថាភាពគ្មានសមត្ថភាពនៃការធ្វើបច្ចុប្បន្នភាពសម្រាប់ប្រតិបត្តិការដូចគ្នាត្រូវបានធានា។ តើ​វា​ជា​អ្វី? រឿងនេះ​បើ​ប្រតិបត្តិ​ពីរដង​នឹង​មាន​សភាព​ដដែល ពោលគឺ​សំណើ​ខ្លួនឯង​នឹងមិន​ផ្លាស់ប្តូរ​ឡើយ​។ ហើយនេះត្រូវធ្វើដូច្នេះក្នុងករណីមានការគាំង អ្នកអាចចាប់ផ្តើមប្រតិបត្តិការឡើងវិញ ដោយហេតុនេះអាចរំកិលការផ្លាស់ប្តូរដែលបានធ្លាក់ចុះនៅពេលនេះមកវិញ។ ក្នុងករណីនេះ ស្ថានភាពនៃប្រព័ន្ធនឹងក្លាយទៅជាដូចគ្នា ពោលគឺវាមិនគួរជាករណីដែលស៊េរីដូចគ្នា ឧទាហរណ៍ ដំណើរការអាប់ដេត ដែលនាំទៅដល់ស្ថានភាពចុងក្រោយនៃប្រព័ន្ធផ្សេងៗគ្នា។

ប្រភព: www.habr.com