សរសេរឡើងវិញនូវមូលដ្ឋានទិន្នន័យសារ VKontakte ពីទទេហើយរស់បាន។

អ្នកប្រើប្រាស់របស់យើងសរសេរសារទៅគ្នាទៅវិញទៅមកដោយមិនដឹងពីភាពអស់កម្លាំង។

នោះច្រើនណាស់។ ប្រសិនបើអ្នកកំណត់ដើម្បីអានសារទាំងអស់របស់អ្នកប្រើប្រាស់ទាំងអស់ វានឹងចំណាយពេលលើសពី 150 ពាន់ឆ្នាំ។ ផ្តល់ថាអ្នកជាអ្នកអានកម្រិតខ្ពស់គួរសម ហើយចំណាយពេលមិនលើសពីមួយវិនាទីលើសារនីមួយៗ។

ជាមួយនឹងបរិមាណទិន្នន័យបែបនេះ វាជារឿងសំខាន់ដែលតក្កវិជ្ជាសម្រាប់ការរក្សាទុក និងការចូលប្រើប្រាស់វាត្រូវបានបង្កើតឡើងយ៉ាងល្អប្រសើរ។ បើមិនដូច្នេះទេ ក្នុងពេលដ៏មិនអស្ចារ្យមួយ វាអាចនឹងច្បាស់ថាអ្វីៗនឹងខុសក្នុងពេលឆាប់ៗនេះ។

សម្រាប់​យើង​ពេល​នេះ​បាន​មក​ដល់​មួយ​ឆ្នាំ​កន្លះ​មុន។ របៀបដែលយើងបានមកដល់រឿងនេះហើយអ្វីដែលបានកើតឡើងនៅទីបញ្ចប់ - យើងប្រាប់អ្នកតាមលំដាប់លំដោយ។

ផ្ទៃខាងក្រោយ

នៅក្នុងការអនុវត្តដំបូង សារ VKontakte បានធ្វើការលើការរួមបញ្ចូលគ្នានៃកម្មវិធី PHP backend និង MySQL ។ នេះគឺជាដំណោះស្រាយធម្មតាទាំងស្រុងសម្រាប់គេហទំព័រសិស្សតូចមួយ។ ទោះជាយ៉ាងណាក៏ដោយ គេហទំព័រនេះបានកើនឡើងដោយមិនអាចគ្រប់គ្រងបាន ហើយបានចាប់ផ្តើមទាមទារឱ្យមានការបង្កើនប្រសិទ្ធភាពនៃរចនាសម្ព័ន្ធទិន្នន័យសម្រាប់ខ្លួនវាផ្ទាល់។

នៅចុងឆ្នាំ 2009 ឃ្លាំងអត្ថបទម៉ាស៊ីនដំបូងត្រូវបានសរសេរ ហើយនៅឆ្នាំ 2010 សារត្រូវបានផ្ទេរទៅវា។

នៅក្នុងម៉ាស៊ីនអត្ថបទ សារត្រូវបានរក្សាទុកក្នុងបញ្ជី - ប្រភេទនៃ "ប្រអប់សំបុត្រ" ។ បញ្ជីបែបនេះនីមួយៗត្រូវបានកំណត់ដោយ uid - អ្នកប្រើប្រាស់ដែលជាម្ចាស់សារទាំងអស់នេះ។ សារ​មួយ​មាន​សំណុំ​នៃ​លក្ខណៈ៖ អ្នក​កំណត់​អន្តរ​ទំនាក់ទំនង អត្ថបទ ឯកសារ​ភ្ជាប់​ជាដើម។ ការកំណត់អត្តសញ្ញាណសារនៅខាងក្នុង “ប្រអប់” គឺ local_id វាមិនផ្លាស់ប្តូរ ហើយត្រូវបានចាត់តាំងជាបន្តបន្ទាប់សម្រាប់សារថ្មី។ "ប្រអប់" គឺឯករាជ្យ និងមិនត្រូវបានធ្វើសមកាលកម្មជាមួយគ្នានៅក្នុងម៉ាស៊ីនទេ ការទំនាក់ទំនងរវាងពួកវាកើតឡើងនៅកម្រិត PHP ។ អ្នកអាចមើលរចនាសម្ព័ន្ធទិន្នន័យ និងសមត្ថភាពរបស់ម៉ាស៊ីនអត្ថបទពីខាងក្នុង នៅទីនេះ.

