Bioyino - ចែកចាយ និងពង្រីកមាត្រដ្ឋានសរុប

ដូច្នេះអ្នកប្រមូលម៉ែត្រ។ ដូចយើងដែរ។ យើងក៏ប្រមូលរង្វាស់ផងដែរ។ ជាការពិតណាស់ចាំបាច់សម្រាប់អាជីវកម្ម។ ថ្ងៃនេះយើងនឹងនិយាយអំពីតំណភ្ជាប់ដំបូងនៃប្រព័ន្ធត្រួតពិនិត្យរបស់យើង - ម៉ាស៊ីនមេសរុបដែលឆបគ្នាជាមួយ statsd ប៊ីយ៉ូណូហេតុអ្វីបានជាយើងសរសេរវា ហើយហេតុអ្វីបានជាយើងបោះបង់ចោល brubeck ។

ពីអត្ថបទមុនរបស់យើង (1, 2) អ្នក​អាច​ដឹង​ថា​រហូត​ដល់​ពេល​ខ្លះ​យើង​ប្រមូល​សញ្ញា​ដោយ​ប្រើ ប្រ៊ូប៊េក. វាត្រូវបានសរសេរជា C. តាមទស្សនៈនៃកូដ វាសាមញ្ញដូចជាដោត (វាសំខាន់នៅពេលអ្នកចង់រួមចំណែក) ហើយសំខាន់បំផុត វាគ្រប់គ្រងបរិមាណរបស់យើង 2 លានម៉ែត្រក្នុងមួយវិនាទី (MPS) នៅកម្រិតកំពូល។ ដោយគ្មានបញ្ហា។ ឯកសារនេះបញ្ជាក់ថា ការគាំទ្រសម្រាប់ 4 លាន MPS ជាមួយនឹងសញ្ញាផ្កាយ។ នេះមានន័យថា អ្នកនឹងទទួលបានតួលេខដែលបានបញ្ជាក់ ប្រសិនបើអ្នកកំណត់រចនាសម្ព័ន្ធបណ្តាញបានត្រឹមត្រូវនៅលើលីនុច។ (យើងមិនដឹងថាតើអ្នកទទួលបាន MPS ប៉ុន្មានទេ ប្រសិនបើអ្នកចាកចេញពីបណ្តាញដូចដែលនៅមាន) ទោះបីជាមានគុណសម្បត្តិទាំងនេះក៏ដោយ យើងមានពាក្យបណ្តឹងធ្ងន់ធ្ងរជាច្រើនអំពី brubeck ។

ទាមទារ ១. Github ដែលជាអ្នកអភិវឌ្ឍន៍គម្រោងនេះ បានឈប់គាំទ្រវា៖ ការបោះពុម្ពបំណះ និងការជួសជុល ការទទួលយករបស់យើង និង (មិនត្រឹមតែរបស់យើងទេ) PR ។ ក្នុងរយៈពេលប៉ុន្មានខែចុងក្រោយនេះ (កន្លែងណាមួយចាប់ពីខែកុម្ភៈ ដល់ខែមីនា ឆ្នាំ 2018) សកម្មភាពបានបន្ត ប៉ុន្តែមុននោះមានរយៈពេលជិត 2 ឆ្នាំនៃការស្ងប់ស្ងាត់ទាំងស្រុង។ លើសពីនេះ គម្រោងនេះកំពុងត្រូវបានអភិវឌ្ឍ សម្រាប់តម្រូវការខាងក្នុងរបស់ Gihubដែលអាចក្លាយជាឧបសគ្គដ៏ធ្ងន់ធ្ងរដល់ការបញ្ចូលមុខងារថ្មីៗ។

