របៀប និងមូលហេតុដែលយើងសរសេរសេវាកម្មដែលអាចធ្វើមាត្រដ្ឋានបានខ្ពស់សម្រាប់ 1C: សហគ្រាស៖ Java, PostgreSQL, Hazelcast

នៅក្នុងអត្ថបទនេះ យើងនឹងនិយាយអំពីរបៀប និងមូលហេតុដែលយើងអភិវឌ្ឍ ប្រព័ន្ធអន្តរកម្ម - យន្តការដែលផ្ទេរព័ត៌មានរវាងកម្មវិធីអតិថិជន និង 1C: ម៉ាស៊ីនមេសហគ្រាស - ពីការកំណត់ភារកិច្ចរហូតដល់ការគិតតាមរយៈស្ថាបត្យកម្ម និងព័ត៌មានលម្អិតនៃការអនុវត្ត។

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

SV ប្រើទំហំផ្ទុកដែលបានចែកចាយ ហាហ្សែល និងម៉ាស៊ីនស្វែងរក Elasticsearch. យើងក៏នឹងនិយាយអំពី Java និងរបៀបដែលយើងធ្វើមាត្រដ្ឋានផ្ដេក PostgreSQL ។

ការបង្កើតបញ្ហា

ដើម្បីបញ្ជាក់ឱ្យច្បាស់ថាហេតុអ្វីបានជាយើងបង្កើតប្រព័ន្ធអន្តរកម្ម ខ្ញុំនឹងប្រាប់អ្នកបន្តិចអំពីរបៀបដែលការអភិវឌ្ឍន៍កម្មវិធីអាជីវកម្មនៅក្នុង 1C ដំណើរការ។

ដើម្បីចាប់ផ្តើមជាមួយយើងបន្តិចសម្រាប់អ្នកដែលមិនទាន់ដឹងថាយើងធ្វើអ្វី :) យើងកំពុងបង្កើតវេទិកាបច្ចេកវិទ្យា 1C: សហគ្រាស។ វេទិកានេះរួមបញ្ចូលឧបករណ៍អភិវឌ្ឍន៍កម្មវិធីអាជីវកម្ម ក៏ដូចជារយៈពេលដំណើរការដែលអនុញ្ញាតឱ្យកម្មវិធីអាជីវកម្មដំណើរការក្នុងបរិយាកាសឆ្លងវេទិកា។

គំរូអភិវឌ្ឍន៍ម៉ាស៊ីនភ្ញៀវ-ម៉ាស៊ីនមេ

កម្មវិធីអាជីវកម្មដែលបានបង្កើតនៅលើ 1C: សហគ្រាសដំណើរការក្នុងកម្រិតបី ម៉ាស៊ីនភ្ញៀវ-ម៉ាស៊ីនមេ ស្ថាបត្យកម្ម "DBMS - ម៉ាស៊ីនបម្រើកម្មវិធី - ម៉ាស៊ីនភ្ញៀវ" ។ កូដកម្មវិធីត្រូវបានសរសេរនៅក្នុង បង្កើតជាភាសា 1Cអាចត្រូវបានប្រតិបត្តិនៅលើម៉ាស៊ីនមេកម្មវិធីឬនៅលើម៉ាស៊ីនភ្ញៀវ។ ការងារទាំងអស់ជាមួយវត្ថុកម្មវិធី (ថតឯកសារ។ល។) ក៏ដូចជាការអាន និងសរសេរមូលដ្ឋានទិន្នន័យត្រូវបានអនុវត្តតែលើម៉ាស៊ីនមេប៉ុណ្ណោះ។ មុខងារនៃទម្រង់ និងចំណុចប្រទាក់ពាក្យបញ្ជាក៏ត្រូវបានអនុវត្តនៅលើម៉ាស៊ីនមេផងដែរ។ អតិថិជនអនុវត្តការទទួល បើក និងបង្ហាញទម្រង់ "ការប្រាស្រ័យទាក់ទង" ជាមួយអ្នកប្រើប្រាស់ (ការព្រមាន សំណួរ...) ការគណនាតូចៗក្នុងទម្រង់ដែលទាមទារការឆ្លើយតបរហ័ស (ឧទាហរណ៍ គុណតម្លៃដោយបរិមាណ) ធ្វើការជាមួយឯកសារមូលដ្ឋាន។ ធ្វើការជាមួយឧបករណ៍។

នៅក្នុងកូដកម្មវិធី បឋមកថានៃនីតិវិធី និងមុខងារត្រូវតែបង្ហាញយ៉ាងច្បាស់ពីកន្លែងដែលកូដនឹងត្រូវបានប្រតិបត្តិ - ដោយប្រើការណែនាំ &AtClient / &AtServer (&AtClient / &AtServer ជាភាសាអង់គ្លេសជាភាសា)។ ឥឡូវនេះ អ្នកអភិវឌ្ឍន៍ 1C នឹងកែតម្រូវខ្ញុំដោយនិយាយថាការណែនាំគឺពិតជា ច្រើនជាងប៉ុន្តែសម្រាប់យើង ពេលនេះវាមិនសំខាន់ទេ។

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

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

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

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

ផលិតកម្មខ្លួនឯង

បង្កើតយន្តការផ្ញើសារ។ លឿន គួរឱ្យទុកចិត្ត ជាមួយនឹងការដឹកជញ្ជូនដែលមានការធានា ជាមួយនឹងសមត្ថភាពក្នុងការស្វែងរកសារដោយភាពបត់បែន។ ដោយផ្អែកលើយន្តការ អនុវត្តកម្មវិធីផ្ញើសារ (សារ ការហៅជាវីដេអូ) ដែលដំណើរការនៅក្នុងកម្មវិធី 1C ។

