ការដាក់ពង្រាយ Apache Ignite Zero៖ ពិតជាសូន្យមែនទេ?

យើងជាផ្នែកអភិវឌ្ឍន៍បច្ចេកវិទ្យានៃបណ្តាញលក់រាយ។ ថ្ងៃមួយ អ្នកគ្រប់គ្រងកំណត់ភារកិច្ចបង្កើនល្បឿននៃការគណនាខ្នាតធំដោយប្រើ Apache Ignite រួមជាមួយនឹង MSSQL ហើយបានបង្ហាញគេហទំព័រមួយដែលមានរូបភាពស្អាតៗ និងឧទាហរណ៍នៃកូដ Java ។ ខ្ញុំចូលចិត្តគេហទំព័រនេះភ្លាមៗ ការដាក់ពង្រាយសូន្យការពិពណ៌នាដែលសន្យាថាមានអព្ភូតហេតុ៖ អ្នកមិនចាំបាច់ដាក់កូដ Java ឬ Scala ដោយដៃនៅលើថ្នាំងនីមួយៗក្នុងក្រឡាចត្រង្គ ហើយដាក់ពង្រាយវាឡើងវិញរាល់ពេលដែលវាផ្លាស់ប្តូរ។ នៅពេលដែលការងាររីកចម្រើន វាបានបង្ហាញថា Zero Deployment មានការប្រើប្រាស់ជាក់លាក់ លក្ខណៈពិសេសដែលខ្ញុំចង់ចែករំលែក។ ខាងក្រោមការកាត់គឺជាគំនិត និងព័ត៌មានលម្អិតនៃការអនុវត្ត។

1. សេចក្តីថ្លែងការណ៍អំពីបញ្ហា

ខ្លឹមសារនៃបញ្ហាមានដូចខាងក្រោម។ មានបញ្ជីរាយបញ្ជីចំណុចលក់ SalesPoint និងបញ្ជីផលិតផល Sku (Stock Keeping Unit)។ ចំណុចនៃការលក់មានគុណលក្ខណៈ "ប្រភេទហាង" ជាមួយនឹងតម្លៃ "តូច" និង "ធំ" ។ ការចាត់ថ្នាក់ (បញ្ជីផលិតផលនៃចំណុចលក់) ត្រូវបានភ្ជាប់ទៅនឹងចំណុចលក់នីមួយៗ (ផ្ទុកពី DBMS) ហើយព័ត៌មានត្រូវបានផ្តល់ឱ្យថាចាប់ពីកាលបរិច្ឆេទដែលបានបញ្ជាក់ផលិតផលដែលបានបញ្ជាក់។
មិនរាប់បញ្ចូលពីការចាត់ថ្នាក់ ឬបន្ថែមទៅការចាត់ថ្នាក់។

វាត្រូវបានទាមទារដើម្បីរៀបចំឃ្លាំងសម្ងាត់ដែលបានបែងចែកនៃចំណុចលក់ និងរក្សាទុកព័ត៌មានអំពីផលិតផលដែលបានតភ្ជាប់សម្រាប់រយៈពេលមួយខែជាមុន។ ភាពឆបគ្នាជាមួយប្រព័ន្ធប្រយុទ្ធតម្រូវឱ្យថ្នាំងម៉ាស៊ីនភ្ញៀវ Ignite ដើម្បីផ្ទុកទិន្នន័យ គណនាការប្រមូលផ្តុំនៃទម្រង់បែបបទ (ប្រភេទហាង លេខកូដផលិតផល ថ្ងៃ លេខ_of_sales_points) ហើយបញ្ចូលវាត្រឡប់ទៅ DBMS វិញ។

2. ការសិក្សាអក្សរសិល្ប៍

ខ្ញុំមិនទាន់មានបទពិសោធន៍ទេ ដូច្នេះខ្ញុំចាប់ផ្តើមរាំពីចង្ក្រាន។ នោះគឺពីការពិនិត្យឡើងវិញនៃការបោះពុម្ពផ្សាយ។

មាត្រា 2016 ការណែនាំ Apache Ignite៖ ជំហានដំបូង មានតំណភ្ជាប់ទៅកាន់ឯកសារនៃគម្រោង Apache Ignite ហើយនៅពេលជាមួយគ្នានោះមានការស្តីបន្ទោសចំពោះភាពមិនច្បាស់លាស់នៃឯកសារនេះ។ ខ្ញុំអានឡើងវិញពីរបីដង ភាពច្បាស់លាស់មិនមកទេ។ ខ្ញុំយោងទៅការបង្រៀនផ្លូវការ ការចាប់ផ្តើម, ដែល
សន្យាដោយសុទិដ្ឋិនិយមថា "អ្នកនឹងក្រោកឡើងហើយរត់យ៉ាងស្វាហាប់!" ខ្ញុំកំពុងស្វែងរកការកំណត់អថេរបរិស្ថាន ដោយមើលវីដេអូ Apache Ignite Essentials ចំនួនពីរ ប៉ុន្តែវាមិនមានប្រយោជន៍សម្រាប់កិច្ចការជាក់លាក់របស់ខ្ញុំទេ។ ខ្ញុំបើកដំណើរការ Ignite ដោយជោគជ័យពីបន្ទាត់ពាក្យបញ្ជាជាមួយនឹងឯកសារស្តង់ដារ “example-ignite.xml” ដោយបង្កើតកម្មវិធីដំបូង កម្មវិធីគណនា ដោយប្រើ Maven ។ កម្មវិធីដំណើរការ និងប្រើប្រាស់ Zero Deployment ពិតជាស្រស់ស្អាតមែន!

