Yaprak: Meituan Dağıtılmış Kimlik Oluşturma Hizmeti Açık Kaynak
Yaprak, Meituan'ın temel araştırma ve geliştirme platformu tarafından başlatılan dağıtılmış bir kimlik oluşturma hizmetidir.Adı, Alman filozof ve matematikçi Leibniz'in "Dünyada aynı iki yaprak yoktur" ifadesinden alınmıştır. Leaf, yüksek güvenilirlik, düşük gecikme süresi ve küresel benzersizlik özelliklerine sahiptir. Şu anda, Meituan Finans, Meituan Paket Servisi ve Meituan Likörü gibi birçok departmanda yaygın olarak kullanılmaktadır. Spesifik teknik ayrıntılar için lütfen önceki Meituan Teknoloji Blogundaki bir makaleye bakın: "Yaprak Meituan Dağıtılmış Kimlik Oluşturma Hizmeti". Son zamanlarda, Leaf projesi Github'da açık kaynaklı: https://github.com/Meituan-Dianping/Leaf, daha teknik meslektaşlarla iletişim kurmayı ve birlikte inşa etmeyi umuyorum.
Yaprak özellikleri
Yaprak, tasarımın başlangıcında çeşitli gereksinimleri karşıladı:
- Küresel olarak benzersiz, asla yinelenen kimlikler olmayacak ve genel kimlik eğilimi artıyor.
- Yüksek kullanılabilirlik, hizmet tamamen dağıtılmış bir mimariye dayalıdır, MySQL kapalı olsa bile, bir veritabanı kullanılamama dönemini tolere edebilir.
- Yüksek eşzamanlılık ve düşük gecikme Bir CentOS 4C8G sanal makinede, QPS 5W + 'ya kadar uzaktan çağrılabilir ve TP991ms dahilindedir.
- Erişim basittir, doğrudan şirketin RPC hizmeti veya HTTP çağrısı yoluyla erişilebilir.
Yaprak doğar
Leaf'in ilk sürümü, kimlik oluşturmak için bir ön dağıtım yöntemi kullanır, yani N sunucu DB'ye bağlanabilir.Her sunucu başladığında, sabit uzunlukta bir kimlik listesi almak için DB'ye gidecektir. Bu, tamamen dağıtılmış bir mimariye ulaşır ve kimlik bellek tarafından dağıtıldığı için çok verimli olabilir. Sırada veri kalıcılığı sorunu var: Leaf sabit uzunlukta bir Kimlik Listesi almak için DB'ye her gittiğinde ve daha sonra en büyük kimliği devam ettirdiğinde, yani her kimlik kalıcı değildir, ancak bir grup kimlikteki en büyük kimlik kalır. Bir. Bu yöntem, oyundaki normal arşiv işlevine biraz benzer, ancak arşivin gelecekte belirli bir zamanda kullanıcıya verilen kimlik olması, bu da DB kalıcılığının baskısını büyük ölçüde azaltır.
Tüm hizmetin spesifik süreci aşağıdaki gibidir:
- Leaf Server 1: DB'den sayı segmentlerini yükleyin.
- Leaf Server 2: DB'den sayı segmentlerini yükleyin.
- Leaf Server 3: DB'den sayı segmentlerini yükleyin.
Kullanıcı, Leaf Server'ın çeşitli hizmetlerini Round-robin aracılığıyla çağırır, bu nedenle belirli bir İstemci tarafından elde edilen kimlik dizisi: 1, 1001, 2001, 2, 1002, 2002 ... veya: 1, 2 olabilir , 1001, 2001, 2002, 2003, 3, 4 ... Yaprak Sunucu numarası segmenti kullanıldığında, sonraki istek DB'den yeni bir numara segmenti yükleyecek ve bu da her yüklendiğinde Sayı segmenti artıyor.
Leaf veritabanındaki sayı segment tablosunun formatı aşağıdaki gibidir:
Leaf Server'ın sayı segmentini yüklemesi için SQL deyimi aşağıdaki gibidir:
Genel olarak, V1 sürümünün uygulanması nispeten basittir ve iş katmanı DB baskısı sorununu mümkün olan en kısa sürede çözmek için hızla yinelenen bir sürümdür. Bu nedenle üretim ortamında bazı sorunlar bulundu. gibi:
- DB'yi güncellerken zaman alıcı ani artışlar olacaktır. Sistem tarafından harcanan maksimum süre, DB sayı segmentini güncelleme süresine bağlıdır.
- DB sayı segmentini güncellerken, DB çalışmıyorsa veya bir ana-bağımlı anahtar meydana gelirse, hizmet bir süre için kullanılamayacaktır.
Yaprak çift tampon optimizasyonu
Leaf, bu iki sorunu çözmek için bir asenkron güncelleme stratejisi benimser ve aynı zamanda, DB ile ilgili bir sorun olduğunda, normal olarak hizmet sağlayabilen bir Tampon numarası segmenti olmasını sağlamak için çift Buffer yöntemiyle bir eşzamansız güncelleme stratejisi benimser. DB, bir Buffer yayınlama döngüsü içinde kurtarıldığı sürece, tüm Yaprağın kullanılabilirliğini etkilemeyecektir.
Kodun bu sürümü yaklaşık yarım yıldır çevrimiçi olarak kararlı bir şekilde çalışıyor ve Leaf yeni sorunlarla karşılaştı:
- Sayı segmentinin uzunluğu her zaman sabittir. Leaf, DB kullanılamadığında 10 dakika boyunca normal çalışabildiyse, trafik 10 kat arttıysa, normal olarak yalnızca 1 dakika çalışabilirdi.
- Numara segment uzunluğu çok uzun ayarlanır, bu da önbellekteki sayı segmentinin yavaş tüketilmesine neden olur ve daha sonra güncellenmiş DB'nin yeni numara segmentinin, en son verilen numara segmenti kimliği ile çok büyük olmasına neden olur.
Leaf Step'i dinamik olarak ayarlar
Hipotez Hizmet QPS'si Q, sayı segment uzunluğu L, sayı segment güncelleme döngüsü T , Sonra S * T = L . Başlangıçta, L'nin uzunluğu sabittir ve bunun sonucunda Q arttıkça T küçülür ve küçülür. Ancak Leaf'in temel gereksinimi Hope T düzeltildi . O zaman L, Q ile pozitif olarak ilişkilendirilebilirse, T sabit bir değere yaklaşabilir. Bu nedenle, Leaf sayı segmentini her güncellediğinde, son güncelleme numarası segmentinin T periyoduna ve numara segment uzunluğu adımına göre bir sonraki adım segment uzunluğunu belirler:
- T < 15dk, nextStep = adım * 2
- 15 dakika < T < 30dk, nextStep = adım
- T > 30dk, nextStep = step / 2
Şimdiye kadar, belirli bir zaman aralığına eğilimli istikrarlı sayı segment tüketim talebi karşılandı. Elbette ani trafiğin ani olarak onlarca ila yüzlerce kez artması karşısında, bu çözüm veritabanının bir süre kullanılamaz olmasına tahammül edebilme ihtiyacını hala karşılayamamakta ve sistem yine de kararlı bir şekilde çalışabilmektedir. Çünkü özünde Leaf, DB katmanında bazı hataya dayanıklı çözümler üretti, ancak kimlik numara segmenti modunda yayınlandı ve sonuçta büyük ölçüde DB'ye güvenmesi gerekiyor.
MySQL yüksek kullanılabilirlik
MySQL katmanında, Leaf şu anda verileri senkronize etmek için yarı eşzamanlı bir yol kullanıyor ve şirketin DB ara yazılımı Zebra artı MHA'yı bir ana-bağımlı anahtar yapmak için kullanıyor. Gelecekte tamamen güçlü bir tutarlılık arayışında, MySQL Grup Çoğaltmaya geçmeyi düşüneceğiz.
Bu aşamada, şirketin veri tabanındaki güçlü tutarlılığı hala gelişmekte olduğundan, Leaf bilgisayar odası bağlantı kesintisi senaryosunda veri tutarlılığını sağlamak için geçici bir çözüm benimsemiştir:
- Veritabanlarını, her bilgisayar odasında bir örnek olacak şekilde birden çok bilgisayar odasında dağıtarak verilerin bilgisayar odaları arasında senkronize edilmesini sağlayın.
- Yarı eşzamanlı zaman aşımı, yarı eşzamanlı modun eşzamansız çoğaltmaya dejenere olmasını önlemek için sonsuza ayarlanır.
Yaprak izleme
Hizmetin kendisinin izlenmesi için Leaf, tüm sayı segmentlerinin durumunu gerçek zamanlı olarak görebilen Web katmanının bir bellek veri eşleme arabirimi sağlar. Örneğin, her sayı segmentinin çift tamponunun kullanımı, geçerli kimliğin verildiği yer ve diğer bilgiler web arayüzünde görüntülenebilir.
Yaprak Kar Tanesi
Snowflake, Twitter tarafından sağlanan açık kaynaklı bir dağıtılmış kimlik oluşturma algoritması. 64-bit uygulamaya dayalı olarak, aşağıdaki şekil Snowflake algoritmasının ID kompozisyon diyagramını göstermektedir.
- İlk pozisyon 0'dır.
- 2-42. Bitler, geçerli zaman damgasından sabit bir geçmiş zaman damgasının çıkarılmasıyla oluşturulan göreceli zaman damgalarıdır.
- 43-52 bitleri, makine numarasının çalışan kimliğidir ve her sunucunun farklı bir makine kimliği vardır.
- 53-64 arası bitler, kendiliğinden artan kimliklerdir.
Bu şekilde, zaman + makine numarası + kendi kendine artan kimlik kombinasyonu ile tamamen dağıtılmış bir kimlik çıkışı gerçekleştirilir.
Burada Leaf, Java sürümünün uygulanmasını sağlar ve aynı zamanda ZooKeeper tarafından oluşturulan makine numarasına zayıf bir bağımlılık işlemi yapar, ZooKeeper bir sorun yaşasa bile, hizmeti etkilemeyecektir. Leaf, workerID'yi ZooKeeper'dan ilk kez aldıktan sonra, yerel dosya sisteminde bir workerID dosyasını önbelleğe alır. ZooKeeper ile ilgili bir sorun olsa ve makine yeniden başlatılıyor olsa bile, hizmetin normal çalışması garanti edilebilir. Bu şekilde, üçüncü taraf bileşenlerine olan zayıf bağımlılık, SLA'yı bir dereceye kadar iyileştirmiştir.
gelecek planı
Sayı segmenti yüklemesinin optimizasyonu: Leaf yeniden başlatıldıktan sonraki ilk istek MySQL'i eşzamanlı olarak yükleyecektir.Hizmetin yükleme numarası segmentini başlatmak yerine bunu yapmanın nedeni, MySQL'deki Leaf Key'in mutlaka Leaf servis düğümüne ait olmamasıdır. Yükleme, her bir Yaprak düğümü tüm Yaprak Anahtarlarını başlatıp yüklüyorsa, çok sayıda sayı segmenti israfına neden olacaktır. Bu nedenle, gelecekte Leaf hizmeti kapatıldığında, bu hizmet düğümü tarafından geçen gün kullanılan yaprak anahtar listesi yedeklenecek, böylece anahtar listesindeki sayı segmenti yeniden başlatıldıktan sonra MySQL'den önceden yüklenecektir.
Monotonik artış: Basit yol, kimliğin aynı anda bir Leaf hizmet düğümünden ve aynı Leaf Key'den elde edilmesini ve artışın garanti edilebilmesini sağlamaktır. Dikkat edilmesi gereken sorun, Leaf servis düğümü değiştirildiğinde, eski Leaf servisi tarafından kullanılan sayı segmentinin atılması gerektiğidir. Yönlendirme mantığı, her bir Yaprak Anahtarı için etkin / bekleme modeli veya yönlendirme tablosu yapılandırması kullanılarak uygulanabilir.
Açık kaynak hakkında
Dağıtılmış kimlikler oluşturmanın birçok yolu vardır. Leaf'in açık kaynak sürümü iki kimlik oluşturma yöntemi sağlar:
- Sayı segment modu: düşük seviyeli trend büyümesi, daha az kimlik numarası segmenti israfı, MySQL'in kısa vadeli kullanılamazlığını tolere edebilir.
- Kar Tanesi modu: tamamen dağıtılmış, kimliğin semantiği var.
Okuyucular, gerektiğinde iş senaryolarına uyan kimlik dağıtım yöntemini seçebilirler. Umarım Meituan'ın planı size biraz yardım edebilir ve umarım birlikte iletişim kurabilir ve birlikte inşa edebilirsiniz.
Leaf projesinin Github adresi: https://github.com/Meituan-Dianping/Leaf.
Herhangi bir sorunuz veya sorununuz varsa, lütfen Github sorunlarını gönderin.