នេះគឺគ្រប់គ្រាន់សម្រាប់ការឆ្លើយឆ្លងរវាងអ្នកប្រើប្រាស់ពីរនាក់។ ទាយមើលថាមានអ្វីកើតឡើងបន្ទាប់?

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

អ្នក​ប្រើ​និយាយ​ថា "PHP តោះ​ផ្ញើ​សារ​ទៅ​ជជែក"។
PHP និយាយថា “មក! {username}” ។

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

នៅចុងឆ្នាំ 2015 យើងបានចាប់ផ្តើមសារសហគមន៍ ហើយនៅដើមឆ្នាំ 2016 យើងបានបើកដំណើរការ API សម្រាប់ពួកគេ។ ជាមួយនឹងការមកដល់នៃ chatbots ដ៏ធំនៅក្នុងសហគមន៍ វាអាចបំភ្លេចបានសូម្បីតែការចែកចាយការផ្ទុក។

bot ដ៏ល្អបង្កើតសារជាច្រើនលានក្នុងមួយថ្ងៃ - សូម្បីតែអ្នកប្រើប្រាស់ដែលនិយាយច្រើនក៏មិនអាចអួតពីរឿងនេះដែរ។ នេះមានន័យថាករណីមួយចំនួននៃម៉ាស៊ីនអត្ថបទ ដែល bots រស់នៅនោះ ចាប់ផ្តើមរងទុក្ខយ៉ាងពេញលេញ។

ម៉ាស៊ីនផ្ញើសារក្នុងឆ្នាំ 2016 មាន 100 ករណីនៃសមាជិកជជែក និងសមាជិកជជែក និង 8000 ម៉ាស៊ីនអត្ថបទ។ ពួកគេត្រូវបានបង្ហោះនៅលើម៉ាស៊ីនមេមួយពាន់ ដែលនីមួយៗមានអង្គចងចាំ 64 GB ។ ជាវិធានការសង្គ្រោះបន្ទាន់ដំបូង យើងបានបង្កើនអង្គចងចាំ 32 GB ផ្សេងទៀត។ យើងបានប៉ាន់ស្មានការព្យាករណ៍។ បើគ្មានការផ្លាស់ប្តូរខ្លាំងទេ នេះនឹងគ្រប់គ្រាន់សម្រាប់ប្រហែលមួយឆ្នាំទៀត។ អ្នកត្រូវកាន់ផ្នែករឹង ឬបង្កើនប្រសិទ្ធភាពមូលដ្ឋានទិន្នន័យដោយខ្លួនឯង។

ដោយសារតែធម្មជាតិនៃស្ថាបត្យកម្ម វាសមហេតុផលក្នុងការបង្កើនផ្នែករឹងក្នុងពហុគុណ។ នោះគឺយ៉ាងហោចណាស់ចំនួនរថយន្តទ្វេដង - ជាក់ស្តែងនេះគឺជាផ្លូវថ្លៃជាង។ យើងនឹងធ្វើឱ្យប្រសើរ។

គំនិតថ្មី។

ខ្លឹមសារសំខាន់នៃវិធីសាស្រ្តថ្មីគឺការជជែក។ ការជជែកមានបញ្ជីសារដែលទាក់ទងនឹងវា។ អ្នកប្រើប្រាស់មានបញ្ជីជជែក។

អប្បបរមាដែលត្រូវការគឺមូលដ្ឋានទិន្នន័យថ្មីពីរ៖