ទាមទារ ១. ភាពត្រឹមត្រូវនៃការគណនា។ Brubeck ប្រមូលតម្លៃសរុបចំនួន 65536 សម្រាប់ការប្រមូលផ្តុំ។ ក្នុងករណីរបស់យើង សម្រាប់រង្វាស់មួយចំនួន ក្នុងអំឡុងពេលសរុប (30 វិនាទី) តម្លៃកាន់តែច្រើនអាចនឹងមកដល់ (1 នៅកម្រិតកំពូល)។ ជាលទ្ធផលនៃសំណាកគំរូនេះ តម្លៃអតិបរមា និងអប្បបរមាហាក់ដូចជាគ្មានប្រយោជន៍។ ឧទាហរណ៍ដូចនេះ៖

ដូចដែលវាគឺ

របៀបដែលវាគួរតែមាន

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

ហើយទីបំផុត ទាមទារ X. នៅពេលសរសេរ យើងត្រៀមបង្ហាញវាដល់ការអនុវត្តស្ថិតិការងារចំនួន 14 ឬតិចជាងនេះ ដែលយើងអាចរកបាន។ ចូរយើងស្រមៃថាហេដ្ឋារចនាសម្ព័ន្ធតែមួយបានរីកចម្រើនយ៉ាងខ្លាំងដែលការទទួលយក MPS 4 លានគឺមិនគ្រប់គ្រាន់ទៀតទេ។ ឬទោះបីជាវាមិនទាន់រីកចម្រើនក៏ដោយ ប៉ុន្តែការវាស់វែងមានសារៈសំខាន់សម្រាប់អ្នករួចទៅហើយ ដែលសូម្បីតែរយៈពេលខ្លី 2-3 នាទីនៅក្នុងតារាងអាចក្លាយជាការរិះគន់រួចទៅហើយ និងបណ្តាលឱ្យមានការបាក់ទឹកចិត្តដែលមិនអាចគ្រប់គ្រងបានក្នុងចំណោមអ្នកគ្រប់គ្រង។ ដោយសារ​ការ​ព្យាបាល​ជំងឺ​ធ្លាក់​ទឹកចិត្ត​ជា​កិច្ចការ​ដែល​គ្មាន​ការ​អរគុណ ដំណោះស្រាយ​បច្ចេកទេស​គឺ​ជា​ចាំបាច់។

ទីមួយ ការអត់ឱនចំពោះកំហុស ដូច្នេះបញ្ហាភ្លាមៗនៅលើម៉ាស៊ីនមេមិនបណ្តាលឱ្យ apocalypse zombie វិកលចរិតនៅក្នុងការិយាល័យនោះទេ។ ទីពីរ ការធ្វើមាត្រដ្ឋានដើម្បីអាចទទួលយកបានច្រើនជាង 4 លាន MPS ដោយមិនចាំបាច់ជីកជ្រៅទៅក្នុងជង់បណ្តាញលីនុច និងរីកលូតលាស់ដោយស្ងប់ស្ងាត់ "នៅក្នុងទទឹង" ទៅនឹងទំហំដែលត្រូវការ។

