Herkese selam. Vladislav Rodin temas halinde. Şu anda OTUS'ta Yazılım Mimarisi ve Yüksek Stressli Yazılım Mimarisi üzerine dersler veriyorum. Yeni bir kurs akışının başlaması beklentisiyle Sizlerle paylaşmak istediğim orijinal materyalden kısa bir parça yazmaya karar verdim.
Giriş
HDD'nin saniyede yalnızca yaklaşık 400-700 işlem gerçekleştirebilmesi nedeniyle (bu, yüksek yüklü bir sistemdeki tipik rps ile karşılaştırılamaz), klasik disk veritabanı, mimarinin darboğazıdır. Bu nedenle bu depolamanın ölçeklendirme modellerine özellikle dikkat etmek gerekir.
Şu anda 2 veritabanı ölçeklendirme modeli vardır: çoğaltma ve parçalama. Parçalama, yazma işlemini ölçeklendirmenize ve bunun sonucunda kümenizdeki sunucu başına yazma başına rps'yi azaltmanıza olanak tanır. Çoğaltma, aynı şeyi okuma işlemleriyle yapmanıza olanak tanır. Bu makalenin adandığı model budur.
çoğaltma
Çoğaltmaya çok yüksek düzeyde bakarsanız, bu basit bir şeydir: bir sunucunuz vardı, üzerinde veriler vardı ve sonra bu sunucu artık bu verileri okuma yüküyle baş edemiyordu. Birkaç sunucu daha eklersiniz, verileri tüm sunucular arasında senkronize edersiniz ve kullanıcı, kümenizdeki herhangi bir sunucudan okuyabilir.
Görünen basitliğine rağmen, bu planın çeşitli uygulamalarını sınıflandırmak için çeşitli seçenekler vardır:
- Kümedeki rollere göre (master-master veya master-slave)
- Gönderilen nesnelere göre (satır tabanlı, bildirim tabanlı veya karışık)
- Düğüm senkronizasyon mekanizmasına göre
Bugün 3. noktayı ele alacağız.
İşlem taahhüdü nasıl gerçekleşir?
Bu konunun doğrudan replikasyonla alakası yok, üzerine ayrı bir yazı yazılabilir ama transaction commit mekanizmasını anlamadan daha fazla okumak faydasız olduğundan en temel şeyleri hatırlatayım. Bir işlem taahhüdü 3 aşamada gerçekleşir:
- Bir işlemin veritabanı günlüğüne kaydedilmesi.
- Bir veritabanı motorunda bir işlemin kullanılması.
- İstemciye işlemin başarıyla uygulandığına dair onayın gönderilmesi.
Farklı veritabanlarında, bu algoritmanın nüansları olabilir: örneğin, MySQL veritabanının InnoDB motorunda 2 günlük vardır: biri çoğaltma için (ikili günlük), diğeri ise PostgreSQL'deyken ACID'yi (geri alma/yeniden yapma günlüğü) korumak için her iki işlevi de gerçekleştiren bir günlük vardır (önceden yazma günlüğü = WAL). Ancak yukarıda sunulan şey tam olarak bu tür nüansların dikkate alınmamasına izin veren genel kavramdır.
Eşzamanlı (senkronizasyon) çoğaltma
Alınan değişiklikleri işlem yürütme algoritmasına kopyalamak için mantık ekleyelim:
- Bir işlemin veritabanı günlüğüne kaydedilmesi.
- Bir veritabanı motorunda bir işlemin kullanılması.
- Veriler tüm kopyalara gönderiliyor.
- Tüm replikalardan, üzerlerinde bir işlemin tamamlandığına dair onay alınması.
- İstemciye işlemin başarıyla uygulandığına dair onayın gönderilmesi.
Bu yaklaşımla bir takım dezavantajlarla karşılaşırız:
- istemci değişikliklerin tüm kopyalara uygulanmasını bekler.
- Kümedeki düğüm sayısı arttıkça yazma işleminin başarılı olma ihtimali azalır.
1. noktada her şey az çok açıksa, 2. noktanın nedenleri açıklanmaya değer. Senkron çoğaltma sırasında en az bir düğümden yanıt almazsak işlemi geri alırız. Böylece kümedeki düğüm sayısını artırarak yazma işleminin başarısız olma olasılığını artırırsınız.
Düğümlerin yalnızca belirli bir yüzdesinden, örneğin %51'den (yesap) onay bekleyebilir miyiz? Evet yapabiliriz, ancak klasik versiyonda tüm düğümlerin onayı gereklidir, çünkü kümede tam veri tutarlılığını bu şekilde sağlayabiliriz, bu da bu tür çoğaltmanın şüphesiz bir avantajıdır.
Eşzamansız (eşzamansız) çoğaltma
Önceki algoritmayı değiştirelim. Verileri "bir süre sonra" kopyalara göndereceğiz ve "bir süre sonra" değişiklikler kopyalara uygulanacaktır:
- Bir işlemin veritabanı günlüğüne kaydedilmesi.
- Bir veritabanı motorunda bir işlemin kullanılması.
- İstemciye işlemin başarıyla uygulandığına dair onayın gönderilmesi.
- Verileri kopyalara gönderme ve bunlara değişiklikler uygulama.
Bu yaklaşım, Cluster'ın hızlı çalışmasına neden oluyor çünkü istemciyi verinin replikalara ulaşmasını ve hatta commit edilmesini bekletmiyoruz.
Ancak verilerin "bir süre sonra" kopyalara boşaltılması koşulu, bir işlemin kaybına ve kullanıcı tarafından onaylanan bir işlemin kaybına neden olabilir, çünkü verilerin kopyalanacak zamanı yoksa, müşteriye bir onay gönderilir. İşlemin başarısı hakkında gönderildi ve değişikliklerin geldiği düğüm HDD'yi çökertti, işlemi kaybediyoruz, bu da çok hoş olmayan sonuçlara yol açabilir.
Yarı senkronize çoğaltma
Sonunda yarı eşzamanlı çoğaltmaya ulaşıyoruz. Bu tür çoğaltma çok iyi bilinmez veya çok yaygın değildir, ancak hem eşzamanlı hem de eşzamansız çoğaltmanın avantajlarını birleştirebildiği için oldukça ilgi çekicidir.
Önceki 2 yaklaşımı birleştirmeye çalışalım. İstemciyi uzun süre elimizde tutmayacağız ancak verilerin çoğaltılmasını isteyeceğiz:
- Bir işlemin veritabanı günlüğüne kaydedilmesi.
- Bir veritabanı motorunda bir işlemin kullanılması.
- Verileri kopyalara gönderme.
- Değişikliklerin alındığına dair kopyadan onay alınması (“bir süre sonra” uygulanacaktır).
- İstemciye işlemin başarıyla uygulandığına dair onayın gönderilmesi.
Bu algoritmada işlem kaybının yalnızca hem değişiklikleri alan düğümün hem de kopya düğümün başarısız olması durumunda meydana geleceğini lütfen unutmayın. Böyle bir arızanın olasılığı düşük kabul edilir ve bu riskler kabul edilir.
Ancak bu yaklaşımda olası bir hayalet okuma riski vardır. Şu senaryoyu hayal edelim: 4. adımda hiçbir replikadan onay almadık. Bu işlemi geri almalı ve müşteriye bir onay göndermemeliyiz. Veriler 2. adımda uygulandığından, 2. adımın sonu ile işlemin geri alınması arasında bir zaman aralığı vardır; bu sırada paralel işlemler veritabanında olmaması gereken değişiklikleri görebilir.
Kayıpsız yarı senkronize çoğaltma
Biraz düşünürseniz, algoritmanın adımlarını tersine çevirebilir ve bu senaryoda hayalet okuma sorununu çözebilirsiniz:
- Bir işlemin veritabanı günlüğüne kaydedilmesi.
- Çoğaltma verileri gönderiliyor.
- Değişikliklerin alındığına dair kopyadan onay alınması (“bir süre sonra” uygulanacaktır).
- Bir veritabanı motorunda bir işlemin kullanılması.
- İstemciye işlemin başarıyla uygulandığına dair onayın gönderilmesi.
Artık değişiklikleri yalnızca kopyalanmışlarsa uyguluyoruz.
Aviator apk
Her zaman olduğu gibi ideal çözümler yoktur; her birinin kendine göre avantajları ve dezavantajları olan ve farklı sınıftaki problemleri çözmeye uygun bir dizi çözüm vardır. Bu, çoğaltılmış bir veritabanındaki verileri senkronize etmek için bir mekanizma seçmek için kesinlikle doğrudur. Yarı eşzamanlı çoğaltmanın sahip olduğu avantajlar kümesi, düşük yaygınlığına rağmen dikkate değer sayılabilecek kadar sağlam ve ilginçtir.
Bu kadar. görüşürüz !
Kaynak: habr.com