• ម៉ាស៊ីនជជែក។ នេះគឺជាឃ្លាំងនៃវ៉ិចទ័រជជែក។ ការជជែកនីមួយៗមានវ៉ិចទ័រនៃសារដែលទាក់ទងនឹងវា។ សារនីមួយៗមានអត្ថបទ និងឧបករណ៍កំណត់អត្តសញ្ញាណសារតែមួយគត់នៅខាងក្នុងការជជែក - chat_local_id។
• ម៉ាស៊ីនអ្នកប្រើប្រាស់។ នេះគឺជាការផ្ទុកវ៉ិចទ័រអ្នកប្រើប្រាស់ - តំណភ្ជាប់ទៅកាន់អ្នកប្រើប្រាស់។ អ្នកប្រើប្រាស់នីមួយៗមានវ៉ិចទ័រនៃ peer_id (អន្តរទំនាក់ទំនង - អ្នកប្រើប្រាស់ផ្សេងទៀត ការជជែកច្រើន ឬសហគមន៍) និងវ៉ិចទ័រនៃសារ។ peer_id នីមួយៗមានវ៉ិចទ័រនៃសារដែលទាក់ទងនឹងវា។ សារនីមួយៗមាន chat_local_id និងលេខសម្គាល់សារតែមួយគត់សម្រាប់អ្នកប្រើប្រាស់នោះ - user_local_id ។

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

ការធ្វើការជាមួយថាសនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់យើងក្នុងករណីភាគច្រើនគឺផ្អែកលើការរួមបញ្ចូលគ្នានៃកំណត់ហេតុគោលពីរនៃការផ្លាស់ប្តូរ (binlog) រូបថតឋិតិវន្ត និងរូបភាពមួយផ្នែកនៅក្នុងអង្គចងចាំ។ ការផ្លាស់ប្តូរក្នុងអំឡុងពេលថ្ងៃត្រូវបានសរសេរទៅកាន់ binlog ហើយរូបថតនៃស្ថានភាពបច្ចុប្បន្នត្រូវបានបង្កើតជាទៀងទាត់។ រូបថតគឺជាបណ្តុំនៃរចនាសម្ព័ន្ធទិន្នន័យដែលត្រូវបានកែលម្អសម្រាប់គោលបំណងរបស់យើង។ វាមានបឋមកថា (សន្ទស្សន៍មេតានៃរូបភាព) និងសំណុំនៃឯកសារមេតា។ បឋមកថាត្រូវបានរក្សាទុកជាអចិន្ត្រៃយ៍នៅក្នុង RAM និងចង្អុលបង្ហាញកន្លែងដែលត្រូវរកមើលទិន្នន័យពីរូបថត។ ឯកសារមេតានីមួយៗរួមបញ្ចូលទិន្នន័យដែលទំនងជាត្រូវការនៅចំណុចជិតស្និទ្ធក្នុងពេលវេលា - ឧទាហរណ៍ទាក់ទងនឹងអ្នកប្រើប្រាស់តែមួយ។ នៅពេលអ្នកសួរមូលដ្ឋានទិន្នន័យដោយប្រើបឋមកថារូបថត ឯកសារមេតាដែលត្រូវការត្រូវបានអាន ហើយបន្ទាប់មកការផ្លាស់ប្តូរនៅក្នុង binlog ដែលបានកើតឡើងបន្ទាប់ពីរូបថតត្រូវបានបង្កើតត្រូវបានយកមកពិចារណា។ អ្នកអាចអានបន្ថែមអំពីអត្ថប្រយោជន៍នៃវិធីសាស្រ្តនេះ។ នៅទីនេះ.

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

ការផ្ញើសារនៅក្នុងគ្រោងការណ៍ថ្មីមើលទៅដូចនេះ៖

