ការកសាងប្លុកនៃកម្មវិធីដែលបានចែកចាយ។ ការប៉ាន់ស្មានទីពីរ

សេចក្តីជូនដំណឹង

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

នេះគឺជាអត្ថបទចុងក្រោយនៅក្នុងស៊េរីស្តីពីកម្មវិធីប្រតិកម្មដែលបានចែកចាយនៅក្នុង Erlang/Elixir ។ IN អត្ថបទដំបូង អ្នកអាចរកឃើញមូលដ្ឋានគ្រឹះទ្រឹស្តីនៃស្ថាបត្យកម្មប្រតិកម្ម។ អត្ថបទទីពីរ បង្ហាញពីគំរូ និងយន្តការជាមូលដ្ឋានសម្រាប់ការសាងសង់ប្រព័ន្ធបែបនេះ។

ថ្ងៃនេះយើងនឹងលើកយកបញ្ហានៃការអភិវឌ្ឍន៍មូលដ្ឋានកូដ និងគម្រោងទូទៅ។

អង្គការនៃសេវាកម្ម

នៅក្នុងជីវិតពិត នៅពេលបង្កើតសេវាកម្មមួយ អ្នកត្រូវតែបញ្ចូលគ្នានូវគំរូអន្តរកម្មជាច្រើននៅក្នុងឧបករណ៍បញ្ជាមួយ។ ឧទាហរណ៍ សេវាកម្មអ្នកប្រើប្រាស់ ដែលដោះស្រាយបញ្ហានៃការគ្រប់គ្រងទម្រង់អ្នកប្រើប្រាស់គម្រោង ត្រូវតែឆ្លើយតបទៅនឹងសំណើ req-resp និងរាយការណ៍អំពីបច្ចុប្បន្នភាពទម្រង់តាមរយៈ pub-sub ។ ករណីនេះគឺសាមញ្ញណាស់៖ នៅពីក្រោយការផ្ញើសារ មានឧបករណ៍បញ្ជាមួយដែលអនុវត្តតក្កវិជ្ជាសេវាកម្ម និងបោះពុម្ពផ្សាយបច្ចុប្បន្នភាព។

ស្ថានភាពកាន់តែស្មុគស្មាញ នៅពេលដែលយើងត្រូវអនុវត្តសេវាកម្មចែកចាយដែលអត់ឱនចំពោះកំហុស។ ចូរយើងស្រមៃថាតម្រូវការសម្រាប់អ្នកប្រើប្រាស់បានផ្លាស់ប្តូរ៖

1. ឥឡូវនេះសេវាគួរតែដំណើរការសំណើនៅលើ 5 node cluster,
2. អាចអនុវត្តការងារដំណើរការផ្ទៃខាងក្រោយ,
3. ហើយក៏អាចគ្រប់គ្រងបញ្ជីជាវជាប្រចាំសម្រាប់ការអាប់ដេតទម្រង់ផងដែរ។

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

ការពិពណ៌នាជាផ្លូវការនៃសេវាកម្មអ្នកប្រើប្រាស់កាន់តែស្មុគស្មាញ។ តាមទស្សនៈរបស់អ្នកសរសេរកម្មវិធី ការផ្លាស់ប្តូរមានតិចតួចដោយសារការប្រើប្រាស់សារ។ ដើម្បីបំពេញតំរូវការដំបូង យើងត្រូវកំណត់រចនាសម្ព័ន្ធសមតុល្យនៅចំណុចផ្លាស់ប្តូរ req-resp ។

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

ចំណុចទី 3 ទាមទារផ្នែកបន្ថែមទម្រង់ pub-sub ។ ហើយសម្រាប់ការអនុវត្ត បន្ទាប់ពីបង្កើតចំណុចផ្លាស់ប្តូរ pub-sub យើងត្រូវបើកដំណើរការឧបករណ៍បញ្ជាចំណុចនេះបន្ថែមនៅក្នុងសេវាកម្មរបស់យើង។ ដូច្នេះ វាដូចជាយើងកំពុងផ្លាស់ប្តូរតក្កវិជ្ជាសម្រាប់ដំណើរការការជាវ និងការឈប់ជាវពីស្រទាប់ផ្ញើសារទៅក្នុងការអនុវត្តរបស់អ្នកប្រើប្រាស់។

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

ការជ្រើសរើសអ្នកដឹកនាំ

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

នៅក្នុងប្រព័ន្ធដែលមិនងាយនឹងធ្វើមជ្ឈិមនិយម ក្បួនដោះស្រាយដែលមានមូលដ្ឋានលើការយល់ស្រប និងសកល ដូចជា paxos ឬ raft ត្រូវបានប្រើ។
ដោយសារការផ្ញើសារគឺជាឈ្មួញកណ្តាល និងជាធាតុកណ្តាល វាដឹងអំពីអ្នកត្រួតពិនិត្យសេវាកម្មទាំងអស់ - អ្នកដឹកនាំបេក្ខជន។ ការផ្ញើសារអាចតែងតាំងអ្នកដឹកនាំដោយមិនចាំបាច់បោះឆ្នោត។