ដោយសារយើងមានកន្លែងសម្រាប់ធ្វើមាត្រដ្ឋាន យើងបានសម្រេចចិត្តចាប់ផ្តើមដោយការអត់ឱនចំពោះកំហុស។ "អំពី! អធ្យាស្រ័យកំហុស! វាសាមញ្ញ យើងអាចធ្វើវាបាន” យើងបានគិត និងបើកដំណើរការម៉ាស៊ីនមេចំនួន 2 ដោយលើកយកច្បាប់ចម្លងនៃ brubeck លើនីមួយៗ។ ដើម្បីធ្វើដូច្នេះ យើងត្រូវចម្លងចរាចរជាមួយម៉ែត្រទៅម៉ាស៊ីនមេទាំងពីរ ហើយថែមទាំងសរសេរសម្រាប់រឿងនេះទៀតផង។ ឧបករណ៍ប្រើប្រាស់តូច. យើងបានដោះស្រាយបញ្ហានៃការអត់ឱនកំហុសជាមួយនឹងបញ្ហានេះ ប៉ុន្តែ... មិនល្អទេ។ ដំបូងអ្វីគ្រប់យ៉ាងហាក់ដូចជាអស្ចារ្យ: brubeck នីមួយៗប្រមូលកំណែផ្ទាល់ខ្លួននៃការប្រមូលផ្តុំសរសេរទិន្នន័យទៅ Graphite ម្តងរៀងរាល់ 30 វិនាទីដោយសរសេរជាន់លើចន្លោះពេលចាស់ (វាត្រូវបានធ្វើនៅផ្នែក Graphite) ។ ប្រសិនបើម៉ាស៊ីនមេមួយបរាជ័យភ្លាមៗ នោះយើងតែងតែមានម៉ាស៊ីនទីពីរជាមួយនឹងច្បាប់ចម្លងនៃទិន្នន័យសរុបរបស់វាផ្ទាល់។ ប៉ុន្តែនេះគឺជាបញ្ហា៖ ប្រសិនបើម៉ាស៊ីនមេបរាជ័យ "ឃើញ" លេចឡើងនៅលើក្រាហ្វ។ នេះគឺដោយសារតែការពិតដែលថាចន្លោះពេល 30 វិនាទីរបស់ brubeck មិនត្រូវបានធ្វើសមកាលកម្មទេ ហើយនៅពេលនៃការគាំងមួយក្នុងចំណោមពួកគេមិនត្រូវបានសរសេរជាន់ពីលើនោះទេ។ នៅពេលដែលម៉ាស៊ីនមេទីពីរចាប់ផ្តើម រឿងដដែលនេះកើតឡើង។ អត់​ទ្រាំ​ទេ តែ​ចង់​បាន​ល្អ​ជាង! បញ្ហានៃការធ្វើមាត្រដ្ឋានក៏មិនបាត់ទៅដែរ។ ម៉ែត្រទាំងអស់នៅតែ "ហោះហើរ" ទៅម៉ាស៊ីនមេតែមួយ ដូច្នេះហើយយើងត្រូវបានកំណត់ត្រឹម 2-4 លាន MPS ដូចគ្នា អាស្រ័យលើកម្រិតបណ្តាញ។