1. ផ្នែកខាងក្រោយរបស់ PHP ទាក់ទងម៉ាស៊ីនអ្នកប្រើប្រាស់ជាមួយនឹងសំណើដើម្បីផ្ញើសារ។
2. user-engine proxies សំណើទៅកាន់ instance ម៉ាស៊ីនជជែកដែលចង់បាន ដែលត្រឡប់ទៅ user-engine chat_local_id - ការកំណត់អត្តសញ្ញាណតែមួយគត់នៃសារថ្មីនៅក្នុងការជជែកនេះ។ បន្ទាប់មក chat_engine ផ្សាយសារទៅកាន់អ្នកទទួលទាំងអស់នៅក្នុងការជជែក។
3. user-engine ទទួល chat_local_id ពី chat-engine ហើយបញ្ជូន user_local_id ទៅ PHP - ជាឧបករណ៍កំណត់អត្តសញ្ញាណសារតែមួយគត់សម្រាប់អ្នកប្រើប្រាស់នេះ។ បន្ទាប់មកឧបករណ៍សម្គាល់នេះត្រូវបានប្រើជាឧទាហរណ៍ ដើម្បីធ្វើការជាមួយសារតាមរយៈ API ។

ប៉ុន្តែបន្ថែមពីលើការផ្ញើសារពិតប្រាកដ អ្នកត្រូវអនុវត្តចំណុចសំខាន់ៗមួយចំនួនទៀត៖

• ឧទាហរណ៍ បញ្ជីរងគឺជាសារថ្មីៗបំផុតដែលអ្នកឃើញនៅពេលបើកបញ្ជីសន្ទនា។ សារមិនទាន់អាន ​​សារដែលមានស្លាក ("សំខាន់" "សារឥតបានការ" ។ល។)។
• ការបង្ហាប់សារនៅក្នុងម៉ាស៊ីនជជែក
• ការរក្សាទុកសារនៅក្នុងម៉ាស៊ីនអ្នកប្រើប្រាស់
• ស្វែងរក (តាមរយៈប្រអប់ទាំងអស់ និងក្នុងជាក់លាក់មួយ)។
• ការធ្វើបច្ចុប្បន្នភាពតាមពេលវេលាជាក់ស្តែង (Longpolling) ។
• រក្សាទុកប្រវត្តិដើម្បីអនុវត្តឃ្លាំងសម្ងាត់នៅលើម៉ាស៊ីនភ្ញៀវចល័ត។

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

សារពាក់ព័ន្ធនឹងចំនួនព័ត៌មានច្រើន ដែលភាគច្រើនជាអត្ថបទ ដែលមានប្រយោជន៍ដើម្បីអាចបង្ហាប់បាន។ វាជារឿងសំខាន់ដែលយើងអាចមិនទុកក្នុងប័ណ្ណសារបានត្រឹមត្រូវសូម្បីតែសារបុគ្គលតែមួយក៏ដោយ។ ប្រើដើម្បីបង្រួមសារ ក្បួនដោះស្រាយ Huffman ជាឧទាហរណ៍ យើងដឹងថានៅក្នុងសារដែលពាក្យជំនួសដោយ "មិនមែនពាក្យ" - ដកឃ្លា សញ្ញាវណ្ណយុត្តិ - ហើយយើងក៏ចងចាំនូវលក្ខណៈពិសេសមួយចំនួននៃការប្រើប្រាស់និមិត្តសញ្ញាសម្រាប់ភាសារុស្សីផងដែរ។

ដោយសារមានអ្នកប្រើប្រាស់តិចជាងការជជែក ដើម្បីរក្សាទុកការស្នើសុំថាសចូលដោយចៃដន្យនៅក្នុងម៉ាស៊ីនជជែក យើងរក្សាទុកសារនៅក្នុងម៉ាស៊ីនអ្នកប្រើប្រាស់។

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