បន្ទាប់ពីចាប់ផ្តើម និងភ្ជាប់ទៅចំណុចផ្លាស់ប្តូរ សេវាកម្មទាំងអស់ទទួលបានសារប្រព័ន្ធ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ប្រសិនបើ LeaderPid ស្របពេលជាមួយ pid ដំណើរការបច្ចុប្បន្ន វាត្រូវបានតែងតាំងជាអ្នកដឹកនាំ និងបញ្ជី Servers រួមបញ្ចូលថ្នាំងទាំងអស់ និងប៉ារ៉ាម៉ែត្ររបស់វា។
នៅពេលមួយថ្មីលេចឡើង ហើយថ្នាំងចង្កោមដំណើរការត្រូវបានផ្តាច់ ឧបករណ៍បញ្ជាសេវាកម្មទាំងអស់ទទួលបាន #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} រៀងគ្នា។

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

អ្នកសំរបសំរួល

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

ឧទាហរណ៍បុរាណនៃការបង្កើនប្រសិទ្ធភាព pub-sub គឺជាកម្មវិធីចែកចាយដែលមានស្នូលអាជីវកម្មដែលបង្កើតព្រឹត្តិការណ៍អាប់ដេត ដូចជាការផ្លាស់ប្តូរតម្លៃនៅក្នុងទីផ្សារ និងស្រទាប់ចូលប្រើ - N servers ដែលផ្តល់ websocket API សម្រាប់ web clients។
ប្រសិនបើអ្នកសម្រេចចិត្តបន្ត នោះសេវាកម្មអតិថិជនមើលទៅដូចនេះ៖

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

សូមស្រមៃថាយើងមានអ្នកជាវ 50000 នាក់ចំពោះប្រធានបទ "ព័ត៌មាន" ។ អ្នកជាវត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំង 5 ម៉ាស៊ីនមេ។ ជាលទ្ធផល ការអាប់ដេតនីមួយៗដែលមកដល់ចំណុចប្តូរប្រាក់នឹងត្រូវបានចម្លង 50000 ដង: 10000 ដងនៅលើម៉ាស៊ីនមេនីមួយៗ យោងទៅតាមចំនួនអតិថិជននៅលើវា។ មិនមែនជាគ្រោងការណ៍ដ៏មានប្រសិទ្ធភាពទេមែនទេ?
ដើម្បីធ្វើឲ្យស្ថានភាពប្រសើរឡើង សូមណែនាំប្រូកស៊ីដែលមានឈ្មោះដូចគ្នានឹងចំណុចប្តូរប្រាក់។ អ្នកចុះបញ្ជីឈ្មោះសកលត្រូវតែអាចត្រឡប់ដំណើរការជិតបំផុតតាមឈ្មោះ នេះមានសារៈសំខាន់។

សូមបើកដំណើរការប្រូកស៊ីនេះនៅលើម៉ាស៊ីនមេស្រទាប់ចូលដំណើរការ ហើយដំណើរការរបស់យើងទាំងអស់ដែលបម្រើ websocket api នឹងជាវវា ហើយមិនមែនទៅចំណុចផ្លាស់ប្តូរ pub-sub ដើមនៅក្នុងខឺណែលនោះទេ។ ប្រូកស៊ីជាវស្នូលតែនៅក្នុងករណីនៃការជាវតែមួយគត់ និងចម្លងសារចូលទៅកាន់អតិថិជនទាំងអស់របស់វា។
ជាលទ្ធផល សារចំនួន 5 នឹងត្រូវបានផ្ញើរវាងខឺណែល និងម៉ាស៊ីនមេ ជំនួសឱ្យ 50000។

ការតំរង់ទិស និងតុល្យភាព

Req-Resp

នៅក្នុងការអនុវត្តការផ្ញើសារបច្ចុប្បន្ន មានយុទ្ធសាស្ត្រចែកចាយសំណើចំនួន 7៖

