Değişiklik günlüğü olarak MongoDB kullanılarak iki sistem arasında senkronizasyon

İki ilgili sistem geliştiriyoruz. Bunlardan biri (A) müşterilerimizin makinelerine kurulacaktır. Kalan (B) kuruluşum tarafından kullanılacaktır.

Her sistemin kendi veritabanı (ilişkisel) vardır ve şemaları farklıdır. Ancak, her iki sistemin de senkronize edilmesi gerekir. Ek olarak, B'deki bazı değişikliklerin tüm A sınıfı sistemlere, diğeri ise sadece belirli bir sisteme aktarılması gerekir.

Bazı müşterilerin İnternet bağlantısı yoktur, bu nedenle bazı durumlarda senkronizasyonun dosya alışverişi yoluyla yapılması gerekir.

Bu nedenle, bu sorunu şu şekilde çözmeyi planlıyoruz:

1. Her sistem kendi veritabanının değişikliğini tutar. MongoDB ile uygulamayı planlıyoruz.
2. Bir sistem bir senkronizasyon işlemini başlattığında, yapılan tüm değişiklikleri bir günlükten alır. Sistem B ise, alınan değişiklikler hedefe bağlıdır. Ardından, sistem bunları XML biçiminde serileştirir ve son olarak (bir dosya veya ağ aracılığıyla) gönderir.
3. Diğer uç nokta değişiklik kümesini aldığında, bunların serisini kaldırır. Daha sonra sistem, veriler üzerinde gerekli olabilecek bazı dönüşümler yapar ve son olarak değişiklikleri kaydeder. Bu adımda, gerekirse sistem mevcut olabilecek çatışmaları çözmelidir.
4. Son olarak, alıcı sistem değişikliklerini (ve diğer çatışma çözümleme ürünlerini) gönderir.

Bu yaklaşım uygulanabilir, ölçeklenebilir ve zarif mi? Ne tür değişiklikler veya eklemeler yapardınız?

Henüz yapmadıysanız, olay güdümlü sistemlerde, olay kaynaklarında ve nihai tutarlılıkta okumaları ilginç bulabilirsiniz. Tanımladığınız sistemin bu kalıplarla birçok paralellik vardır, ki bu iyi bir şeydir.

Yaklaşımınız kulağa hoş geliyor, özellikle:

• Sıralı bir değişiklik günlüğü kullanımı, senkronizasyon işleminin yalnızca son görülen değişiklikten bu yana yapılan değişiklikleri alabildiği anlamına gelir. Bu, işlem süresini kısaltarak ölçeklenebilirliğe yardımcı olur ve internet bağlantısının mevcut olduğu durumlarda gerçek zamanlıya yakın senkronizasyon oluşturmanıza olanak tanır.
• İnternet bağlantısı olmayan müşteriler, hızlı senkronizasyona güvenmek ve istemeden ölçeklenebilirlik sorunlarıyla sonuçlanmak yerine, şimdi gecikmeli ve sipariş dışı senkronizasyonla uğraşmayı düşünmeye zorluyor.

Etki alanı modeli hakkında daha fazla bilgi sahibi olmadan tahminim, çatışmaları çözmenin size en fazla soruna neden olacak kısım olmasıdır. Her tür çatışmanın nasıl çözüleceğini düşünerek biraz zaman harcayacağım. Özellikle:

• Bazı çakışmalar kullanıcı çözümlemesi gerektirecek mi?
• Müşteri sistemi çatışmaları çözmek için her zaman doğru yer olacak mı?
• Müşteri sistemi değişikliklerini gönderdiğinde 4. adımdan sonra B sisteminde çatışmaların olması mümkün müdür?

Her sistem kendi veritabanının değişikliğini tutar. MongoDB ile uygulamayı planlıyoruz.

Bir etkinlik deposu kullanabilirsiniz . Orada herhangi bir veri güncelleme mağaza yeni bir olay yaratacaktır.

Bir sistem bir senkronizasyon işlemini başlattığında, yapılan tüm değişiklikleri günlükten alır. Sistem B ise, alınan değişiklikler hedefe bağlıdır. Ardından, sistem bunları XML biçiminde serileştirir ve son olarak (bir dosya veya ağ aracılığıyla) gönderir.

Olay göndermek için herhangi bir mekanizmayı kullanabilirsiniz, ancak dosyalarla uğraşmak zorunda olmadığınız durumlarda mümkünse bir otobüs kullanmak daha kolay olacaktır. Genellikle bunlar, göndermek için bağlantı sağlanana kadar mesajları tutacak şekilde yapılandırılabilir.

Diğer uç nokta değişiklik kümesini aldığında, bunların serisini kaldırır. Daha sonra sistem, veriler üzerinde gerekli olabilecek bazı dönüşümler yapar ve son olarak değişiklikleri kaydeder. Bu adımda, gerekirse sistem mevcut olabilecek çatışmaları çözmelidir.

Etkinlikleri etki alanı nesnelerinize uygulamanız yeterlidir.

Son olarak, alıcı sistem değişikliklerini (ve diğer çatışma çözümleme ürünlerini) gönderir.

Aynı yaklaşımı kullanın.