រចនាប្រព័ន្ធឱ្យមានទំហំផ្ដេក។ ការកើនឡើងនៃបន្ទុកត្រូវតែគ្របដណ្តប់ដោយការបង្កើនចំនួនថ្នាំង។

Реализация

យើងបានសម្រេចចិត្តមិនបញ្ចូលផ្នែកម៉ាស៊ីនមេរបស់ SV ដោយផ្ទាល់ទៅក្នុង 1C:Enterprise platform ប៉ុន្តែដើម្បីអនុវត្តវាជាផលិតផលដាច់ដោយឡែក API ដែលអាចត្រូវបានហៅចេញពីកូដនៃដំណោះស្រាយកម្មវិធី 1C ។ នេះត្រូវបានធ្វើសម្រាប់ហេតុផលមួយចំនួន ដែលសំខាន់នោះគឺខ្ញុំចង់ធ្វើឱ្យវាអាចផ្លាស់ប្តូរសាររវាងកម្មវិធី 1C ផ្សេងៗគ្នា (ឧទាហរណ៍រវាងការគ្រប់គ្រងពាណិជ្ជកម្ម និងគណនេយ្យ)។ កម្មវិធី 1C ផ្សេងគ្នាអាចដំណើរការលើកំណែផ្សេងគ្នានៃ 1C: វេទិកាសហគ្រាស មានទីតាំងនៅលើម៉ាស៊ីនមេផ្សេងៗគ្នា។ល។ នៅក្នុងលក្ខខណ្ឌបែបនេះការអនុវត្ត SV ជាផលិតផលដាច់ដោយឡែកដែលមានទីតាំងនៅ "ចំហៀង" នៃការដំឡើង 1C គឺជាដំណោះស្រាយដ៏ល្អបំផុត។