• default. សំណើត្រូវបានផ្ញើទៅឧបករណ៍បញ្ជាទាំងអស់។
• round-robin. សំណើត្រូវបានរាប់បញ្ចូល និងចែកចាយជារង្វង់រវាងឧបករណ៍បញ្ជា។
• consensus. ឧបករណ៍បញ្ជាដែលបម្រើសេវាកម្មត្រូវបានបែងចែកទៅជាអ្នកដឹកនាំនិងទាសករ។ សំណើត្រូវបានផ្ញើទៅអ្នកដឹកនាំតែប៉ុណ្ណោះ។
• consensus & round-robin. ក្រុមនេះមានអ្នកដឹកនាំ ប៉ុន្តែសំណើត្រូវបានចែកចាយក្នុងចំណោមសមាជិកទាំងអស់។
• sticky. មុខងារ hash ត្រូវ​បាន​គណនា និង​ផ្តល់​ឱ្យ​អ្នក​ដោះស្រាយ​ជាក់លាក់។ សំណើជាបន្តបន្ទាប់ដែលមានហត្ថលេខានេះទៅកាន់អ្នកដោះស្រាយដូចគ្នា។
• sticky-fun. នៅពេលចាប់ផ្តើមចំណុចផ្លាស់ប្តូរ មុខងារគណនាសញ្ញាសម្រាប់ sticky តុល្យភាព។
• fun. ស្រដៀង​នឹង​ភាព​សប្បាយ​រីករាយ មាន​តែ​អ្នក​បន្ថែម​ទៀត​អាច​ប្ដូរ​ទិស បដិសេធ ឬ​ដំណើរការ​វា​ជា​មុន​បាន។

យុទ្ធសាស្ត្រចែកចាយត្រូវបានកំណត់នៅពេលដែលចំណុចផ្លាស់ប្តូរត្រូវបានចាប់ផ្តើម។

បន្ថែមពីលើតុល្យភាព ការផ្ញើសារអនុញ្ញាតឱ្យអ្នកដាក់ស្លាកអង្គភាព។ តោះមើលប្រភេទស្លាកក្នុងប្រព័ន្ធ៖

• ស្លាកការតភ្ជាប់។ អនុញ្ញាតឱ្យអ្នកយល់តាមរយៈការតភ្ជាប់ដែលព្រឹត្តិការណ៍បានមក។ ប្រើនៅពេលដែលដំណើរការរបស់ឧបករណ៍បញ្ជាភ្ជាប់ទៅចំណុចផ្លាស់ប្តូរដូចគ្នា ប៉ុន្តែជាមួយនឹងគ្រាប់ចុចផ្លូវផ្សេងគ្នា។
• ស្លាកសេវាកម្ម។ អនុញ្ញាតឱ្យអ្នកបញ្ចូលគ្នានូវឧបករណ៍ដោះស្រាយទៅជាក្រុមសម្រាប់សេវាកម្មមួយ និងពង្រីកសមត្ថភាពផ្លូវ និងតុល្យភាព។ សម្រាប់លំនាំ req-resp ការកំណត់ផ្លូវគឺលីនេអ៊ែរ។ យើងផ្ញើសំណើទៅចំណុចប្តូរប្រាក់ បន្ទាប់មកវាបញ្ជូនវាទៅសេវាកម្ម។ ប៉ុន្តែប្រសិនបើយើងត្រូវការបំបែកអ្នកដោះស្រាយទៅជាក្រុមឡូជីខល នោះការបំបែកត្រូវបានធ្វើដោយប្រើស្លាក។ នៅពេលបញ្ជាក់ស្លាក សំណើនឹងត្រូវបានផ្ញើទៅក្រុមជាក់លាក់មួយនៃឧបករណ៍បញ្ជា។
• ស្នើសុំស្លាក។ អនុញ្ញាតឱ្យអ្នកបែងចែករវាងចម្លើយ។ ដោយសារប្រព័ន្ធរបស់យើងមានភាពអសមកាល ដើម្បីដំណើរការការឆ្លើយតបសេវាកម្ម យើងត្រូវអាចបញ្ជាក់ RequestTag នៅពេលផ្ញើសំណើ។ ពីវាយើងនឹងអាចយល់ពីចម្លើយចំពោះសំណើណាមួយដែលបានមករកយើង។

Pub-sub

សម្រាប់ pub-sub អ្វីគ្រប់យ៉ាងគឺសាមញ្ញជាងបន្តិច។ យើង​មាន​ចំណុច​ផ្លាស់ប្តូរ​មួយ​ដែល​សារ​ត្រូវ​បាន​គេ​បោះផ្សាយ។ ចំណុចផ្លាស់ប្តូរចែកចាយសារក្នុងចំណោមអតិថិជនដែលបានជាវ routing keys ដែលពួកគេត្រូវការ (យើងអាចនិយាយបានថាវាស្រដៀងទៅនឹងប្រធានបទ)។

មាត្រដ្ឋាន និងភាពអត់ធ្មត់នៃកំហុស

ការធ្វើមាត្រដ្ឋាននៃប្រព័ន្ធទាំងមូលគឺអាស្រ័យលើកម្រិតនៃការធ្វើមាត្រដ្ឋាននៃស្រទាប់ និងធាតុផ្សំនៃប្រព័ន្ធ៖

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

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

ការកក់ទុក

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

