Kami ialah jabatan pembangunan teknologi bagi rangkaian runcit. Pada suatu hari, pihak pengurusan menetapkan tugas untuk mempercepatkan pengiraan berskala besar dengan menggunakan Apache Ignite bersama-sama dengan MSSQL, dan menunjukkan laman web dengan ilustrasi yang cantik dan contoh kod Java. Saya segera menyukai tapak tersebut , perihalan yang menjanjikan keajaiban: anda tidak perlu menggunakan kod Java atau Scala anda secara manual pada setiap nod dalam grid dan gunakan semula setiap kali ia berubah. Semasa kerja berjalan, ternyata Zero Deployment mempunyai kegunaan khusus, ciri yang ingin saya kongsikan. Di bawah potongan adalah butiran pemikiran dan pelaksanaan.
1. Pernyataan masalah
Intipati tugasan adalah seperti berikut. Terdapat direktori SalesPoint tempat jualan dan direktori produk Sku (Unit Penyimpan Stok). Tempat jualan mempunyai atribut "Jenis kedai" dengan nilai "kecil" dan "besar". Pelbagai (senarai produk tempat jualan) disambungkan kepada setiap tempat jualan (dimuat daripada DBMS) dan maklumat disediakan bahawa dari tarikh yang ditentukan produk yang ditentukan
dikecualikan daripada pelbagai atau ditambah kepada pelbagai.
Ia dikehendaki menyusun cache tempat jualan yang dibahagikan dan menyimpan di dalamnya maklumat tentang produk yang disambungkan selama sebulan lebih awal. Keserasian dengan sistem pertempuran memerlukan nod klien Ignite untuk memuatkan data, mengira agregat borang (Jenis kedai, Kod Produk, hari, bilangan_mata_jualan) dan memuat naiknya kembali ke DBMS.
2. Kajian sastera
Saya belum mempunyai pengalaman, jadi saya mula menari dari dapur. Iaitu, daripada semakan penerbitan.
Perkara 2016 mengandungi pautan ke dokumentasi projek Apache Ignite dan pada masa yang sama celaan untuk kekaburan dokumentasi ini. Saya membacanya semula beberapa kali, kejelasan tidak datang. Saya merujuk kepada tutorial rasmi Yang
optimis menjanjikan "Anda akan bangun dan berlari dalam sekejap!" Saya sedang memikirkan tetapan pembolehubah persekitaran, menonton dua video Apache Ignite Essentials, tetapi mereka tidak begitu berguna untuk tugas khusus saya. Saya berjaya melancarkan Ignite dari baris arahan dengan fail standard "example-ignite.xml", membina aplikasi pertama menggunakan Maven. Aplikasi ini berfungsi dan menggunakan Zero Deployment, sungguh cantik!
Saya membaca lebih lanjut, dan di sana contoh segera menggunakan affinityKey (dicipta lebih awal melalui pertanyaan SQL), dan juga menggunakan BinaryObject yang misterius:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); saya dah baca ia : format binari - sesuatu seperti refleksi, mengakses medan objek mengikut nama. Boleh membaca nilai medan tanpa menyahsiri objek sepenuhnya (menjimatkan ingatan). Tetapi mengapa BinaryObject digunakan dan bukannya Person, kerana terdapat Zero Deployment? Mengapa IgniteCache dipindahkan ke IgniteCache ? Belum jelas lagi.
Saya membuat semula Aplikasi Pengiraan untuk disesuaikan dengan kes saya. Kunci utama direktori tempat jualan dalam MSSQL ditakrifkan sebagai [id] [int] NOT NULL, saya mencipta cache dengan analogi
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Dalam konfigurasi xml saya menunjukkan bahawa cache dipisahkan
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Pembahagian mengikut tempat jualan menganggap bahawa agregat yang diperlukan akan dibina pada setiap nod kluster untuk rekod salesPointCache yang tersedia di sana, selepas itu nod pelanggan akan melakukan penjumlahan akhir.
Saya sedang membaca tutorial , saya melakukannya dengan analogi. Pada setiap nod kluster saya menjalankan IgniteRunnable(), seperti ini:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Saya menambah pengagregatan dan memuat naik logik dan menjalankannya pada set data ujian. Semuanya berfungsi secara tempatan pada pelayan pembangunan.
Saya melancarkan dua pelayan ujian CentOs, nyatakan alamat IP dalam default-config.xml, laksanakan pada setiap
./bin/ignite.sh config/default-config.xmlKedua-dua nod Ignite sedang berjalan dan boleh melihat satu sama lain. Saya menyatakan alamat yang diperlukan dalam konfigurasi xml aplikasi klien, ia bermula, menambah nod ketiga pada topologi dan serta-merta terdapat dua nod lagi. Log menunjukkan "ClassNotFoundException: model.SalesPoint" dalam baris
SalesPoint sp=salesPointCache.get(spId);StackOverflow mengatakan bahawa sebab ralat adalah kerana tiada kelas SalesPoint tersuai pada pelayan CentOs. Kami dah sampai. Bagaimana pula dengan "anda tidak perlu menggunakan kod Java anda secara manual pada setiap nod" dan seterusnya? Atau adakah "kod Java anda" bukan mengenai SalesPoint?
Saya mungkin terlepas sesuatu - saya mula mencari lagi, membaca dan mencari lagi. Selepas beberapa ketika, saya mendapat perasaan bahawa saya telah membaca semua tentang topik itu, tidak ada yang baru lagi. Semasa saya mencari, saya menemui beberapa komen yang menarik.
, Arkitek Utama di GridGain Systems, pada StackOverflow, April 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.Pendapat lain yang berwibawa: , Pengarah pengurusan produk, GridGain Systems.
Artikel tentang HabrΓ© merujuk tiga artikel oleh Denis Magda: , , 2016-2017. Dalam artikel kedua, Denis mencadangkan memulakan nod kluster melalui MaintenanceServiceNodeStartup.jar. Anda juga boleh menggunakan pelancaran dengan konfigurasi xml dan baris arahan, tetapi kemudian anda perlu meletakkan kelas tersuai secara manual pada setiap nod kluster yang digunakan:
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.Memang itu sahaja. Di sini ternyata, mengapa, format binari misteri ini!
3.SingleJar
Denis mendapat tempat pertama dalam penilaian peribadi saya, IMHO tutorial yang paling berguna daripada semua yang ada. Dalam dia Github mengandungi contoh sedia sepenuhnya untuk menyediakan nod kluster, yang menyusun tanpa sebarang mencangkung tambahan.
Saya melakukannya dengan cara yang sama dan mendapatkan satu fail balang yang melancarkan "nod data" atau "nod pelanggan" bergantung pada hujah baris arahan. Perhimpunan bermula dan berfungsi. Zero Deployment telah dikalahkan.
Peralihan daripada megabait data ujian kepada berpuluh gigabait data pertempuran menunjukkan bahawa format binari wujud atas sebab tertentu. Ia adalah perlu untuk mengoptimumkan penggunaan memori pada nod, dan di sinilah BinaryObject ternyata sangat berguna.
4. Kesimpulan
Celaan pertama yang dihadapi mengenai kekaburan dokumentasi projek Apache Ignite ternyata adil; sedikit yang berubah sejak 2016. Bukan mudah bagi pemula untuk memasang prototaip yang berfungsi berdasarkan tapak web dan/atau repositori.
Berdasarkan hasil kerja yang dilakukan, tanggapan adalah bahawa Zero Deployment berfungsi, tetapi hanya pada peringkat sistem. Sesuatu seperti ini: BinaryObject digunakan untuk mengajar nod kluster jauh untuk berfungsi dengan kelas tersuai; Penggunaan Sifar - mekanisme dalaman
Apache Ignite sendiri dan mengedarkan objek sistem ke seluruh kelompok.
Saya harap pengalaman saya akan berguna kepada pengguna Apache Ignite baharu.
Sumber: www.habr.com