ប្រសិនបើអ្នកគិតបន្តិចអំពីបញ្ហា ហើយក្នុងពេលតែមួយជីកព្រិលដោយប្រើប៉ែល នោះគំនិតជាក់ស្តែងខាងក្រោមអាចនឹងគិតដល់៖ អ្នកត្រូវការស្ថិតិដែលអាចដំណើរការក្នុងរបៀបចែកចាយ។ នោះគឺមួយដែលអនុវត្តការធ្វើសមកាលកម្មរវាងថ្នាំងនៅក្នុងពេលវេលានិងម៉ែត្រ។ "ពិតណាស់ ដំណោះស្រាយបែបនេះប្រហែលជាមានរួចហើយ" យើងបាននិយាយហើយទៅកាន់ Google... ហើយពួកគេមិនបានរកឃើញអ្វីសោះ។ បន្ទាប់ពីឆ្លងកាត់ឯកសារសម្រាប់ statsd ផ្សេងៗគ្នា (https://github.com/etsy/statsd/wiki#server-implementations គិតត្រឹមថ្ងៃទី 11.12.2017 ខែធ្នូ ឆ្នាំ XNUMX) យើងរកមិនឃើញអ្វីទាំងអស់។ ជាក់ស្តែង ទាំងអ្នកអភិវឌ្ឍន៍ ឬអ្នកប្រើប្រាស់ដំណោះស្រាយទាំងនេះ មិនទាន់បានជួបប្រទះនឹងការវាស់វែងជាច្រើននៅឡើយ បើមិនដូច្នេះទេ ពួកគេប្រាកដជានឹងមកជាមួយអ្វីមួយ។

ហើយបន្ទាប់មកយើងបានចងចាំអំពី "toy" statsd - bioyino ដែលត្រូវបានសរសេរនៅក្នុងកម្មវិធី Just for Fun hackathon (ឈ្មោះនៃគម្រោងនេះត្រូវបានបង្កើតឡើងដោយស្គ្រីបមុនពេលចាប់ផ្តើម hackathon) ហើយដឹងថាយើងត្រូវការជាបន្ទាន់នូវស្ថិតិផ្ទាល់ខ្លួនរបស់យើង។ ដើម្បីអ្វី?

• ដោយសារតែមានក្លូន statsd តិចពេកនៅក្នុងពិភពលោក
• ព្រោះវាអាចធ្វើទៅបានដើម្បីផ្តល់នូវការអត់ធ្មត់ និងលទ្ធភាពនៃកំហុសដែលចង់បាន (រួមទាំងការធ្វើសមកាលកម្មម៉ែត្រសរុបរវាងម៉ាស៊ីនមេ និងការដោះស្រាយបញ្ហានៃការបញ្ជូនការប៉ះទង្គិច)
• ដោយសារតែវាអាចគណនាម៉ែត្របានត្រឹមត្រូវជាង brubeck ធ្វើ
• ដោយសារតែអ្នកអាចប្រមូលស្ថិតិលម្អិតបន្ថែមទៀតដោយខ្លួនឯងដែល brubeck អនុវត្តមិនបានផ្តល់ឱ្យយើង,
• ដោយសារតែខ្ញុំមានឱកាសរៀបចំកម្មវិធីមន្ទីរពិសោធន៍ខ្នាតធំដែលបានចែកចាយដែលមានប្រសិទ្ធភាពខ្ពស់ផ្ទាល់ខ្លួនរបស់ខ្ញុំ ដែលនឹងមិនធ្វើឡើងវិញទាំងស្រុងនូវស្ថាបត្យកម្មនៃ hyperfor ស្រដៀងគ្នាផ្សេងទៀត... នោះហើយជាវា។

តើត្រូវសរសេរលើអ្វី? ជាការពិតណាស់នៅក្នុង Rust ។ ហេតុអ្វី?

• ដោយសារតែមានដំណោះស្រាយគំរូរួចហើយ
• ដោយសារតែអ្នកនិពន្ធអត្ថបទបានស្គាល់ Rust នៅពេលនោះរួចហើយ ហើយមានបំណងចង់សរសេរអ្វីមួយនៅក្នុងវាសម្រាប់ផលិត ដោយមានឱកាសដាក់វានៅក្នុងប្រភពបើកចំហ។
• ដោយសារតែភាសាជាមួយ GC មិនស័ក្តិសមសម្រាប់យើង ដោយសារធម្មជាតិនៃចរាចរណ៍ដែលទទួលបាន (ស្ទើរតែពេលវេលាពិត) និងការផ្អាក GC មិនអាចទទួលយកបាន
• ដោយសារតែអ្នកត្រូវការដំណើរការអតិបរមាដែលអាចប្រៀបធៀបទៅនឹង C
• ដោយសារតែ Rust ផ្តល់ឱ្យយើងនូវភាពស្របគ្នាដែលមិនមានការភ័យខ្លាច ហើយប្រសិនបើយើងចាប់ផ្តើមសរសេរវានៅក្នុង C/C++ នោះ យើងនឹងទទួលបាននូវភាពងាយរងគ្រោះកាន់តែច្រើន ភាពលើសចំណុះ លក្ខខណ្ឌប្រណាំង និងពាក្យដែលគួរឱ្យខ្លាចផ្សេងទៀតជាង brubeck ។

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

ពេលវេលាកន្លងផុតទៅ...

ទីបំផុត បន្ទាប់ពីការព្យាយាមបរាជ័យជាច្រើនលើក កំណែការងារដំបូងគឺរួចរាល់។ តើមានអ្វីកើតឡើង? នេះជាអ្វីដែលបានកើតឡើង។

ថ្នាំងនីមួយៗទទួលបានសំណុំរង្វាស់ផ្ទាល់ខ្លួនរបស់វា និងប្រមូលផ្តុំពួកវា ហើយមិនប្រមូលផ្តុំម៉ែត្រសម្រាប់ប្រភេទទាំងនោះដែលសំណុំពេញលេញរបស់ពួកគេត្រូវបានទាមទារសម្រាប់ការសរុបចុងក្រោយ។ ថ្នាំងត្រូវបានភ្ជាប់ទៅគ្នាទៅវិញទៅមកដោយប្រភេទនៃពិធីការចាក់សោដែលបានចែកចាយមួយចំនួនដែលអនុញ្ញាតឱ្យអ្នកជ្រើសរើសក្នុងចំណោមពួកវាតែមួយគត់ (នៅទីនេះយើងយំ) ដែលសក្តិសមក្នុងការផ្ញើម៉ែត្រទៅមហាមួយ។ បញ្ហានេះកំពុងត្រូវបានដោះស្រាយដោយ កុងស៊ុលប៉ុន្តែនៅពេលអនាគត មហិច្ឆតារបស់អ្នកនិពន្ធនឹងពង្រីក ផ្ទាល់ខ្លួន ការអនុវត្ត Raft ជាកន្លែងដែលអ្នកសក្ដិសមបំផុតនឹងក្លាយជាថ្នាំងអ្នកដឹកនាំការយល់ស្រប។ បន្ថែមពីលើការយល់ស្រប ថ្នាំងជាញឹកញាប់ (ម្តងក្នុងមួយវិនាទីតាមលំនាំដើម) ផ្ញើទៅប្រទេសជិតខាងរបស់ពួកគេ ផ្នែកទាំងនោះនៃម៉ែត្រសរុបដែលពួកគេបានគ្រប់គ្រងដើម្បីប្រមូលក្នុងវិនាទីនោះ។ វាប្រែថាការធ្វើមាត្រដ្ឋាន និងការអត់ឱនកំហុសត្រូវបានរក្សាទុក - ថ្នាំងនីមួយៗនៅតែមានសំណុំម៉ែត្រពេញលេញ ប៉ុន្តែម៉ែត្រត្រូវបានផ្ញើសរុបរួចហើយតាមរយៈ TCP និងបានអ៊ិនកូដទៅជាពិធីការប្រព័ន្ធគោលពីរ ដូច្នេះតម្លៃចម្លងត្រូវបានកាត់បន្ថយយ៉ាងខ្លាំងបើប្រៀបធៀបទៅនឹង UDP ។ ទោះបីជាមានចំនួនច្រើននៃម៉ែត្រចូលក៏ដោយ ការប្រមូលផ្តុំត្រូវការអង្គចងចាំតិចតួចបំផុត និងសូម្បីតែស៊ីភីយូតិចក៏ដោយ។ សម្រាប់ mertics ដែលអាចបង្ហាប់បានខ្ពស់របស់យើង នេះគ្រាន់តែជាទិន្នន័យរាប់សិបមេកាបៃប៉ុណ្ណោះ។ ជាប្រាក់រង្វាន់បន្ថែម យើងមិនទទួលបានទិន្នន័យដែលមិនចាំបាច់សរសេរឡើងវិញជា Graphite ដូចករណីជាមួយ burbeck នោះទេ។

កញ្ចប់ UDP ដែលមានម៉ែត្រគឺមិនមានតុល្យភាពរវាងថ្នាំងនៅលើឧបករណ៍បណ្តាញតាមរយៈ Round Robin សាមញ្ញ។ ជាការពិតណាស់ ផ្នែករឹងបណ្តាញមិនញែកមាតិកានៃកញ្ចប់ព័ត៌មានទេ ដូច្នេះហើយអាចទាញបានច្រើនជាង 4M កញ្ចប់ក្នុងមួយវិនាទី ដោយមិននិយាយអំពីម៉ែត្រដែលវាមិនដឹងអ្វីទាំងអស់។ ប្រសិនបើយើងពិចារណាថាម៉ែត្រមិនមកម្តងមួយៗក្នុងកញ្ចប់នីមួយៗ នោះយើងមិនគិតទុកជាមុនអំពីបញ្ហាដំណើរការណាមួយនៅក្នុងកន្លែងនេះទេ។ ប្រសិនបើម៉ាស៊ីនមេគាំង ឧបករណ៍បណ្តាញយ៉ាងលឿន (ក្នុងរយៈពេល 1-2 វិនាទី) រកឃើញការពិតនេះហើយដកម៉ាស៊ីនមេដែលគាំងចេញពីការបង្វិល។ ជាលទ្ធផលនៃបញ្ហានេះ ថ្នាំងអកម្ម (ពោលគឺមិនមែនអ្នកដឹកនាំ) អាចបើក និងបិទដោយការអនុវត្តដោយមិនចាំបាច់កត់សម្គាល់ការដកនៅលើតារាង។ អតិបរមាដែលយើងចាញ់គឺជាផ្នែកមួយនៃរង្វាស់ដែលបានមកនៅវិនាទីចុងក្រោយ។ ការបាត់បង់/បិទ/ប្តូរភ្លាមៗនៃអ្នកដឹកនាំនឹងនៅតែបង្កើតភាពខុសប្រក្រតីតូចមួយ (ចន្លោះពេល 30 វិនាទីនៅតែមិនស៊ីសង្វាក់គ្នា) ប៉ុន្តែប្រសិនបើមានការទំនាក់ទំនងរវាងថ្នាំង បញ្ហាទាំងនេះអាចត្រូវបានបង្រួមអប្បបរមា ឧទាហរណ៍ដោយការផ្ញើកញ្ចប់ព័ត៌មានធ្វើសមកាលកម្ម។ .

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

ផ្នែករាប់ (ទទួលខុសត្រូវចំពោះការប្រមូលផ្តុំ) គឺគួរឱ្យធុញណាស់។ សតិបណ្ដោះអាសន្នដែលបំពេញដោយលំហូរបណ្តាញត្រូវបានចែកចាយក្នុងចំណោមលំហូររាប់ ដែលពួកគេត្រូវបានញែកជាបន្តបន្ទាប់ និងសរុប។ តាមការស្នើសុំ រង្វាស់ត្រូវបានផ្តល់សម្រាប់ការផ្ញើទៅកាន់ថ្នាំងផ្សេងទៀត។ ទាំងអស់នេះ រួមទាំងការបញ្ជូនទិន្នន័យរវាងថ្នាំង និងធ្វើការជាមួយកុងស៊ុល ត្រូវបានអនុវត្តដោយមិនសមកាលកម្ម ដោយដំណើរការលើក្របខ័ណ្ឌ tokio.

បញ្ហាជាច្រើនទៀតក្នុងអំឡុងពេលអភិវឌ្ឍន៍គឺបណ្តាលមកពីផ្នែកបណ្តាញដែលទទួលខុសត្រូវក្នុងការទទួលម៉ែត្រ។ គោលដៅចម្បងនៃការបំបែកលំហូរបណ្តាញចូលទៅក្នុងអង្គភាពដាច់ដោយឡែកគឺបំណងប្រាថ្នាដើម្បីកាត់បន្ថយពេលវេលាដែលលំហូរចំណាយ មិនមាន ដើម្បីអានទិន្នន័យពីរន្ធ។ ជម្រើសដែលប្រើ UDP អសមកាល និង recvmsg ធម្មតាបានបាត់យ៉ាងឆាប់រហ័ស៖ ទីមួយប្រើប្រាស់ស៊ីភីយូទំហំអ្នកប្រើប្រាស់ច្រើនពេកសម្រាប់ដំណើរការព្រឹត្តិការណ៍ ទីពីរទាមទារការប្តូរបរិបទច្រើនពេក។ ដូច្នេះឥឡូវនេះវាត្រូវបានគេប្រើ recvmmsg ជាមួយនឹងសតិបណ្ដោះអាសន្នធំ (និងសតិបណ្ដោះអាសន្ន មន្ត្រីសុភាពបុរស គ្មានអ្វីសម្រាប់អ្នកទេ!) ការគាំទ្រសម្រាប់ UDP ធម្មតាត្រូវបានបម្រុងទុកសម្រាប់ករណីស្រាលដែល recvmmsg មិនត្រូវការ។ នៅក្នុងរបៀបពហុសារ វាគឺអាចធ្វើទៅបានដើម្បីសម្រេចបាននូវរឿងសំខាន់: ភាគច្រើននៃពេលវេលា ខ្សែបណ្តាញទាញជួរប្រព័ន្ធប្រតិបត្តិការ - អានទិន្នន័យពីរន្ធ ហើយផ្ទេរវាទៅសតិបណ្ដោះអាសន្នកន្លែងប្រើប្រាស់ ជួនកាលប្តូរទៅផ្តល់សតិបណ្ដោះអាសន្នដែលបំពេញទៅ អ្នកប្រមូលផ្តុំ។ ជួរនៅក្នុងរន្ធអនុវត្តមិនកកកុញទេចំនួននៃកញ្ចប់ដែលបានធ្លាក់ចុះអនុវត្តមិនរីកចម្រើន។

ការកត់សម្គាល់

នៅក្នុងការកំណត់លំនាំដើម ទំហំសតិបណ្ដោះអាសន្នត្រូវបានកំណត់ឱ្យធំណាស់។ ប្រសិនបើអ្នកភ្លាមៗសម្រេចចិត្តសាកល្បងម៉ាស៊ីនមេដោយខ្លួនឯង អ្នកអាចជួបប្រទះនឹងការពិតដែលថាបន្ទាប់ពីការផ្ញើម៉ែត្រមួយចំនួនតូចពួកគេនឹងមិនមកដល់ Graphite ទេ ដោយនៅសល់នៅក្នុងបណ្តុំបណ្តាញស្ទ្រីម។ ដើម្បីធ្វើការជាមួយម៉ែត្រមួយចំនួនតូច អ្នកត្រូវកំណត់ទំហំ bufsize និង task-queue-size ទៅតម្លៃតូចជាងនៅក្នុង config ។

ទីបំផុតតារាងខ្លះសម្រាប់អ្នកចូលចិត្តគំនូសតាង។

ស្ថិតិអំពីចំនួនម៉ែត្រចូលសម្រាប់ម៉ាស៊ីនមេនីមួយៗ៖ ច្រើនជាង 2 លាន MPS ។

បិទ​ថ្នាំង​មួយ​ក្នុង​ចំណោម​ថ្នាំង និង​ចែកចាយ​ម៉ែត្រ​ដែល​ចូល​ឡើងវិញ។

ស្ថិតិលើការវាស់វែងចេញ៖ មានតែថ្នាំងមួយប៉ុណ្ណោះដែលតែងតែផ្ញើ - មេវាយឆ្មក់។

ស្ថិតិនៃប្រតិបត្តិការនៃថ្នាំងនីមួយៗដោយគិតគូរពីកំហុសនៅក្នុងម៉ូឌុលប្រព័ន្ធផ្សេងៗ។

ព័ត៌មានលម្អិតនៃម៉ែត្រចូល (ឈ្មោះម៉ែត្រត្រូវបានលាក់)។

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

ជាការពិតណាស់ អ្នកគ្រប់គ្នាត្រូវបានស្វាគមន៍ក្នុងការជួយក្នុងការអភិវឌ្ឍន៍គម្រោង៖ បង្កើត PR, បញ្ហាប្រសិនបើអាចធ្វើទៅបាន យើងនឹងឆ្លើយតប កែលម្អ។ល។

ដោយ​មាន​ការ​និយាយ​ថា នោះ​ហើយ​ជា​មនុស្ស​ទាំង​អស់​គ្នា​ទិញ​ដំរី​របស់​យើង!

ប្រភព: www.habr.com