នៅក្នុងគម្រោងរបស់ខ្ញុំ ខ្ញុំប្រើថ្នាំងបន្ថែមដែលយកបន្ទុកក្នុងករណីមានការធ្លាក់ចុះ។ Erlang មានការអនុវត្តរបៀបចែកចាយស្តង់ដារសម្រាប់កម្មវិធី OTP ។ របៀបចែកចាយអនុវត្តការងើបឡើងវិញក្នុងករណីបរាជ័យដោយការបើកដំណើរការកម្មវិធីដែលបរាជ័យនៅលើថ្នាំងដែលបានបើកដំណើរការពីមុនមួយទៀត។ ដំណើរការនេះមានតម្លាភាព បន្ទាប់ពីបរាជ័យ កម្មវិធីនឹងផ្លាស់ទីដោយស្វ័យប្រវត្តិទៅថ្នាំងដែលបរាជ័យ។ អ្នកអាចអានបន្ថែមអំពីមុខងារនេះ។ នៅទីនេះ.

ផលិតភាព

សូមព្យាយាមយ៉ាងហោចណាស់ប្រៀបធៀបដំណើរការរបស់ rabbitmq និងការផ្ញើសារផ្ទាល់ខ្លួនរបស់យើង។
ខ្ញុំ​បាន​រក​ឃើញ លទ្ធផលផ្លូវការ ការធ្វើតេស្ត rabbitmq ពីក្រុម openstack ។

នៅក្នុងកថាខណ្ឌ 6.14.1.2.1.2.2 ។ ឯកសារដើមបង្ហាញពីលទ្ធផលនៃ RPC CAST៖

យើងនឹងមិនធ្វើការកំណត់បន្ថែមទៅលើខឺណែល OS ឬ erlang VM ជាមុនទេ។ លក្ខខណ្ឌសម្រាប់ការធ្វើតេស្ត៖

• erl opts: +A1 +sbtu ។
• ការធ្វើតេស្តនៅក្នុងថ្នាំង erlang តែមួយគឺដំណើរការលើកុំព្យូទ័រយួរដៃដែលមាន i7 ចាស់នៅក្នុងកំណែចល័ត។
• ការធ្វើតេស្តចង្កោមត្រូវបានអនុវត្តនៅលើម៉ាស៊ីនមេដែលមានបណ្តាញ 10G ។
• កូដដំណើរការនៅក្នុងធុង docker ។ បណ្តាញនៅក្នុងរបៀប NAT ។

លេខកូដសាកល្បង៖

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

សេណារីយ៉ូ ២៖ ការធ្វើតេស្តនេះត្រូវបានដំណើរការលើកុំព្យូទ័រយួរដៃដែលមានកំណែចល័ត i7 ចាស់។ ការធ្វើតេស្ត ការផ្ញើសារ និងសេវាកម្មត្រូវបានប្រតិបត្តិលើថ្នាំងមួយក្នុងធុង Docker មួយ៖

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

សេណារីយ៉ូ ១៖ ថ្នាំង 3 ដែលដំណើរការលើម៉ាស៊ីនផ្សេងគ្នានៅក្រោម docker (NAT)។

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

ក្នុងគ្រប់ករណីទាំងអស់ ការប្រើប្រាស់ CPU មិនលើសពី 250%

លទ្ធផល

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

រូបថត @chuttersnap

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើប្រធានបទអ្វីខ្លះដែលខ្ញុំគួររៀបរាប់លម្អិតបន្ថែមទៀតជាផ្នែកនៃស៊េរី VTrade Experiment?

• ទ្រឹស្តី៖ ទីផ្សារ ការបញ្ជាទិញ និងពេលវេលារបស់ពួកគេ៖ DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• សៀវភៅបញ្ជា។ ទ្រឹស្ដី និងការអនុវត្តសៀវភៅដោយដាក់ជាក្រុម

• ការមើលឃើញនៃការជួញដូរ: ធីក, របារ, ដំណោះស្រាយ។ របៀបរក្សាទុកនិងរបៀបកាវបិទ

• ការិយាល័យខាងក្រោយ។ ការធ្វើផែនការ និងការអភិវឌ្ឍន៍។ ការត្រួតពិនិត្យបុគ្គលិក និងការស៊ើបអង្កេតឧប្បត្តិហេតុ

• API ចូរយើងស្វែងយល់ថាតើចំណុចប្រទាក់អ្វីខ្លះដែលត្រូវការ និងរបៀបអនុវត្តពួកវា

• ការផ្ទុកព័ត៌មាន៖ PostgreSQL, Timescale, Tarantool នៅក្នុងប្រព័ន្ធពាណិជ្ជកម្ម

• ប្រតិកម្មនៅក្នុងប្រព័ន្ធជួញដូរ

• ផ្សេងទៀត។ ខ្ញុំនឹងសរសេរនៅក្នុងមតិយោបល់

អ្នកប្រើប្រាស់ 6 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ៦៣ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com