ជាការប្រសើរណាស់ ព័ត៌មានលម្អិតទាំងអស់ត្រូវបានគេយកមកពិចារណា ហើយអ្វីដែលនៅសេសសល់គឺត្រូវប្តូរទៅគ្រោងការណ៍ថ្មី ហើយនិយមដោយគ្មានអ្នកប្រើប្រាស់កត់សម្គាល់វា។

ការផ្ទេរទិន្នន័យ

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

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

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

ឥឡូវនេះ chat-engine ដឹងអំពីការជជែកច្រើនពីសមាជិកជជែក ប៉ុន្តែវាមិនទាន់ដឹងអ្វីទាំងអស់អំពីការសន្ទនាជាមួយ interlocutors ពីរនាក់។ ការសន្ទនាបែបនេះមានទីតាំងនៅក្នុងម៉ាស៊ីនអត្ថបទដោយយោងទៅអ្នកប្រើប្រាស់។ នៅទីនេះ យើងបានយកទិន្នន័យ "បន្តផ្ទាល់"៖ រាល់ chat-engine instance បានសួររាល់ text-engine instances ប្រសិនបើពួកគេមានការសន្ទនាដែលវាត្រូវការ។

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

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

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

យើងប្រើរចនាសម្ព័ន្ធទិន្នន័យពិសេសដើម្បីរក្សាទុកសារដែលបាននាំចូល។

វាតំណាងឱ្យវ៉ិចទ័រនៃទំហំ តើអ្នករាល់គ្នានៅឯណា - មាន​លក្ខណៈ​ខុស​គ្នា និង​តម្រៀប​តាម​លំដាប់​ចុះ ដោយ​មាន​លំដាប់​ធាតុ​ពិសេស។ នៅក្នុងផ្នែកនីមួយៗដែលមានសន្ទស្សន៍ ធាតុត្រូវបានតម្រៀប។ ការស្វែងរកធាតុនៅក្នុងរចនាសម្ព័ន្ធបែបនេះត្រូវការពេលវេលា តាមរយៈការ ការស្វែងរកប្រព័ន្ធគោលពីរ។ ការបន្ថែមធាតុមួយត្រូវបានរំលោះ .

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

ទិន្នន័យត្រូវបានសរសេរទៅកាន់សមាជិកជជែក និងម៉ាស៊ីនអ្នកប្រើប្រាស់ (និងមិនមែនទៅម៉ាស៊ីនអត្ថបទ ដូចក្នុងប្រតិបត្តិការធម្មតាយោងទៅតាមគ្រោងការណ៍ចាស់)។ user-engine proxies សំណើទៅកាន់ chat-engine - ហើយនៅទីនេះ ឥរិយាបទអាស្រ័យលើថាតើការជជែកនេះត្រូវបានបញ្ចូលគ្នារួចហើយឬអត់។ ប្រសិនបើការជជែកមិនទាន់ត្រូវបានបញ្ចូលគ្នាទេ ម៉ាស៊ីនជជែកមិនសរសេរសារទៅខ្លួនវាទេ ហើយដំណើរការរបស់វាកើតឡើងតែនៅក្នុងម៉ាស៊ីនអត្ថបទប៉ុណ្ណោះ។ ប្រសិនបើការជជែកត្រូវបានបញ្ចូលទៅក្នុងម៉ាស៊ីនជជែករួចហើយ វាត្រឡប់ chat_local_id ទៅម៉ាស៊ីនអ្នកប្រើប្រាស់ ហើយផ្ញើសារទៅកាន់អ្នកទទួលទាំងអស់។ user-engine proxies ទិន្នន័យទាំងអស់ទៅកាន់ text-engine - ដូច្នេះប្រសិនបើមានអ្វីកើតឡើង យើងអាចត្រលប់មកវិញបានជានិច្ច ដោយមានទិន្នន័យបច្ចុប្បន្នទាំងអស់នៅក្នុងម៉ាស៊ីនចាស់។ text-engine ត្រឡប់ user_local_id ដែល user-engine រក្សាទុក ហើយត្រឡប់ទៅ backend វិញ។