ដូច្នេះហើយ យើងបានសម្រេចចិត្តបង្កើត SV ជាផលិតផលដាច់ដោយឡែក។ យើងណែនាំថាក្រុមហ៊ុនតូចៗប្រើម៉ាស៊ីនមេ CB ដែលយើងដំឡើងនៅក្នុងពពករបស់យើង (wss://1cdialog.com) ដើម្បីជៀសវាងការចំណាយលើសដែលទាក់ទងនឹងការដំឡើង និងការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ។ អតិថិជនធំអាចយល់ឃើញថា វាត្រូវបានណែនាំឱ្យដំឡើងម៉ាស៊ីនមេ CB ផ្ទាល់ខ្លួនរបស់ពួកគេនៅឯកន្លែងរបស់ពួកគេ។ យើងបានប្រើវិធីសាស្រ្តស្រដៀងគ្នានៅក្នុងផលិតផល SaaS ពពករបស់យើង។ 1c ស្រស់ - វាត្រូវបានផលិតជាផលិតផលដែលផលិតយ៉ាងច្រើនសម្រាប់ដំឡើងនៅកន្លែងរបស់អតិថិជន ហើយក៏ត្រូវបានដាក់ឱ្យប្រើប្រាស់ក្នុងពពករបស់យើងផងដែរ។ https://1cfresh.com/.

កម្មវិធី

ដើម្បីចែកចាយបន្ទុក និងការអត់ឱនចំពោះកំហុស យើងនឹងដាក់ពង្រាយកម្មវិធី Java មួយមិនមែនទេ ប៉ុន្តែមានកម្មវិធីជាច្រើនជាមួយនឹងឧបករណ៍ផ្ទុកតុល្យភាពនៅពីមុខពួកគេ។ ប្រសិនបើអ្នកត្រូវការផ្ទេរសារពី node ទៅ node សូមប្រើ Publish/subscribe នៅក្នុង Hazelcast។

ការទំនាក់ទំនងរវាងអតិថិជន និងម៉ាស៊ីនមេគឺតាមរយៈ websocket ។ វាសមល្អសម្រាប់ប្រព័ន្ធពេលវេលាពិត។

ឃ្លាំងសម្ងាត់ដែលបានចែកចាយ

យើងបានជ្រើសរើសរវាង Redis, Hazelcast និង Ehcache ។ វាជាឆ្នាំ 2015 ។ Redis ទើបតែបញ្ចេញនូវចង្កោមថ្មី (ថ្មីពេកគួរឱ្យខ្លាច) មាន Sentinel ជាមួយនឹងការរឹតបន្តឹងជាច្រើន។ Ehcache មិនដឹងពីរបៀបប្រមូលផ្តុំទៅជាចង្កោមទេ (មុខងារនេះបានបង្ហាញខ្លួននៅពេលក្រោយ)។ យើងបានសម្រេចចិត្តសាកល្បងវាជាមួយ Hazelcast 3.4 ។
Hazelcast ត្រូវបានប្រមូលផ្តុំជាចង្កោមចេញពីប្រអប់។ នៅក្នុងរបៀប node តែមួយ វាមិនមានប្រយោជន៍ខ្លាំងទេ ហើយអាចប្រើបានតែជាឃ្លាំងសម្ងាត់ប៉ុណ្ណោះ - វាមិនដឹងពីរបៀបបោះចោលទិន្នន័យទៅឌីសទេ ប្រសិនបើអ្នកបាត់បង់ថ្នាំងតែមួយ អ្នកនឹងបាត់បង់ទិន្នន័យ។ យើងដាក់ពង្រាយ Hazelcasts ជាច្រើន ដែលរវាងយើងបម្រុងទុកទិន្នន័យសំខាន់។ យើងមិនបម្រុងទុកឃ្លាំងសម្ងាត់ទេ - យើងមិនខ្វល់ពីវាទេ។

សម្រាប់ពួកយើង Hazelcast គឺ៖

• ការផ្ទុកវគ្គអ្នកប្រើប្រាស់។ វាត្រូវការពេលយូរដើម្បីចូលទៅកាន់ database សម្រាប់ session រាល់ពេល ដូច្នេះយើងដាក់ session ទាំងអស់នៅក្នុង Hazelcast។
• ឃ្លាំង​សម្ងាត់។ ប្រសិនបើអ្នកកំពុងស្វែងរកទម្រង់អ្នកប្រើប្រាស់ សូមពិនិត្យមើលឃ្លាំងសម្ងាត់។ បានសរសេរសារថ្មី - ដាក់វានៅក្នុងឃ្លាំងសម្ងាត់។
• ប្រធានបទសម្រាប់ការទំនាក់ទំនងរវាងកម្មវិធី។ ថ្នាំងបង្កើតព្រឹត្តិការណ៍មួយ ហើយដាក់វានៅក្នុងប្រធានបទ Hazelcast ។ ថ្នាំងកម្មវិធីផ្សេងទៀតដែលបានជាវប្រធានបទនេះទទួល និងដំណើរការព្រឹត្តិការណ៍។
• ការចាក់សោចង្កោម។ ឧទាហរណ៍ យើងបង្កើតការពិភាក្សាដោយប្រើគន្លឹះពិសេសមួយ (ការពិភាក្សាឯកត្តជនក្នុងមូលដ្ឋានទិន្នន័យ 1C)៖

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

យើង​បាន​ពិនិត្យ​មើល​ថា​គ្មាន​ឆានែល​ទេ។ យើងបានយកសោ ពិនិត្យវាម្តងទៀត និងបង្កើតវា។ ប្រសិនបើអ្នកមិនពិនិត្យមើលសោបន្ទាប់ពីចាក់សោទេ នោះវាមានឱកាសដែលខ្សែស្រឡាយផ្សេងទៀតបានពិនិត្យនៅពេលនោះ ហើយឥឡូវនេះនឹងព្យាយាមបង្កើតការពិភាក្សាដូចគ្នា - ប៉ុន្តែវាមានរួចហើយ។ អ្នកមិនអាចចាក់សោដោយប្រើ java Lock ដែលធ្វើសមកាលកម្ម ឬធម្មតាបានទេ។ តាមរយៈមូលដ្ឋានទិន្នន័យ - វាយឺត ហើយវាជាការអាណិតសម្រាប់មូលដ្ឋានទិន្នន័យ តាមរយៈ Hazelcast - នោះហើយជាអ្វីដែលអ្នកត្រូវការ។

ការជ្រើសរើស DBMS

យើងមានបទពិសោធន៍យ៉ាងទូលំទូលាយ និងជោគជ័យក្នុងការធ្វើការជាមួយ PostgreSQL និងសហការជាមួយអ្នកអភិវឌ្ឍន៍ DBMS នេះ។

វាមិនងាយស្រួលទេជាមួយនឹងក្រុម PostgreSQL - មាន XL, XC, ស៊ីតូសប៉ុន្តែជាទូទៅ ទាំងនេះមិនមែនជា NoSQLs ដែលធ្វើមាត្រដ្ឋានចេញពីប្រអប់នោះទេ។ យើងមិនបានចាត់ទុក NoSQL ជាកន្លែងផ្ទុកសំខាន់នោះទេ វាគ្រប់គ្រាន់ហើយដែលយើងយក Hazelcast ដែលយើងមិនបានធ្វើការជាមួយពីមុនមក។

ប្រសិនបើអ្នកត្រូវការធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យទំនាក់ទំនង នោះមានន័យថា ការកាត់. ដូចដែលអ្នកបានដឹងហើយថាជាមួយនឹងការ sharding យើងបែងចែកមូលដ្ឋានទិន្នន័យទៅជាផ្នែកដាច់ដោយឡែកដើម្បីឱ្យពួកវានីមួយៗអាចដាក់នៅលើម៉ាស៊ីនមេដាច់ដោយឡែក។

កំណែដំបូងនៃការបែងចែករបស់យើងសន្មតថាមានលទ្ធភាពចែកចាយតារាងនីមួយៗនៃកម្មវិធីរបស់យើងឆ្លងកាត់ម៉ាស៊ីនមេផ្សេងៗគ្នាក្នុងសមាមាត្រផ្សេងៗគ្នា។ មានសារជាច្រើននៅលើម៉ាស៊ីនមេ A - សូមយើងផ្លាស់ទីផ្នែកនៃតារាងនេះទៅម៉ាស៊ីនមេ B។ ការសម្រេចចិត្តនេះគ្រាន់តែស្រែកអំពីការបង្កើនប្រសិទ្ធភាពមុនអាយុ ដូច្នេះយើងបានសម្រេចចិត្តដាក់កម្រិតខ្លួនយើងទៅនឹងវិធីសាស្រ្តពហុភតិកៈ។

អ្នកអាចអានអំពីអ្នកជួលច្រើនឧទាហរណ៍នៅលើគេហទំព័រ ទិន្នន័យ Citus.

SV មានគោលគំនិតនៃកម្មវិធី និងអតិថិជន។ កម្មវិធីគឺជាការដំឡើងជាក់លាក់នៃកម្មវិធីអាជីវកម្ម ដូចជា ERP ឬ Accounting ជាមួយនឹងអ្នកប្រើប្រាស់ និងទិន្នន័យអាជីវកម្មរបស់វា។ អតិថិជនគឺជាស្ថាប័ន ឬបុគ្គលដែលជំនួសឲ្យពាក្យសុំត្រូវបានចុះឈ្មោះនៅក្នុងម៉ាស៊ីនមេ SV ។ អតិថិជនអាចមានកម្មវិធីជាច្រើនដែលបានចុះឈ្មោះ ហើយកម្មវិធីទាំងនេះអាចផ្លាស់ប្តូរសារគ្នាទៅវិញទៅមក។ អតិថិជនបានក្លាយជាអ្នកជួលនៅក្នុងប្រព័ន្ធរបស់យើង។ សារពីអតិថិជនជាច្រើនអាចមានទីតាំងនៅក្នុងមូលដ្ឋានទិន្នន័យជាក់ស្តែងមួយ។ ប្រសិនបើយើងឃើញថាអតិថិជនបានចាប់ផ្តើមបង្កើតចរាចរច្រើន យើងផ្លាស់ទីវាទៅមូលដ្ឋានទិន្នន័យជាក់ស្តែងដាច់ដោយឡែក (ឬសូម្បីតែម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យដាច់ដោយឡែក)។

យើង​មាន​មូលដ្ឋាន​ទិន្នន័យ​សំខាន់​ដែល​តារាង​កំណត់​ផ្លូវ​ត្រូវ​បាន​រក្សា​ទុក​ជាមួយ​នឹង​ព័ត៌មាន​អំពី​ទីតាំង​នៃ​មូលដ្ឋាន​ទិន្នន័យ​អតិថិជន​ទាំងអស់។

ដើម្បីការពារមូលដ្ឋានទិន្នន័យចម្បងពីការជាប់គាំង យើងរក្សាទុកតារាងផ្លូវ (និងទិន្នន័យដែលត្រូវការញឹកញាប់ផ្សេងទៀត) នៅក្នុងឃ្លាំងសម្ងាត់។

ប្រសិនបើមូលដ្ឋានទិន្នន័យរបស់អ្នកជាវចាប់ផ្តើមយឺត យើងនឹងកាត់វាជាភាគថាសនៅខាងក្នុង។ នៅលើគម្រោងផ្សេងទៀតដែលយើងប្រើ pg_pathman.

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

ប្រសិនបើ​ការចម្លង​ដែល​ធ្វើសមកាលកម្ម​ត្រូវបាន​បាត់បង់ នោះ​ការចម្លង​អសមកាល​នឹង​ក្លាយជា​សមកាលកម្ម។
ប្រសិនបើមូលដ្ឋានទិន្នន័យចម្បងត្រូវបានបាត់បង់ ការចម្លងសមកាលកម្មក្លាយជាមូលដ្ឋានទិន្នន័យសំខាន់ ហើយការចម្លងអសមកាលនឹងក្លាយជាការចម្លងសមកាលកម្ម។

Elasticsearch សម្រាប់ការស្វែងរក

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

នៅលើ github យើងបានរកឃើញ កម្មវិធីជំនួយ morphology របស់រុស្ស៊ី សម្រាប់ Elasticsearch ហើយប្រើវា។ នៅក្នុងសន្ទស្សន៍ Elasticsearch យើងរក្សាទុកឫសពាក្យ (ដែលកម្មវិធីជំនួយកំណត់) និង N-grams ។ នៅពេលដែលអ្នកប្រើប្រាស់បញ្ចូលអត្ថបទដើម្បីស្វែងរក យើងរកមើលអត្ថបទដែលបានវាយក្នុងចំណោម N-grams ។ នៅពេលរក្សាទុកក្នុងលិបិក្រម ពាក្យ "អត្ថបទ" នឹងត្រូវបានបំបែកទៅជា N-grams ខាងក្រោម៖

[ទាំងនោះ, tek, tex, អត្ថបទ, អត្ថបទ, ek, អតីត, ext, អត្ថបទ, ks, kst, ksty, st, sty, អ្នក],

ហើយឫសនៃពាក្យ "អត្ថបទ" ក៏នឹងត្រូវបានរក្សាទុកផងដែរ។ វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យអ្នកស្វែងរកនៅដើម កណ្តាល និងនៅចុងបញ្ចប់នៃពាក្យ។

រូបភាពធំ

ធ្វើម្តងទៀតនូវរូបភាពពីដើមអត្ថបទ ប៉ុន្តែជាមួយនឹងការពន្យល់៖

• Balancer លាតត្រដាងនៅលើអ៊ីនធឺណិត; យើងមាន nginx វាអាចជាណាមួយ។
• កម្មវិធី Java ទាក់ទងគ្នាទៅវិញទៅមកតាមរយៈ Hazelcast ។
• ដើម្បីធ្វើការជាមួយបណ្តាញ socket យើងប្រើ សុទ្ធ។.
• កម្មវិធី Java ត្រូវបានសរសេរក្នុង Java 8 ហើយមានបណ្តុំ អូស៊ីជី. ផែនការរួមមានការធ្វើចំណាកស្រុកទៅ Java 10 និងការផ្លាស់ប្តូរទៅម៉ូឌុល។

ការអភិវឌ្ឍន៍និងការធ្វើតេស្ត

នៅក្នុងដំណើរការនៃការបង្កើត និងសាកល្បង SV យើងបានជួបប្រទះនូវលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍មួយចំនួននៃផលិតផលដែលយើងប្រើ។

ផ្ទុកការធ្វើតេស្ត និងការលេចធ្លាយអង្គចងចាំ

ការចេញផ្សាយ SV នីមួយៗពាក់ព័ន្ធនឹងការធ្វើតេស្តផ្ទុក។ វាជោគជ័យនៅពេល៖

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

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

យើងអនុវត្តការធ្វើតេស្តផ្ទុកនៃប្រព័ន្ធអន្តរកម្មក្នុងការកំណត់រចនាសម្ព័ន្ធចំនួនបី៖

1. ការធ្វើតេស្តភាពតានតឹង
2. ការតភ្ជាប់តែប៉ុណ្ណោះ
3. ការចុះឈ្មោះអតិថិជន

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

ឧទាហរណ៍ នេះ​ជា​ផ្នែក​នៃ​ការ​ធ្វើ​តេស្ត​ស្ត្រេស​មើល​ទៅ​ដូច​ជា៖

• អ្នកប្រើប្រាស់ចូល
  • ស្នើសុំការពិភាក្សាដែលមិនទាន់អានរបស់អ្នក។
  • 50% ទំនងជាអានសារ
  • 50% ទំនងជានឹងផ្ញើសារ
  • អ្នកប្រើប្រាស់បន្ទាប់៖
    • មានឱកាស 20% ក្នុងការបង្កើតការពិភាក្សាថ្មី។
    • ជ្រើសរើសការពិភាក្សាណាមួយរបស់វាដោយចៃដន្យ
    • ចូលទៅខាងក្នុង
    • ស្នើសុំសារ ទម្រង់អ្នកប្រើប្រាស់
    • បង្កើតសារចំនួនប្រាំផ្ញើទៅកាន់អ្នកប្រើប្រាស់ចៃដន្យពីការពិភាក្សានេះ។
    • ទុកការពិភាក្សា
    • ធ្វើម្តងទៀត 20 ដង
    • ចេញ ត្រឡប់ទៅដើមស្គ្រីបវិញ។

  • chatbot ចូលទៅក្នុងប្រព័ន្ធ (ត្រាប់តាមការផ្ញើសារពីកូដកម្មវិធី)
    • មានឱកាស 50% នៃការបង្កើតឆានែលថ្មីសម្រាប់ការផ្លាស់ប្តូរទិន្នន័យ (ការពិភាក្សាពិសេស)
    • 50% ទំនងជាសរសេរសារទៅកាន់បណ្តាញណាមួយដែលមានស្រាប់

សេណារីយ៉ូ "ការតភ្ជាប់តែប៉ុណ្ណោះ" បានបង្ហាញខ្លួនសម្រាប់ហេតុផលមួយ។ មានស្ថានភាពមួយ៖ អ្នកប្រើប្រាស់បានភ្ជាប់ប្រព័ន្ធ ប៉ុន្តែមិនទាន់បានចូលរួម។ អ្នកប្រើប្រាស់ម្នាក់ៗបើកកុំព្យូទ័រនៅម៉ោង 09:00 ព្រឹក បង្កើតការតភ្ជាប់ទៅម៉ាស៊ីនមេ ហើយនៅស្ងៀម។ បុរសទាំងនេះមានគ្រោះថ្នាក់ មានពួកគេជាច្រើន - កញ្ចប់តែមួយគត់ដែលពួកគេមានគឺ PING/PONG ប៉ុន្តែពួកគេរក្សាការភ្ជាប់ទៅម៉ាស៊ីនមេ (ពួកគេមិនអាចរក្សាវាបានទេ - ចុះប្រសិនបើមានសារថ្មី) ។ ការធ្វើតេស្តនេះបង្កើតឡើងវិញនូវស្ថានភាពដែលអ្នកប្រើប្រាស់បែបនេះមួយចំនួនធំព្យាយាមចូលប្រព័ន្ធក្នុងរយៈពេលកន្លះម៉ោង។ វាស្រដៀងទៅនឹងការធ្វើតេស្តស្ត្រេស ប៉ុន្តែការផ្តោតអារម្មណ៍របស់វាច្បាស់ណាស់លើការបញ្ចូលដំបូងនេះ - ដើម្បីកុំឱ្យមានការបរាជ័យ (មនុស្សម្នាក់មិនប្រើប្រព័ន្ធ ហើយវាបានធ្លាក់ចុះរួចទៅហើយ - វាពិបាកក្នុងការគិតពីអ្វីដែលអាក្រក់ជាងនេះ) ។

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

យើងប្រើជាម៉ាស៊ីនបង្កើតបន្ទុក JMeter. វាមិនដឹងពីរបៀបធ្វើការជាមួយ websocket វាត្រូវការកម្មវិធីជំនួយ។ ដំបូងក្នុងលទ្ធផលស្វែងរកសម្រាប់សំណួរ "jmeter websocket" គឺ៖ អត្ថបទពី BlazeMeterដែលណែនាំ កម្មវិធីជំនួយដោយ Maciej Zaleski.

នោះហើយជាកន្លែងដែលយើងសម្រេចចិត្តចាប់ផ្តើម។

ស្ទើរតែភ្លាមៗបន្ទាប់ពីចាប់ផ្តើមការធ្វើតេស្តធ្ងន់ធ្ងរ យើងបានរកឃើញថា JMeter ចាប់ផ្តើមលេចធ្លាយការចងចាំ។

កម្មវិធីជំនួយគឺជារឿងធំដាច់ដោយឡែកមួយដែលមានផ្កាយ 176 វាមាន 132 សមនៅលើ github ។ អ្នកនិពន្ធខ្លួនឯងមិនបានប្តេជ្ញាចិត្តចំពោះវាទេចាប់តាំងពីឆ្នាំ 2015 (យើងបានយកវានៅឆ្នាំ 2015 បន្ទាប់មកវាមិនបង្កឱ្យមានការសង្ស័យទេ) បញ្ហា github ជាច្រើនទាក់ទងនឹងការលេចធ្លាយអង្គចងចាំ 7 សំណើទាញដែលមិនបិទ។
ប្រសិនបើអ្នកសម្រេចចិត្តធ្វើការធ្វើតេស្តផ្ទុកដោយប្រើកម្មវិធីជំនួយនេះ សូមយកចិត្តទុកដាក់លើការពិភាក្សាខាងក្រោម៖

1. នៅក្នុងបរិយាកាសពហុខ្សែ បញ្ជី LinkedList ធម្មតាត្រូវបានប្រើប្រាស់ ហើយលទ្ធផលគឺ NPE នៅក្នុងពេលដំណើរការ។ នេះអាចដោះស្រាយបានដោយការប្តូរទៅ ConcurrentLinkedDeque ឬដោយប្លុកដែលបានធ្វើសមកាលកម្ម។ យើងជ្រើសរើសជម្រើសដំបូងសម្រាប់ខ្លួនយើង (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. ការលេចធ្លាយអង្គចងចាំ; នៅពេលផ្តាច់ទំនាក់ទំនងព័ត៌មានការតភ្ជាប់មិនត្រូវបានលុបទេ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. នៅក្នុងរបៀបស្ទ្រីម (នៅពេលដែល websocket មិនត្រូវបានបិទនៅចុងបញ្ចប់នៃគំរូ ប៉ុន្តែត្រូវបានប្រើនៅពេលក្រោយនៅក្នុងផែនការ) លំនាំឆ្លើយតបមិនដំណើរការទេ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

នេះ​គឺ​ជា​ផ្នែក​មួយ​ក្នុង​ចំណោម​អ្នក​នៅ​លើ github។ អ្វីដែលយើងបានធ្វើ៖

1. បានយក ផ្លូវបំបែក Elyran Kogan (@elyrank) - វាដោះស្រាយបញ្ហា 1 និង 3
2. ដោះស្រាយបញ្ហា ២
3. បាន​ធ្វើ​បច្ចុប្បន្នភាព​ព្រលាន​ពី 9.2.14 ទៅ 9.3.12
4. ទម្រង់​កាលបរិច្ឆេទ​សាមញ្ញ​រុំ​ក្នុង ThreadLocal; SimpleDateFormat មិនមានសុវត្ថិភាពខ្សែស្រឡាយ ដែលនាំទៅដល់ NPE នៅពេលដំណើរការ
5. ជួសជុលការលេចធ្លាយអង្គចងចាំផ្សេងទៀត (ការតភ្ជាប់ត្រូវបានបិទមិនត្រឹមត្រូវនៅពេលផ្តាច់)

ហើយនៅតែហូរ!

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

ពីរថ្ងៃបានកន្លងផុតទៅ...

ឥឡូវនេះ Hazelcast កំពុងអស់ការចងចាំហើយ។ កំណត់ហេតុបានបង្ហាញថាបន្ទាប់ពីការធ្វើតេស្តពីរបីថ្ងៃ Hazelcast ចាប់ផ្តើមត្អូញត្អែរអំពីការខ្វះការចងចាំហើយបន្ទាប់ពីពេលខ្លះចង្កោមបានដួលរលំហើយថ្នាំងនៅតែបន្តស្លាប់ម្តងមួយៗ។ យើងបានភ្ជាប់ JVisualVM ទៅ hazelcast ហើយបានឃើញ "ការមើលឃើញកើនឡើង" - វាជាទៀងទាត់ហៅថា GC ប៉ុន្តែមិនអាចសម្អាតអង្គចងចាំបានទេ។

វាប្រែថានៅក្នុង hazelcast 3.4 នៅពេលលុបផែនទី / multiMap (map.destroy()) អង្គចងចាំមិនត្រូវបានដោះលែងទាំងស្រុងទេ៖

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

ឥឡូវនេះកំហុសត្រូវបានជួសជុលក្នុង 3.5 ប៉ុន្តែវាមានបញ្ហានៅពេលនោះ។ យើងបានបង្កើតផែនទីពហុផែនទីថ្មីដែលមានឈ្មោះថាមវន្ត ហើយបានលុបវាទៅតាមតក្កវិជ្ជារបស់យើង។ កូដមើលទៅដូចនេះ៖

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

ហៅទូរសព្ទ៖

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

multiMap ត្រូវបានបង្កើតឡើងសម្រាប់ការជាវនីមួយៗ ហើយត្រូវបានលុបនៅពេលដែលវាមិនត្រូវការ។ យើងបានសម្រេចចិត្តថាយើងនឹងចាប់ផ្តើមផែនទី សោនឹងជាឈ្មោះនៃការជាវ ហើយតម្លៃនឹងជាការកំណត់អត្តសញ្ញាណសម័យ (ពីនោះអ្នកអាចទទួលបានអត្តសញ្ញាណអ្នកប្រើប្រាស់ ប្រសិនបើចាំបាច់)។

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

តារាងបានប្រសើរឡើង។

តើយើងបានរៀនអ្វីទៀតអំពីការធ្វើតេស្តផ្ទុក?

1. JSR223 ចាំបាច់ត្រូវសរសេរជាចង្អូរ និងរួមបញ្ចូលឃ្លាំងសម្ងាត់ចងក្រង - វាលឿនជាង។ តំណភ្ជាប់.
2. ក្រាហ្វ Jmeter-Plugins ងាយស្រួលយល់ជាងក្រាហ្វិកស្តង់ដារ។ តំណភ្ជាប់.

អំពីបទពិសោធន៍របស់យើងជាមួយ Hazelcast

Hazelcast គឺជាផលិតផលថ្មីសម្រាប់ពួកយើង យើងបានចាប់ផ្តើមធ្វើការជាមួយវាពីកំណែ 3.4.1 ឥឡូវនេះម៉ាស៊ីនមេផលិតកម្មរបស់យើងកំពុងដំណើរការកំណែ 3.9.2 (នៅពេលសរសេរ កំណែចុងក្រោយបំផុតរបស់ Hazelcast គឺ 3.10)។

ការបង្កើតអត្តសញ្ញាណប័ណ្ណ

យើងចាប់ផ្តើមជាមួយនឹងលេខសម្គាល់ចំនួនគត់។ សូមស្រមៃថាយើងត្រូវការ Long មួយផ្សេងទៀតសម្រាប់អង្គភាពថ្មី។ លំដាប់នៅក្នុងមូលដ្ឋានទិន្នន័យគឺមិនសមរម្យ តារាងពាក់ព័ន្ធនឹងការបំបែក - វាប្រែថាមានសារ ID=1 ក្នុង DB1 និងសារ ID=1 ក្នុង DB2 អ្នកមិនអាចដាក់លេខសម្គាល់នេះនៅក្នុង Elasticsearch ឬនៅក្នុង Hazelcast បានទេ ប៉ុន្តែអ្វីដែលអាក្រក់បំផុតនោះគឺប្រសិនបើអ្នកចង់បញ្ចូលគ្នានូវទិន្នន័យពីមូលដ្ឋានទិន្នន័យពីរចូលទៅក្នុងមួយ (ឧទាហរណ៍ ការសម្រេចថាមូលដ្ឋានទិន្នន័យមួយគឺគ្រប់គ្រាន់សម្រាប់អតិថិជនទាំងនេះ)។ អ្នកអាចបន្ថែម AtomicLongs ជាច្រើនទៅ Hazelcast ហើយរក្សាបញ្ជរនៅទីនោះ បន្ទាប់មកការអនុវត្តនៃការទទួលបានលេខសម្គាល់ថ្មីគឺកើនឡើងហើយទទួលបាន បូកនឹងពេលវេលាសម្រាប់ការស្នើសុំទៅ Hazelcast ។ ប៉ុន្តែ Hazelcast មានអ្វីដែលល្អបំផុត - FlakeIdGenerator ។ នៅពេលទាក់ទងអតិថិជននីមួយៗ ពួកគេត្រូវបានផ្តល់ជួរលេខសម្គាល់ ឧទាហរណ៍ ទីមួយ - ពី 1 ដល់ 10, ទីពីរ - ពី 000 ដល់ 10 ហើយដូច្នេះនៅលើ។ ឥឡូវនេះ អតិថិជនអាចចេញឧបករណ៍កំណត់អត្តសញ្ញាណថ្មីដោយខ្លួនឯងរហូតដល់ជួរដែលចេញឱ្យវាបញ្ចប់។ វាដំណើរការយ៉ាងឆាប់រហ័ស ប៉ុន្តែនៅពេលអ្នកចាប់ផ្តើមកម្មវិធីឡើងវិញ (និងម៉ាស៊ីនភ្ញៀវ Hazelcast) លំដាប់ថ្មីមួយនឹងចាប់ផ្តើម - ដូច្នេះការរំលង។ល។ លើសពីនេះទៀត អ្នកអភិវឌ្ឍន៍ពិតជាមិនយល់ពីមូលហេតុដែលលេខសម្គាល់មានចំនួនគត់ ប៉ុន្តែមានភាពមិនស៊ីសង្វាក់គ្នា។ យើងបានថ្លឹងអ្វីៗគ្រប់យ៉ាង ហើយប្តូរទៅ UUIDs។

និយាយអីញ្ចឹងសម្រាប់អ្នកដែលចង់ធ្វើដូច Twitter មានបណ្ណាល័យ Snowcast បែបនេះ - នេះគឺជាការអនុវត្ត Snowflake នៅលើ Hazelcast ។ អ្នកអាចមើលវានៅទីនេះ៖

github.com/noctarius/snowcast
github.com/twitter/snowflake

ប៉ុន្តែ​យើង​មិន​បាន​ទៅ​ជិត​វា​ទៀត​ទេ។

TransactionalMap.replace

ការភ្ញាក់ផ្អើលមួយទៀត៖ TransactionalMap.replace មិនដំណើរការទេ។ នេះជាការសាកល្បង៖

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

ខ្ញុំត្រូវសរសេរជំនួសខ្លួនឯងដោយប្រើ getForUpdate៖

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

សាកល្បងមិនត្រឹមតែរចនាសម្ព័ន្ធទិន្នន័យធម្មតាប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងកំណែប្រតិបត្តិការរបស់ពួកគេផងដែរ។ វាកើតឡើងដែល IMap ដំណើរការ ប៉ុន្តែ TransactionalMap លែងមានទៀតហើយ។

បញ្ចូល JAR ថ្មី​ដោយ​គ្មាន​ពេល​សម្រាក

ដំបូង យើងបានសម្រេចចិត្តកត់ត្រាវត្ថុនៃថ្នាក់របស់យើងនៅក្នុង Hazelcast ។ ឧទាហរណ៍ យើងមានថ្នាក់ Application យើងចង់រក្សាទុក និងអានវា។ រក្សាទុក៖

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

យើងអានថា:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

អ្វីគ្រប់យ៉ាងកំពុងដំណើរការ។ បន្ទាប់មកយើងបានសម្រេចចិត្តបង្កើតលិបិក្រមនៅក្នុង Hazelcast ដើម្បីស្វែងរកដោយ៖

map.addIndex("subscriberId", false);

ហើយនៅពេលសរសេរអង្គភាពថ្មី ពួកគេបានចាប់ផ្តើមទទួល ClassNotFoundException។ Hazelcast បានព្យាយាមបន្ថែមទៅក្នុងលិបិក្រម ប៉ុន្តែមិនដឹងអ្វីទាំងអស់អំពីថ្នាក់របស់យើង ហើយចង់ឱ្យ JAR ដែលមានថ្នាក់នេះត្រូវបានផ្គត់ផ្គង់ទៅវា។ យើងធ្វើបានប៉ុណ្ណឹង អ្វីៗដំណើរការបាន ប៉ុន្តែបញ្ហាថ្មីមួយបានលេចចេញមក៖ របៀបអាប់ដេត JAR ដោយមិនបញ្ឈប់ចង្កោមទាំងស្រុង? Hazelcast មិនយក JAR ថ្មីកំឡុងពេលអាប់ដេត node-by-node ទេ។ នៅចំណុចនេះ យើងបានសម្រេចចិត្តថាយើងអាចរស់នៅដោយមិនចាំបាច់ស្វែងរកលិបិក្រម។ យ៉ាងណាមិញ ប្រសិនបើអ្នកប្រើ Hazelcast ជាឃ្លាំងតម្លៃសំខាន់ នោះអ្វីៗនឹងដំណើរការមែនទេ? មិន​ប្រាកដ​ទេ។ នៅទីនេះម្តងទៀត ឥរិយាបថរបស់ IMap និង TransactionalMap គឺខុសគ្នា។ កន្លែងដែល IMap មិនខ្វល់ TransactionalMap បោះកំហុស។

IMap យើងសរសេរវត្ថុចំនួន 5000 អានវា។ អ្វីគ្រប់យ៉ាងត្រូវបានរំពឹងទុក។

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

ប៉ុន្តែវាមិនដំណើរការក្នុងប្រតិបត្តិការទេ យើងទទួលបាន ClassNotFoundException៖

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

នៅក្នុង 3.8 យន្តការដាក់ឱ្យប្រើប្រាស់ថ្នាក់អ្នកប្រើប្រាស់បានបង្ហាញខ្លួន។ អ្នកអាចកំណត់ឈ្មោះមេមួយ និងធ្វើបច្ចុប្បន្នភាពឯកសារ JAR នៅលើវា។

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

របៀបដែលយើងធានាបាននូវប្រសិទ្ធភាពខ្ពស់។

ការធ្វើដំណើរបួនទៅ Hazelcast - ល្អ ពីរទៅមូលដ្ឋានទិន្នន័យ - អាក្រក់

ការចូលទៅកាន់ឃ្លាំងសម្ងាត់សម្រាប់ទិន្នន័យគឺតែងតែប្រសើរជាងការចូលទៅកាន់មូលដ្ឋានទិន្នន័យ ប៉ុន្តែអ្នកក៏មិនចង់រក្សាទុកកំណត់ត្រាដែលមិនប្រើផងដែរ។ យើងទុកការសម្រេចចិត្តអំពីអ្វីដែលត្រូវទុកក្នុងឃ្លាំងរហូតដល់ដំណាក់កាលចុងក្រោយនៃការអភិវឌ្ឍន៍។ នៅពេលដែលមុខងារថ្មីត្រូវបានសរសេរកូដ យើងបើកការកត់ត្រាសំណួរទាំងអស់នៅក្នុង PostgreSQL (log_min_duration_statement ទៅ 0) ហើយដំណើរការការធ្វើតេស្តផ្ទុករយៈពេល 20 នាទី។ ដោយប្រើកំណត់ហេតុដែលបានប្រមូល ឧបករណ៍ប្រើប្រាស់ដូចជា pgFouine និង pgBadger អាចបង្កើតរបាយការណ៍វិភាគបាន។ នៅក្នុងរបាយការណ៍ យើងស្វែងរកសំណួរយឺត និងញឹកញាប់ជាចម្បង។ សម្រាប់សំណួរយឺត យើងបង្កើតផែនការប្រតិបត្តិ (ពន្យល់) ហើយវាយតម្លៃថាតើសំណួរបែបនេះអាចត្រូវបានពន្លឿនដែរឬទេ។ សំណើញឹកញាប់សម្រាប់ទិន្នន័យបញ្ចូលដូចគ្នាសមល្អទៅក្នុងឃ្លាំងសម្ងាត់។ យើងព្យាយាមរក្សាសំណួរ "រាបស្មើ" មួយតារាងក្នុងមួយសំណួរ។

ប្រតិបត្តិការ។

SV ជាសេវាកម្មអនឡាញត្រូវបានដាក់ឱ្យដំណើរការនៅនិទាឃរដូវឆ្នាំ 2017 ហើយជាផលិតផលដាច់ដោយឡែក SV ត្រូវបានចេញផ្សាយនៅខែវិច្ឆិកា ឆ្នាំ 2017 (នៅពេលនោះនៅក្នុងស្ថានភាពកំណែបែតា)។

ក្នុងរយៈពេលជាងមួយឆ្នាំនៃប្រតិបត្តិការនេះ មិនមានបញ្ហាធ្ងន់ធ្ងរនៅក្នុងប្រតិបត្តិការនៃសេវាកម្មអនឡាញ CB ទេ។ យើងត្រួតពិនិត្យសេវាអនឡាញតាមរយៈ Zabbixប្រមូលនិងដាក់ពង្រាយពី ឫស្សី.

ការចែកចាយម៉ាស៊ីនមេ SV ត្រូវបានផ្គត់ផ្គង់ជាទម្រង់កញ្ចប់ដើម៖ RPM, DEB, MSI ។ បូកសម្រាប់ Windows យើងផ្តល់កម្មវិធីដំឡើងតែមួយក្នុងទម្រង់នៃ EXE តែមួយដែលដំឡើង server, Hazelcast និង Elasticsearch នៅលើម៉ាស៊ីនតែមួយ។ ដំបូងឡើយ យើងបានសំដៅទៅលើកំណែនៃការដំឡើងនេះថាជាកំណែ "សាកល្បង" ប៉ុន្តែឥឡូវនេះវាបានក្លាយទៅជាច្បាស់ថានេះគឺជាជម្រើសនៃការដាក់ពង្រាយដ៏ពេញនិយមបំផុត។

ប្រភព: www.habr.com