ខ្ញុំបានអានបន្ថែម ហើយនៅទីនោះឧទាហរណ៍ភ្លាមៗប្រើ affinityKey (បង្កើតមុនតាមរយៈសំណួរ SQL) ហើយថែមទាំងប្រើ BinaryObject អាថ៌កំបាំង៖

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

ខ្ញុំ​អាន​វា បន្តិច៖ ទ្រង់ទ្រាយគោលពីរ - អ្វីមួយដូចជាការឆ្លុះបញ្ចាំង ការចូលប្រើវាលនៃវត្ថុតាមឈ្មោះ។ អាច​អាន​តម្លៃ​នៃ​វាល​មួយ​ដោយ​មិន​ចាំបាច់​បំផ្លាញ​វត្ថុ​ទាំងស្រុង (រក្សា​ទុក​ការ​ចងចាំ)។ ប៉ុន្តែហេតុអ្វីបានជា BinaryObject ប្រើជំនួស Person ចាប់តាំងពីមាន Zero Deployment? ហេតុអ្វីបានជា IgniteCache ផ្ទេរទៅ IgniteCache ? វាមិនទាន់ច្បាស់នៅឡើយទេ។

ខ្ញុំកំពុងបង្កើតកម្មវិធីកុំព្យូទ័រឡើងវិញ ដើម្បីឲ្យសមនឹងករណីរបស់ខ្ញុំ។ គន្លឹះសំខាន់នៃថតចំណុចលក់ក្នុង MSSQL ត្រូវបានកំណត់ជា [id] [int] NOT NULL ខ្ញុំបង្កើតឃ្លាំងសម្ងាត់ដោយភាពស្រដៀងគ្នា

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

នៅក្នុងការកំណត់ xml ខ្ញុំបង្ហាញថាឃ្លាំងសម្ងាត់ត្រូវបានបែងចែក

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

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

ខ្ញុំកំពុងអានមេរៀន កម្មវិធី Ignite Compute ដំបូង, ខ្ញុំធ្វើវាដោយការប្រៀបធៀប។ នៅលើថ្នាំងចង្កោមនីមួយៗ ខ្ញុំដំណើរការ IgniteRunnable() អ្វីមួយដូចនេះ៖

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

ខ្ញុំបន្ថែមការប្រមូលផ្តុំ និងការបង្ហោះតក្កវិជ្ជា ហើយដំណើរការវានៅលើសំណុំទិន្នន័យសាកល្បង។ អ្វីគ្រប់យ៉ាងដំណើរការក្នុងមូលដ្ឋាននៅលើម៉ាស៊ីនមេអភិវឌ្ឍន៍។

ខ្ញុំបើកដំណើរការម៉ាស៊ីនមេសាកល្បង CentOs ពីរ បញ្ជាក់អាសយដ្ឋាន IP ក្នុង default-config.xml ប្រតិបត្តិលើនីមួយៗ

./bin/ignite.sh config/default-config.xml

ថ្នាំង Ignite ទាំងពីរកំពុងដំណើរការ ហើយអាចមើលឃើញគ្នាទៅវិញទៅមក។ ខ្ញុំបញ្ជាក់អាសយដ្ឋានដែលត្រូវការនៅក្នុង xml config នៃកម្មវិធីអតិថិជន វាចាប់ផ្តើម បន្ថែមថ្នាំងទីបីទៅ topology ហើយភ្លាមៗនោះមានថ្នាំងពីរម្តងទៀត។ កំណត់ហេតុបង្ហាញ “ClassNotFoundException: model.SalesPoint” នៅក្នុងបន្ទាត់

SalesPoint sp=salesPointCache.get(spId);

StackOverflow និយាយថាហេតុផលសម្រាប់កំហុសគឺថាមិនមានថ្នាក់ SalesPoint ផ្ទាល់ខ្លួននៅលើម៉ាស៊ីនមេ CentOs ទេ។ យើង​បាន​មក​ដល់។ តើធ្វើដូចម្តេចអំពី "អ្នកមិនចាំបាច់ប្រើកូដ Java របស់អ្នកដោយដៃនៅលើថ្នាំងនីមួយៗ" ហើយដូច្នេះនៅលើ? ឬ "កូដ Java របស់អ្នក" មិនមែនអំពី SalesPoint ទេ?

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

