Bir dating tətbiqində chat mesajının yarım saniyə gecikməsi xırda texniki detal kimi görünə bilər. Amma qarşı tərəfin online olduğunu göstərib mesajı gec çatdıranda məhsul istifadəçiyə yalan danışmış olur. Zoosk-un real-time rabitə arxitekturasında əsas məsələ buna görə təkcə sürət deyildi. Presence, bildiriş və şəxsi mesaj eyni anda həm canlı, həm tutarlı, həm də bərpa oluna bilən olmalı idi.
Texnologiyaların bir qismi köhnədir. Verdikləri dizayn sualları isə hələ təzədir: uzunömürlü bağlantılar necə bölünür, tez dəyişən online state axtarışa necə qoşulur, server sıradan çıxanda istifadəçi hara gedir və offline mesaj hansı qatın məsuliyyətidir?
Üç fərqli axını bir protokola yığmaq
Zoosk real-time rabitəni üç istifadəçi davranışı ətrafında qurmuşdu. Presence istifadəçinin online, away, offline və ya görünməz vəziyyətini daşıyırdı. Notification profil baxışı və uyğunlaşma kimi hadisəni client-ə çatdırırdı. Messaging isə iki istifadəçi arasındakı söhbəti aparır, məzmunu sonradan tarixçə kimi göstərmək üçün verilənlər bazasında saxlayırdı.
Bu axınların hamısı XMPP-dən keçirdi. XMPP Core uzunömürlü TCP bağlantısı üzərində persistent XML stream yaradır; tərəflər bağlantı açıq qaldığı müddətdə məlumatı dərhal itələyə bilir. Protokolun əsas vahidi stanza-dır və üç növü var: message, presence və iq. Zoosk üçün bu bölgü əlverişli idi, çünki chat və online vəziyyət eyni transport qatını paylaşsa da, semantik olaraq qarışmırdı.
Mobil və desktop client-lər serverə TCP socket ilə bağlanırdı. Həmin dövrün brauzer imkanları səbəbindən veb client-lər BOSH, yəni uzunömürlü rabitəni ardıcıl HTTP request-ləri ilə təqlid edən mexanizmdən istifadə edirdi. Bu gün XMPP-ni brauzerə çıxarmaq üçün RFC 7395 ilə standartlaşdırılmış WebSocket subprotocol-u daha təbii seçimdir: handshake zamanı xmpp subprotocol-u razılaşdırılır, sonra XMPP frame-ləri WebSocket bağlantısından keçir.
Diaqram — orijinal məqalədə
İstifadəçi veb, mobil və ya desktop client-dən gəlirdi. Load balancer normal halda bağlantıları primary Tigase node-a ötürürdü, health check uğursuz olanda isə trafik secondary node-a yönəlirdi. XMPP routing online istifadəçiyə stanza-nı canlı çatdırır, offline istifadəçi üçün mesaj saxlancına müraciət edirdi. Tigase sənədlərində offline mesajların istifadəçi yenidən daxil olduqda çatdırılması ayrıca server funksiyası kimi göstərilir.
Burada incə məqam var. Failover yeni bağlantını sağlam node-a göndərə bilər, amma mövcud TCP bağlantısını sehrli şəkildə o biri maşına köçürmür; client qırılmanı hiss etməli, yenidən qoşulmalı və sessiyanın itirdiyi məlumat üçün bərpa mexanizminə arxalanmalıdır. Yüksək availability ilə fasiləsiz sessiya eyni vəd deyil.
Fərq vacibdir.
Presence məlumatını axtarışdan ayırmaq
Online state sakit məlumat deyil. İstifadəçi tətbiqi açır, arxa plana keçir, bağlantısını itirir, qayıdır; bir hesab bir neçə cihazdan da qoşula bilər. Bu dəyişikliklərin hər birini əsas axtarış indeksinə yazmaq indeks replikasiyasını və sorğu davranışını lazımsız yerə bir-birinə bağlayardı.
Zoosk bunu ayrıca Online State Manager ilə həll etmişdi. Chat node-ları presence keçidini xüsusi XMPP packet-i kimi bu komponentə göndərirdi. Online State Manager isə Solr serverlərinin yanındakı ehcache nüsxələrini yeniləyirdi. Axtarış sorğusu gələndə sabit profil nəticələri cache-dəki cari online state ilə birləşdirilir, sonra filtr və ya sıralama tətbiq olunurdu.
Diaqram — orijinal məqalədə
Məlumat iki mənbədən gəlir: client bağlantısı və periodik profil indeksi. Client bağlantısı Tigase chat node-da presence keçidi yaradır, Online State Manager bu keçidi hər Solr node-unun yanındakı ehcache-ə yayır. Periodik profil indeksi ilə tez dəyişən state yalnız axtarış sorğusu zamanı görüşür, beləcə profil sənədinin indekslənmə tempi online göstəricinin təzələnmə tempini məhdudlaşdırmır.
Əvəzində eventual consistency yaranır. Gecikmə mümkündür. Cache yenilənməsi vaxtında çatmasa, axtarış nəticəsi istifadəçini qısa müddət online göstərə bilər. Dating məhsulunda bu, adətən qəbul edilən güzəştdir; chat mesajının itməsi isə deyil. Deməli, hər iki məlumat eyni real-time interfeysdə görünsə də, onlara eyni consistency tələbi qoymaq düzgün olmazdı.
Görünməz status ayrıca məhsul qaydasını ortaya çıxarır. İstifadəçi serverə bağlı qala və başqalarının presence məlumatını görə bilər, lakin özü onların siyahısında online görünməz. Buna görə connection state ilə public presence bir boolean sahəyə sıxışdırılmamalıdır. Biri infrastruktur faktıdır, digəri istifadəçiyə göstərilən vəziyyət və məxfilik qərarıdır.
Bildiriş yolu və davamlılıq sərhədi
Real-time hadisələrin hamısı chat serverində yaranmırdı. Məsələn, profilə baxış veb tətbiqdə baş verirdi. Tətbiq asinxron job başladır, job Tigase-ə custom payload-lı XMPP packet-i göndərir, Tigase də onu istifadəçinin aktiv client-inə yönləndirirdi. Client həmin packet-dən toast göstərmək və ya unread badge-i yeniləmək üçün istifadə edirdi.
Bu yanaşmada tətbiqin biznes hadisəsi ilə client bağlantısı arasında aydın sərhəd yaranır: veb tətbiq hansı socket-in hansı node-da olduğunu bilmir, routing işi RTC qatında qalır. Rahat bölgüdür. Lakin custom packet schema-sı versiyalanmasa, server və müxtəlif client buraxılışları arasında uyğunluq tez başağrısına çevrilə bilər. Payload-a versiya əlavə etmək, naməlum sahələri tolerant oxumaq və eyni hadisənin təkrar gəlməsini təhlükəsizliklə qarşılamaq belə sistemdə vacibdir.
Mesajın canlı çatdırılması onun davamlı saxlanması ilə eyni əməliyyat deyil. İstifadəçi online-dırsa packet dərhal client-ə gedə bilər, amma tarixçə üçün database yazısı ayrıca uğursuz ola bilər. Güclü məhsul tələbi varsa, server mesaj ID-si, deduplication və aydın delivery state saxlamalıdır. Yoxsa istifadəçi mesajı ekranda bir an görər, başqa cihazdan daxil olanda isə tapa bilməz.
Miqyaslama rəqəmdən çox bölünmə qərarıdır
Arxitektura çoxlu primary-secondary cütlüyünə bölünmüşdü və hər cütlük ayrıca bağlantı qrupu daşıyırdı. Bu, scale-out üçün rahat sərhəddir: yeni shard əlavə etmək olur, bir node-un yaddaş və socket yükü bütün sistemi sürükləmir, nasazlığın təsir sahəsi də həmin qrupla məhdudlaşır. Müasir Tigase cluster node-larını vahid platforma kimi birləşdirməyi, yükü yaymağı və redundancy yaratmağı dəstəkləyir.
Amma shard seçiminin cavabı ayrıca verilməlidir. İstifadəçi hər qoşulmada təsadüfi cluster-ə düşürsə, session routing və istifadəçilərarası mesajlaşma node-lar arasında əlavə koordinasiya tələb edir. Sabit hash bölgüsü koordinasiyanı azalda bilər, əvəzində node əlavə ediləndə paylanmanı dəyişir. Directory service daha çevikdir, özü kritik asılılığa çevrilir. Burada pulsuz seçim yoxdur.
Monitorinq də yalnız CPU və yaddaş qrafiki deyil. Socket qəbul edilir, amma presence stanza-sı keçmirsə sistem texniki baxımdan ayaqdadır, məhsul baxımından yox. Buna görə synthetic client-in login, presence və mesaj axınını başdan sona yoxlaması; queue ölçüsü, mesaj sayı, emal müddəti və aktiv bağlantı sayının ayrıca izlənməsi məntiqlidir. Qırılmanın istifadəçiyə necə göründüyünü ölçməyən dashboard çox rahat, amma natamam təsəllidir.
Zoosk nümunəsinin əsas dərsi XMPP seçimi deyil. Güclü tərəf connection state, public presence, davamlı mesaj, axtarış indeksi və tez dəyişən cache məlumatını ayrı məsuliyyətlər kimi görməkdir. Onların yenilənmə tempi və nasazlıq nəticəsi fərqlidir. Hamısını “real-time data” adlı bir qutuya yığanda sistem sadələşmir, yalnız sərhədlər gizlənir.
Tez-tez verilən suallar
Zoosk real-time rabitə üçün hansı protokoldan istifadə edirdi?
Sistem XMPP üzərində qurulmuşdu; mobil və desktop client-lər uzunömürlü TCP bağlantısı, brauzer client-ləri isə HTTP üzərindən BOSH istifadə edirdi.
Presence niyə birbaşa axtarış indeksində saxlanmırdı?
Online vəziyyət tez-tez dəyişdiyi üçün onu periodik yenilənən əsas indeksdən ayırmaq daha münasib idi. Sorğu zamanı axtarış nəticəsi ayrıca online-state cache-i ilə birləşdirilirdi.
İstifadəçi offline olanda mesaj nə olurdu?
Mesaj və bəzi bildirişlər server tərəfində saxlanılır, istifadəçi yenidən qoşulanda çatdırılırdı. Chat tarixçəsi üçün mesaj məzmunu ayrıca verilənlər bazasında qalırdı.
Mənbələr
- RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core
- Tigase Server Documentation
- RFC 7395: An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
Bu yazı süni intellekt köməyi ilə yazılıb, faktları və mənbələri yoxlanılıb.
Top comments (0)