ជាលទ្ធផល ដំណើរការផ្លាស់ប្តូរមើលទៅដូចនេះ៖ យើងភ្ជាប់ម៉ាស៊ីនអ្នកប្រើប្រាស់ទទេ និងចង្កោមម៉ាស៊ីនជជែក។ ម៉ាស៊ីនជជែកអាន binlog សមាជិកជជែកទាំងមូល បន្ទាប់មកប្រូកស៊ីចាប់ផ្តើមដោយយោងតាមគ្រោងការណ៍ដែលបានពិពណ៌នាខាងលើ។ យើងផ្ទេរទិន្នន័យចាស់ និងទទួលបានចង្កោមដែលធ្វើសមកាលកម្មពីរ (ចាស់ និងថ្មី)។ អ្វីដែលនៅសេសសល់គឺត្រូវប្តូរការអានពីម៉ាស៊ីនអត្ថបទទៅជាម៉ាស៊ីនអ្នកប្រើប្រាស់ ហើយបិទដំណើរការប្រូកស៊ី។

Результаты

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

ការផ្លាស់ប្តូរតក្កវិជ្ជាពិតជាធំធេងណាស់។ ហើយខ្ញុំចង់កត់សម្គាល់ថានេះមិនតែងតែមានន័យថាពេញមួយឆ្នាំនៃការអភិវឌ្ឍន៍ដោយក្រុមដ៏ធំនិងជួរជាច្រើននៃកូដនោះទេ។ chat-engine និង user-engine រួមជាមួយនឹងរឿងបន្ថែមទាំងអស់ដូចជា Huffman សម្រាប់ការបង្ហាប់សារ ដើមឈើ Splay និងរចនាសម្ព័ន្ធសម្រាប់សារដែលបាននាំចូលគឺតិចជាង 20 ពាន់បន្ទាត់នៃកូដ។ ហើយពួកគេត្រូវបានសរសេរដោយអ្នកអភិវឌ្ឍន៍ 3 នាក់ក្នុងរយៈពេលត្រឹមតែ 10 ខែប៉ុណ្ណោះ (ទោះជាយ៉ាងណាក៏ដោយវាមានតម្លៃចងចាំវា។ ទាំងអស់ បី អ្នកអភិវឌ្ន៍ - ជើងឯកពិភពលោក នៅក្នុងកម្មវិធីកីឡា).

លើសពីនេះទៅទៀត ជំនួសឱ្យការបង្កើនចំនួនម៉ាស៊ីនមេទ្វេដង យើងបានកាត់បន្ថយចំនួនរបស់ពួកគេពាក់កណ្តាល - ឥឡូវនេះម៉ាស៊ីនអ្នកប្រើប្រាស់ និងម៉ាស៊ីនជជែកផ្ទាល់នៅលើម៉ាស៊ីនចំនួន 500 ខណៈដែលគ្រោងការណ៍ថ្មីមានបន្ទប់ធំសម្រាប់ផ្ទុក។ យើងបានសន្សំប្រាក់យ៉ាងច្រើនលើឧបករណ៍ - ប្រហែល 5 លានដុល្លារ + 750 ពាន់ដុល្លារក្នុងមួយឆ្នាំក្នុងការចំណាយប្រតិបត្តិការ។

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

ទោះបីជារឿងនេះមិននិយាយអំពីអ្នកក៏ដោយ សូមចំណាំថាយើងឱ្យតម្លៃលើការណែនាំ។ ប្រាប់មិត្តម្នាក់អំពី ដំណឹងជ្រើសរើសបុគ្គលិកហើយប្រសិនបើគាត់បានបញ្ចប់រយៈពេលសាកល្បងដោយជោគជ័យ អ្នកនឹងទទួលបានប្រាក់រង្វាន់ 100 ពាន់រូប្លិ៍។

ប្រភព: www.habr.com