Είμαστε το τμήμα ανάπτυξης τεχνολογίας ενός δικτύου λιανικής. Μια μέρα, η διοίκηση έθεσε το καθήκον να επιταχύνει τους υπολογισμούς μεγάλης κλίμακας χρησιμοποιώντας το Apache Ignite σε συνδυασμό με το MSSQL και έδειξε έναν ιστότοπο με όμορφες εικόνες και παραδείγματα κώδικα Java. Μου άρεσε αμέσως ο ιστότοπος , η περιγραφή του οποίου υπόσχεται θαύματα: δεν χρειάζεται να αναπτύσσετε με μη αυτόματο τρόπο τον κώδικα Java ή Scala σε κάθε κόμβο του πλέγματος και να τον αναπτύσσετε εκ νέου κάθε φορά που αλλάζει. Καθώς προχωρούσε η εργασία, αποδείχθηκε ότι το Zero Deployment έχει συγκεκριμένες χρήσεις, τις δυνατότητες των οποίων θέλω να μοιραστώ. Κάτω από την περικοπή υπάρχουν σκέψεις και λεπτομέρειες εφαρμογής.
1. Δήλωση του προβλήματος
Η ουσία του προβλήματος είναι η εξής. Υπάρχει ένας κατάλογος σημείων πωλήσεων SalesPoint και ένας κατάλογος προϊόντων Sku (Μονάδα Διατήρησης Αποθεμάτων). Το σημείο πώλησης έχει ένα χαρακτηριστικό "Store type" με τις τιμές "small" και "large". Μια συλλογή (κατάλογος προϊόντων του σημείου πώλησης) συνδέεται με κάθε σημείο πώλησης (φορτωμένη από το DBMS) και παρέχονται πληροφορίες ότι από την καθορισμένη ημερομηνία το συγκεκριμένο προϊόν
εξαιρούνται από τη συλλογή ή προστίθενται στην ποικιλία.
Απαιτείται να οργανώσετε μια χωρισμένη κρυφή μνήμη σημείων πώλησης και να αποθηκεύσετε σε αυτήν πληροφορίες σχετικά με συνδεδεμένα προϊόντα για ένα μήνα εκ των προτέρων. Η συμβατότητα με το σύστημα μάχης απαιτεί από τον κόμβο πελάτη Ignite να φορτώσει δεδομένα, να υπολογίσει ένα άθροισμα της φόρμας (τύπος καταστήματος, κωδικός προϊόντος, ημέρα, αριθμός_σημείων_πώλησης) και να το ανεβάσει ξανά στο DBMS.
2. Μελέτη λογοτεχνίας
Δεν έχω εμπειρία ακόμα, οπότε αρχίζω να χορεύω από τη σόμπα. Δηλαδή από ανασκόπηση δημοσιεύσεων.
Άρθρο 2016 περιέχει έναν σύνδεσμο προς την τεκμηρίωση του έργου Apache Ignite και ταυτόχρονα μια μομφή για την ασάφεια αυτής της τεκμηρίωσης. Το ξαναδιάβασα μια-δυο φορές, η σαφήνεια δεν έρχεται. Αναφέρομαι στο επίσημο tutorial Ο οποίος
υπόσχεται αισιόδοξα «Θα είστε έτοιμοι και θα έρθετε γρήγορα!» Ανακαλύπτω τις ρυθμίσεις της μεταβλητής περιβάλλοντος, παρακολουθώ δύο βίντεο 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 που είναι διαθέσιμες εκεί, μετά από το οποίο ο κόμβος πελάτη θα εκτελέσει την τελική άθροιση.
Διαβάζω το σεμινάριο , το κάνω κατ' αναλογία. Σε κάθε κόμβο συμπλέγματος εκτελώ την 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 της εφαρμογής πελάτη, ξεκινάει, προσθέτει έναν τρίτο κόμβο στην τοπολογία και αμέσως υπάρχουν πάλι δύο κόμβοι. Το αρχείο καταγραφής εμφανίζει "ClassNotFoundException: model.SalesPoint" στη γραμμή
SalesPoint sp=salesPointCache.get(spId);Το StackOverflow λέει ότι ο λόγος για το σφάλμα είναι ότι δεν υπάρχει προσαρμοσμένη κλάση SalesPoint σε διακομιστές CentOs. Φτάσαμε. Τι θα λέγατε για το "δεν χρειάζεται να αναπτύξετε χειροκίνητα τον κώδικα Java σας σε κάθε κόμβο" και ούτω καθεξής; Ή μήπως ο "κώδικάς σας Java" δεν αφορά το SalesPoint;
Μάλλον κάτι έχασα - ξαναρχίζω να ψάχνω, να διαβάζω και να ψάχνω ξανά. Μετά από λίγο, έχω την αίσθηση ότι έχω διαβάσει τα πάντα για το θέμα, δεν υπάρχει τίποτα καινούργιο πια. Ενώ έψαχνα, βρήκα μερικά ενδιαφέροντα σχόλια.
, Επικεφαλής Αρχιτέκτονας στην GridGain Systems, στο 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 Systems.
Άρθρο για το Habré παραπέμπει σε τρία άρθρα της Denis Magda: , , 2016-2017. Στο δεύτερο άρθρο, ο 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.Μονό βάζο
Ο Denis πήρε την πρώτη θέση στην προσωπική μου βαθμολογία, το IMHO το πιο χρήσιμο σεμινάριο από όλα τα διαθέσιμα. Στο δικό του Το Github περιέχει ένα εντελώς έτοιμο παράδειγμα ρύθμισης κόμβων συμπλέγματος, το οποίο μεταγλωττίζεται χωρίς επιπλέον squatting.
Το κάνω με τον ίδιο τρόπο και λαμβάνω ένα μόνο αρχείο jar που εκκινεί το "data node" ή το "client node" ανάλογα με το όρισμα της γραμμής εντολών. Η συναρμολόγηση ξεκινά και λειτουργεί. Το Zero Deployment ηττήθηκε.
Η μετάβαση από τα megabyte δεδομένων δοκιμής σε δεκάδες gigabyte δεδομένων μάχης έδειξε ότι η δυαδική μορφή υπάρχει για κάποιο λόγο. Ήταν απαραίτητο να βελτιστοποιηθεί η κατανάλωση μνήμης στους κόμβους και αυτό είναι όπου το BinaryObject αποδείχθηκε πολύ χρήσιμο.
4. Συμπεράσματα
Η πρώτη μομφή που συναντήθηκε σχετικά με την ασάφεια της τεκμηρίωσης του έργου Apache Ignite αποδείχθηκε δίκαιη· λίγα έχουν αλλάξει από το 2016. Δεν είναι εύκολο για έναν αρχάριο να συναρμολογήσει ένα λειτουργικό πρωτότυπο με βάση έναν ιστότοπο ή/και ένα αποθετήριο.
Με βάση τα αποτελέσματα της δουλειάς που έγινε, η εντύπωση ήταν ότι το Zero Deployment λειτουργεί, αλλά μόνο σε επίπεδο συστήματος. Κάτι σαν αυτό: Το BinaryObject χρησιμοποιείται για τη διδασκαλία απομακρυσμένων κόμβων συμπλέγματος να λειτουργούν με προσαρμοσμένες κλάσεις. Zero Deployment - εσωτερικός μηχανισμός
Το ίδιο το Apache Ignite και διανέμει αντικείμενα συστήματος σε όλο το σύμπλεγμα.
Ελπίζω η εμπειρία μου να είναι χρήσιμη στους νέους χρήστες του Apache Ignite.
Πηγή: www.habr.com