Linux altında verimli günlük kitaplığı uygulaması
Günlüğün kendisinde var olan özelliklerinden dolayı, kayıtlar soldan sağa sırayla eklenir; bu, soldaki kayıtların sağdaki kayıtlardan "daha eski" olduğu anlamına gelir, bu da sistem saatine güvenmemize gerek olmadığı anlamına gelir. Bu özellik dağıtılmış içindir. Sistem çok önemli.
Oturum veritabanının uygulanması
Günlüğün ne zaman göründüğünü bilmenin bir yolu yoktur, kavramsal olarak çok basit olabilir. Veri tabanı alanında, günlükler daha çok MySQL'de yeniden oturum açma gibi sistem çöktüğünde verileri ve dizinleri senkronize etmek için kullanılır.Yineleme günlüğü, sistem çöktüğünde verileri sağlamak için kullanılan disk tabanlı bir veri yapısıdır. Sistemin doğruluğu ve eksiksizliği aynı zamanda ön yazma günlükleri olarak da adlandırılır.Örneğin, bir işlemin yürütülmesi sırasında, önce yineleme günlüğü yazılır ve ardından gerçek değişiklikler uygulanır, böylece sistem bir çökmeden sonra geri yüklendiğinde, yineleme günlüğü yeniden yapılabilir. Verileri geri yüklemek için bırakın (başlatma sürecinde, şu anda istemci bağlantısı olmayacaktır). Günlük aynı zamanda veritabanının ana ve kölesi arasındaki senkronizasyon için de kullanılabilir, çünkü esasen veritabanının tüm işlem kayıtları günlüğe yazılmıştır.Yalnızca günlüğü slave ile senkronize etmemiz ve master-slave senkronizasyonunu elde etmek için slave üzerinde yeniden oynatmamız gerekir. Diğer birçok gerekli bileşen de burada uygulanabilir: Denetleme, önbellek senkronizasyonu vb. Gibi kişiselleştirilmiş iş mantığını elde etmek için, yineleme günlüğüne abone olarak veritabanındaki tüm değişiklikleri alabiliriz.
Dağıtılmış sistemde oturum açma uygulaması
Dağıtılmış sistem hizmeti esasen durum değişiklikleri ile ilgilidir, burada bir durum makinesi olarak anlaşılabilir, iki bağımsız süreç (sistem saati, harici arayüz vb. Gibi dış ortama bağlı olmayan) tutarlı girdi verilmiş tutarlı çıktı üretecektir. Ve nihayetinde tutarlı bir durumu koruyun ve günlük, düzenli değişiklikler sorununu çözmek için kullanılabilen doğal sırası nedeniyle sistem saatine bağlı değildir.
Bu özelliği, dağıtılmış sistemlerde karşılaşılan birçok sorunu çözmek için kullanıyoruz. Örneğin, RocketMQ'daki bekleme düğümünde, ana broker istemcinin talebini alır, günlüğü kaydeder ve ardından gerçek zamanlı olarak salve ile senkronize olur. Bağımlı, yerel olarak yeniden oynatır. Okuma isteklerini işleyin. Günlüğe yalnızca veri kaydedilemez, aynı zamanda SQL deyimleri gibi işlemler de doğrudan kaydedilebilir.
Günlük, tutarlılık problemini çözmek için önemli bir veri yapısıdır.Günlük, bir işlem sırası gibidir.Her kayıt bir talimatı temsil eder.Örneğin, yaygın olarak kullanılan Paxos ve Raft protokollerinin tümü, günlük üzerinde oluşturulmuş tutarlılık protokolleridir.
Message Queue'da oturum açma uygulaması
Günlükler, veri giriş ve çıkışını işlemek için rahatlıkla kullanılabilir.Her veri kaynağı kendi günlüğünü oluşturabilir.Veri kaynağı, belirli bir olay akışı (sayfa tıklama, önbellek yenileme hatırlatıcısı, veritabanı binlog değişikliği) gibi çeşitli yönlerden gelebilir. ), logları bir kümede merkezi olarak saklayabiliriz, aboneler günlüğün her kaydını ofsete göre okuyabilir ve her bir kayıttaki veri ve işlemlere göre kendi değişikliklerini uygulayabilir.
Buradaki günlük, eşzamansız ayırmada ve akım sınırlamasında rol oynayabilen bir mesaj kuyruğu olarak anlaşılabilir. Neden ayrılık diyoruz? Çünkü tüketiciler ve üreticiler için, iki rolün sorumlulukları çok nettir: İster veri tabanından bir değişiklik günlüğü ister bir olay olsun, aşağı akış veya yukarı akış kim olduğuna bakmadan mesaj üretmekten ve tüketmekten sorumludurlar. Bir taraf için, hiç umursamama gerek yok, sadece ilgilendiğim günlüklere ve günlüklerdeki her kayda dikkat etmem gerekiyor.
Veritabanının QPS'sinin kesin olduğunu ve üst seviye uygulamaların genellikle yatay olarak genişleyebildiğini biliyoruz.Şu anda, çift 11'in ani isteğine ulaşılırsa, veritabanı bunu işleyemez, ardından her ekibin veritabanının çalışmasını yazmak için bir mesaj kuyruğu ekleyebiliriz. Günlükte, başka bir uygulama bu günlük kayıtlarını tüketmekten ve bunları veritabanına uygulamaktan sorumludur ve veritabanı kapatılsa bile, geri yüklendiğinde son mesajın bulunduğu yerden işlemeye devam edebilir (RocketMQ ve Kafka her ikisi de Tam Bir Kez anlambilimini destekler) Burada, üreticinin hızı tüketicinin hızından farklı olsa bile herhangi bir etki olmayacaktır.Günlük burada bir tampon görevi görür.Günlükteki tüm kayıtları saklayabilir ve düzenli olarak slave düğümü ile senkronize edebilir, böylece mesajların birikimi Yazma günlüğü ana düğüm tarafından işlendiği için yetenek çok iyi geliştirilebilir.İki tür okuma isteği vardır.Birincisi kuyruk okumadır, yani tüketim hızı yazma hızına ayak uydurabilir.Bu tür okuma Doğrudan önbelleğe gidin ve diğeri yazma talebinin arkasındaki tüketicidir.Bu, ikincil düğümden okunabilir.Bu şekilde, IO yalıtımı ve işletim sistemiyle birlikte gelen pagecache, önbellek ön okuma gibi bazı dosya stratejileri aracılığıyla, Performans büyük ölçüde geliştirilebilir.
Dağıtık sistemlerde yatay ölçeklenebilirlik çok önemli bir özelliktir ve makine eklenerek çözülebilecek sorunlar sorun değildir. Peki, yatay genişlemeyi sağlayabilecek bir mesaj kuyruğu nasıl uygulanır? Tek makineli bir mesaj kuyruğumuz varsa, konu sayısı arttıkça IO, CPU, bant genişliği vb. Yavaş yavaş darboğazlara dönüşecek ve performans yavaş yavaş düşecek, o zaman buradan nasıl ilerleyeceğiz? Performans optimizasyonu ne olacak?
Konu / günlük parçalanması. Aslında konuya göre yazılan mesajlar günlük kayıtlarıdır.Daha sonra yazma sayısı arttıkça tek bir fırsat kademeli olarak darboğaz haline gelir. Şu anda tek bir konuyu birden çok alt konuya ayırabiliriz ve Her konuyu farklı bir makineye atayın.Bu şekilde mesaj miktarı fazla olan konular makine eklenerek çözülebilir ve az mesaj içeren bazı konular için aynı makineye atanabilir veya bölümlenmeyebilir.
Kafka'nın üretici istemcisi gibi grup taahhüdü, bir mesaj yazarken önce yerel bir bellek kuyruğuna yazar ve ardından mesajları her bölüme ve düğüme göre toplar ve toplu olarak gönderir. Sunucu veya aracı için de kullanılabilir. Bu şekilde önce sayfa önbelleği yazılır ve daha sonra disk periyodik olarak yenilenir .. Yenileme yöntemi işletmeye göre belirlenebilir.Örneğin, bir finans işletmesi eşzamanlı bir yenileme yöntemini benimseyebilir.
Yararsız veri kopyalarından kaçının
IO izolasyonu
Günlükler, dağıtılmış sistemlerde önemli bir rol oynar ve dağıtılmış sistemlerin çeşitli bileşenlerini anlamanın anahtarıdır.Anlayışın derinleşmesiyle, birçok dağıtılmış ara yazılımın Zookeeper, HDFS, Kafka gibi günlüklere dayalı olarak oluşturulduğunu gördük. , RocketMQ, Google Spanner, vb. Ve hatta ana-alt birimi günlük senkronizasyonuna dayalı olan Redis, MySQL vb. Veritabanları. Paylaşılan günlük sistemine dayanarak birçok sistemi uygulayabiliriz: düğümler arasında veri senkronizasyonu, eşzamanlı güncellemeler Veri sipariş sorunları (tutarlılık sorunları), dayanıklılık (sistem çöktüğünde sistem diğer düğümler üzerinden hizmet vermeye devam edebilir), dağıtılmış kilit hizmetleri vb. Uygulamadan yavaşça geçip çok sayıda makale okuduktan sonra daha derin bir seviye olacağına inanıyorum. Anlamak.
