Apache Ignite Sıfır Dağıtımı: Gerçekten Sıfır mı?

Biz bir perakende ağının teknoloji geliştirme departmanıyız. Bir gün yönetim, Apache Ignite'ı MSSQL ile birlikte kullanarak büyük ölçekli hesaplamaları hızlandırma görevini üstlendi ve güzel çizimler ve Java kodu örnekleri içeren bir web sitesi gösterdi. Siteyi hemen beğendim Sıfır DağıtımAçıklaması mucizeler vaat eden: Java veya Scala kodunuzu ızgaradaki her düğüme manuel olarak dağıtmanıza ve her değiştiğinde yeniden dağıtmanıza gerek yok. Çalışma ilerledikçe Sıfır Dağıtımın, özelliklerini paylaşmak istediğim belirli kullanımlara sahip olduğu ortaya çıktı. Kesimin altında düşünceler ve uygulama detayları bulunmaktadır.

1. Sorunun açıklaması

Sorunun özü aşağıdaki gibidir. Satış Noktası satış noktaları rehberi ve Sku (Stok Saklama Birimi) ürün rehberi bulunmaktadır. Satış noktasının “küçük” ve “büyük” değerlerine sahip “Mağaza tipi” özelliği bulunmaktadır. Her satış noktasına (DBMS'den yüklenen) bir ürün çeşidi (satış noktasının ürünlerinin listesi) bağlanır ve belirtilen tarihten itibaren belirtilen ürünün
ürün yelpazesinden çıkarıldı veya ürün yelpazesine eklendi.

Satış noktalarının bölümlenmiş bir önbelleğinin düzenlenmesi ve bağlı ürünlerle ilgili bilgilerin bir ay önceden saklanması gerekir. Savaş sistemiyle uyumluluk, Ignite istemci düğümünün verileri yüklemesini, formun bir toplamını hesaplamasını (Mağaza türü, Ürün kodu, gün, satış_noktası sayısı) ve bunu DBMS'ye geri yüklemesini gerektirir.

2. Edebiyat çalışması

Henüz bir tecrübem olmadığı için ocaktan dans etmeye başlıyorum. Yani, yayınların incelenmesinden.

2016 yazı Apache Ignite'a Giriş: İlk Adımlar Apache Ignite projesinin belgelerine bir bağlantı içerir ve aynı zamanda bu belgelerin belirsizliğine yönelik bir sitem içerir. Birkaç kez tekrar okudum, netlik gelmiyor. Resmi eğitime başvuruyorum başlamakHangi
iyimser bir şekilde "Bir anda ayağa kalkacaksınız!" sözünü veriyor. İki Apache Ignite Essentials videosu izleyerek ortam değişkeni ayarlarını bulmaya çalışıyorum, ancak bunlar benim özel görevim için pek kullanışlı olmadı. Ignite'ı komut satırından "example-ignite.xml" standart dosyasıyla başarıyla başlatıyorum ve ilk uygulamayı oluşturuyorum Bilgi İşlem Uygulaması Maven'i kullanıyor. Uygulama çalışıyor ve Sıfır Dağıtımı kullanıyor, ne güzel!

Daha fazlasını okudum ve orada örnek hemen affinityKey'i (daha önce bir SQL sorgusu aracılığıyla oluşturulmuş) kullanıyor ve hatta gizemli BinaryObject'i kullanıyor:

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

saygın hafifçe: ikili format - yansıma gibi bir şey, bir nesnenin alanlarına isme göre erişim. Nesnenin serisini tamamen kaldırmadan (bellekten tasarruf etmeden) bir alanın değerini okuyabilir. Peki Sıfır Dağıtım olduğuna göre neden Kişi yerine BinaryObject kullanılıyor? Neden IgniteCache IgniteCache'e aktarıldı ? Henüz net değil.

Durumuma uyacak şekilde Hesaplama Uygulamasını yeniden yapıyorum. MSSQL'deki satış noktaları dizininin birincil anahtarı [id] [int] NOT NULL olarak tanımlanır, benzetme yoluyla bir önbellek oluştururum

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

Xml yapılandırmasında önbelleğin bölümlendiğini belirtiyorum

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

Satış noktasına göre bölümleme, orada bulunan salesPointCache kayıtları için her küme düğümünde gerekli toplamın oluşturulacağını ve ardından istemci düğümünün nihai toplamayı gerçekleştireceğini varsayar.

Dersi okuyorum İlk Ignite Hesaplama Uygulaması, bunu benzetme yoluyla yapıyorum. Her küme düğümünde IgniteRunnable()'ı çalıştırıyorum, şöyle bir şey:

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

Toplama ve yükleme mantığını ekliyorum ve bunu bir test veri kümesinde çalıştırıyorum. Her şey geliştirme sunucusunda yerel olarak çalışır.

İki CentO test sunucusunu başlatıyorum, IP adreslerini default-config.xml dosyasında belirtiyorum, her birinde çalıştırıyorum

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

Her iki Ignite düğümü de çalışıyor ve birbirini görebiliyor. İstemci uygulamasının xml yapılandırmasında gerekli adresleri belirtiyorum, başlıyor, topolojiye üçüncü bir düğüm ekliyor ve hemen tekrar iki düğüm oluyor. Günlük, satırda "ClassNotFoundException: model.SalesPoint" ifadesini gösterir

SalesPoint sp=salesPointCache.get(spId);

StackOverflow, hatanın nedeninin CentOs sunucularında özel bir SalesPoint sınıfının bulunmaması olduğunu söylüyor. Biz geldik. "Java kodunuzu her düğüme manuel olarak dağıtmanıza gerek yok" vb.'ye ne dersiniz? Yoksa “Java kodunuz” SalesPoint ile ilgili değil mi?

Muhtemelen bir şeyi kaçırdım - tekrar aramaya, okumaya ve tekrar aramaya başlıyorum. Bir süre sonra konuyla ilgili her şeyi okuduğum hissine kapılıyorum, artık yeni bir şey yok. Araştırırken ilginç yorumlarla karşılaştım.

Valentin Kulichenko, GridGain Systems'de Baş Mimar, cevap StackOverflow'ta, Nisan 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.

Başka bir yetkili görüş: Denis Magda, Ürün Yönetimi Direktörü, GridGain Systems.

Habre ile ilgili makale mikro hizmetler hakkında Denis Magda'nın üç makalesine gönderme yapıyor: Mikro Hizmetler Bölüm I, Mikro Hizmetler Bölüm II, Mikro Hizmetler Bölüm III 2016-2017. İkinci makalede Denis, MaintenanceServiceNodeStartup.jar aracılığıyla bir küme düğümü başlatmayı öneriyor. Başlatmayı xml yapılandırması ve komut satırıyla da kullanabilirsiniz, ancak daha sonra özel sınıfları dağıtılan her küme düğümüne manuel olarak yerleştirmeniz gerekir:

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.

Gerçekten de bu kadar. İşte bu gizemli ikili formatın nedeni ortaya çıkıyor!

3.Tek Kavanoz

Denis benim kişisel derecelendirmemde birinci sırada yer aldı; IMHO mevcut tüm eğitimler arasında en yararlı olanıydı. onun içinde Mikro HizmetlerÖrneği Github, herhangi bir ek çömelme olmadan derlenen, küme düğümleri kurmanın tamamen hazır bir örneğini içerir.

Bunu aynı şekilde yapıyorum ve komut satırı argümanına bağlı olarak "veri düğümü" veya "istemci düğümü" başlatan tek bir jar dosyası alıyorum. Montaj başlar ve çalışır. Sıfır Dağıtım yenildi.

Megabaytlarca test verisinden onlarca gigabaytlık savaş verilerine geçiş, ikili formatın bir nedenden dolayı var olduğunu gösterdi. Düğümlerdeki bellek tüketimini optimize etmek gerekiyordu ve BinaryObject'in çok kullanışlı olduğu yer burasıydı.

4. bulgular

Apache Ignite proje belgelerinin belirsizliği konusunda karşılaşılan ilk suçlamanın adil olduğu ortaya çıktı; 2016'dan bu yana çok az şey değişti. Yeni başlayan birinin bir web sitesi ve/veya veri deposunu temel alarak işleyen bir prototip oluşturması kolay değildir.

Yapılan çalışmanın sonuçlarına dayanarak, Sıfır Dağıtımın yalnızca sistem düzeyinde çalıştığı izlenimi oluştu. Bunun gibi bir şey: BinaryObject, uzak küme düğümlerine özel sınıflarla çalışmayı öğretmek için kullanılır; Sıfır Dağıtım - dahili mekanizma
Apache Ignite kendisini ve sistem nesnelerini küme boyunca dağıtır.

Deneyimlerimin yeni Apache Ignite kullanıcılarına faydalı olacağını umuyorum.

Kaynak: habr.com