Valentin Kulichenko, ស្ថាបត្យករនាំមុខនៅប្រព័ន្ធ GridGain, ចម្លើយ នៅលើ StackOverflow, ខែមេសា 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

មតិ​មាន​សិទ្ធិ​អំណាច​មួយ​ផ្សេង​ទៀត​: ដេនីស ម៉ាដា, នាយកគ្រប់គ្រងផលិតផល, ប្រព័ន្ធ GridGain ។

អត្ថបទអំពី Habre អំពីសេវាមីក្រូ យោងអត្ថបទបីដោយ Denis Magda: សេវាមីក្រូផ្នែក I, សេវាមីក្រូផ្នែកទី II, សេវាមីក្រូផ្នែក III ២០១៦-២០១៧។ នៅក្នុងអត្ថបទទីពីរ Denis ស្នើឱ្យចាប់ផ្តើមថ្នាំងចង្កោមតាមរយៈ MaintenanceServiceNodeStartup.jar ។ អ្នកក៏អាចប្រើការបើកដំណើរការជាមួយការកំណត់រចនាសម្ព័ន្ធ xml និងបន្ទាត់ពាក្យបញ្ជា ប៉ុន្តែបន្ទាប់មកអ្នកត្រូវដាក់ថ្នាក់ផ្ទាល់ខ្លួនដោយដៃនៅលើថ្នាំងចង្កោមនីមួយៗដែលបានដាក់ពង្រាយ៖

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

ជាការពិត នោះហើយជាវា។ នៅទីនេះវាប្រែចេញ ហេតុអ្វីបានជាទម្រង់គោលពីរដ៏អាថ៌កំបាំងនេះ!

3.SingleJar

Denis បានជាប់ចំណាត់ថ្នាក់លេខ XNUMX ក្នុងការវាយតម្លៃផ្ទាល់ខ្លួនរបស់ខ្ញុំ IMHO ការបង្រៀនដែលមានប្រយោជន៍បំផុតដែលមានទាំងអស់។ នៅក្នុងរបស់គាត់។ សេវាកម្មខ្នាតតូចឧទាហរណ៍ Github មានឧទាហរណ៍ដែលត្រៀមរួចជាស្រេចទាំងស្រុងនៃការដំឡើងថ្នាំងចង្កោម ដែលចងក្រងដោយមិនមានការអង្គុយបន្ថែម។

ខ្ញុំធ្វើវាតាមរបៀបដូចគ្នា ហើយទទួលបានឯកសារ jar តែមួយដែលបើកដំណើរការ "ថ្នាំងទិន្នន័យ" ឬ "ថ្នាំងអតិថិជន" អាស្រ័យលើអាគុយម៉ង់បន្ទាត់ពាក្យបញ្ជា។ ការជួបប្រជុំគ្នាចាប់ផ្តើមនិងដំណើរការ។ ការដាក់ពង្រាយសូន្យត្រូវបានបរាជ័យ។

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

4 - សេចក្តី​សន្និដ្ឋាន

ការតិះដៀលដំបូងដែលបានជួបប្រទះអំពីភាពមិនច្បាស់លាស់នៃឯកសារគម្រោង Apache Ignite ប្រែទៅជាមានភាពយុត្តិធម៌ មានការផ្លាស់ប្តូរតិចតួចចាប់តាំងពីឆ្នាំ 2016 ។ វាមិនងាយស្រួលទេសម្រាប់អ្នកចាប់ផ្តើមដំបូងក្នុងការប្រមូលផ្តុំគំរូមុខងារដោយផ្អែកលើគេហទំព័រ និង/ឬឃ្លាំង។

ដោយផ្អែកលើលទ្ធផលនៃការងារដែលបានធ្វើ ការចាប់អារម្មណ៍គឺថា Zero Deployment ដំណើរការ ប៉ុន្តែមានតែនៅកម្រិតប្រព័ន្ធប៉ុណ្ណោះ។ អ្វីមួយដូចនេះ៖ BinaryObject ត្រូវបានប្រើដើម្បីបង្រៀនថ្នាំងចង្កោមពីចម្ងាយដើម្បីធ្វើការជាមួយថ្នាក់ផ្ទាល់ខ្លួន។ ការដាក់ពង្រាយសូន្យ - យន្តការផ្ទៃក្នុង
Apache Ignite ខ្លួនវា ហើយចែកចាយវត្ថុប្រព័ន្ធទូទាំងចង្កោម។

ខ្ញុំសង្ឃឹមថាបទពិសោធន៍របស់ខ្ញុំនឹងមានប្រយោជន៍ចំពោះអ្នកប្រើប្រាស់ Apache Ignite ថ្មី។

ប្រភព: www.habr.com