NATS JetStream hodisasi tahlili

1. Umumiy ko‘rinish

MSA (Microservice Architecture) asosidagi ilovalar bitta katta tizimni bir nechta mustaqil xizmatlarga ajratish orqali tuziladi. Har bir xizmat turli funksiyalar va mas’uliyatlarga ega, biroq amaliy xizmatlarni taqdim etish uchun xizmatlar o‘rtasida ma’lumot uzatish va holatni ulashish davom etishi kerak. Xabar almashish xizmatlar o‘rtasida qo‘llaniladigan aloqa usullaridan biridir, asinxron ma’lumot yetkazib berish talab etilganda esa xabar brokeridan foydalanish mumkin.

Project A bir nechta xizmatlar o‘rtasida kema bortidagi sensor ma’lumotlari va hodisa ma’lumotlarini ishonchli hamda samarali yetkazib berish uchun NATS asosidagi doimiy xabar almashish tizimi — NATS JetStream’dan foydalanadi. NATS JetStream xizmatlar o‘rtasida nafaqat asinxron xabar yetkazib berishni, balki xabarlarni saqlash, Consumer holatini boshqarish va xabarlarni qayta yetkazib berishni ham qo‘llab-quvvatlaydi. Shu orqali uzluksiz hosil bo‘ladigan kema ma’lumotlarini ishonchli qayta ishlash imkonini beradi.

Biroq amaliy ishlab chiqish va ishlatish jarayonida kema serverining majburiy o‘chirilishi va ilovaning noodatiy tarzda tugatilishi kabi turli holatlar yuz beradi. Bunday muhitlarda NATS JetStream bilan bog‘liq kutilmagan nosozliklarga tez-tez duch keldik. Ushbu maqolada NATS JetStream’dan foydalanish vaqtida yuzaga kelgan nosozlik holatlariga asoslanib, asosiy sabablarni tahlil qilamiz hamda kelajakda shu kabi nosozliklarni aniqlash va ularga javob berish uchun Consumer holati qiymatlariga asoslangan diagnostika tartibini bayon qilamiz.

2. Xabarlarni qayta ishlashdagi nosozliklarning yuzaga kelishi

Majburiy o‘chirish kabi noodatiy o‘chirishdan so‘ng server qayta ishga tushirilganda, xabarlar Stream’ga Published qilinishda davom etayotgan bo‘lsa ham, Durable Consumer xabarlarni to‘g‘ri qabul qila olmaydigan holat yuz berdi.

Ishga tushirilganda, ushbu ilova mavjud Durable Consumer bor-yo‘qligini tekshiradi. Agar Consumer allaqachon mavjud bo‘lsa, yangisini yaratish o‘rniga mavjud Consumer’dan qayta foydalanadi. Durable Consumer nafaqat obuna ma’lumotlarini, balki xabarlar qanchagacha yetkazilganini ko‘rsatuvchi Delivered Sequence, tasdiqlashlar qaysi nuqtagacha yakunlanganini ko‘rsatuvchi Ack Floor, hali tasdiqlanmagan xabarlar holati va qayta yetkazilishi mo‘ljallangan xabarlarni o‘z ichiga olgan iste’mol holatini ham uzluksiz saqlaydi. Shu sababli, xabarlarni qayta ishlash vaqtida server majburan tugatilsa, ayrim xabarlar uchun Ack qayta ishlanishi yakunlanmasligi yoki Consumer’ning yetkazib berish va qayta ishlash holati tugallanmagan holda qolishi mumkin.

Server qayta ishga tushirilgach, ilova mavjud Durable Consumer’dan qayta foydalanishda davom etadi va shu sababli noodatiy tugatilishdan oldin qolib ketgan xabarlarni qayta ishlash holatini ham meros qilib oladi. Normal sharoitda qayta ishlanmagan xabarlar AckWait va qayta yetkazib berish siyosatiga muvofiq yana yetkazilishi, shundan so‘ng xabarlarni iste’mol qilish davom etishi kerak. Biroq turli holatlarga, masalan, to‘planib qolgan Ack Pending xabarlariga yoki Delivered Sequence va Ack Floor oralig‘idagi qayta ishlash holatining to‘g‘ri davom etmasligiga qarab, Consumer tomonidan xabarlarni yetkazib berish kechikishi yoki to‘xtashi mumkin.

3. Consumer holati qiymatlarini tahlil qilish usuli

Nosozlik yuz berganda, avvalo Consumer holati haqidagi ma’lumotlarni tekshiring va nosozlik qaysi bosqichda yuz berganini aniqlang.

Information for Consumer “stream” > “consumer”

Configuration:
    Name: “consumer”
    Pull Mode: true
    Filter Subject: subject.>
    Deliver Policy: All
    Ack Policy: Explicit
    Ack Wait: 30s
    Maximum Deliveries: 3
    Maximum Ack Pending: 1000
State:
    Last Delivered Message:
        Consumer sequence: 15230
        Stream sequence: 185400

    Acknowledgment Floor:
        Consumer sequence: 14230
        Stream sequence: 184400

    OutStanding Acks: 1000
    Redelivered Messages: 15
    Unprocessed Messages: 3270
    Waiting Pulls: 1

• 1-jadval. Consumer holatining asosiy qiymatlari va ularning ma’nolari

1) OutStanding Acks MaxAckPending qiymatiga yetganda

OutStanding Acks — Consumer ilovaga yetkazib bergan, biroq hali Ack olmagan xabarlar sonini anglatadi. Ushbu qiymat MaxAckPending sozlamasiga yetganda, Ack qayta ishlanib, sig‘im bo‘shaguniga qadar JetStream yangi xabarlarni yetkazib berishni cheklashi mumkin.

Maximum Ack Pending:  1000
OutStanding Acks:     1000
Unprocessed Messages: 3270

Yuqoridagi misolda Stream’da hali 3270 ta xabar qolgan, biroq Consumer ruxsat etilgan Ack Pending chegarasigacha bo‘lgan xabarlarni allaqachon yetkazib bergan. Shu sababli, agar Ack’lar ilova tomonidan qayta ishlanmasa, qo‘shimcha xabarlar yetkazib berilmaydi. Natijada tashqi tomondan Publish jarayoni odatdagidek ko‘rinsa ham, Consumer hech qanday xabar qabul qilmaydigan holat yuzaga kelishi mumkin.

2) Pull so‘rovlari to‘g‘ri amalga oshirilmaganda

Pull Consumer xabarlarni faqat ilova fetch() yoki consume() yordamida Pull so‘rovlarini yuborgandagina yetkazib beradi. Shu sababli, yetkazib berilishi kerak bo‘lgan xabarlar qolgan bo‘lsa-yu, Waiting Pulls 0 bo‘lib qolsa, muammoni Consumer’ning o‘zidan ko‘ra ilovaning Pull’ni qayta ishlash mantiqidan izlash mumkin.

Unprocessed Messages: 3270
OutStanding Acks:      0
Waiting Pulls:         0

Yuqoridagi holatda xabarlarni yetkazib berish Ack’lar tufayli bloklanmagan, biroq xabar so‘rayotgan Pull so‘rovlari mavjud emas. Server qayta ishga tushirilgandan so‘ng Pull’ni qayta ishlash Thread’i yoki consume() sikli to‘g‘ri ishga tushganini hamda NATS qayta ulangandan keyin Subscription to‘g‘ri tiklanganini tekshiring.

3) Last Delivered va Ack Floor uzoq vaqt davomida siljimaganda

Last Delivered Consumer xabarlarni qanchagacha yetkazib berganini, Ack Floor esa tasdiqlashlar qaysi nuqtagacha uzluksiz yakunlanganini ko‘rsatadi. Ikki qiymat o‘rtasidagi farqning o‘ziga e’tibor qaratishdan ko‘ra, vaqt o‘tishi bilan ikkala qiymat ham umuman o‘zgarmayotganini tekshirish muhim.

Last Delivered Stream Sequence: 185400
Ack Floor Stream Sequence:      185380
OutStanding Acks:               20
Unprocessed Messages:           3270

\n Agar Last Delivered bir necha soniya yoki daqiqa davomida 185400 qiymatida qolsa, Unprocessed Messages esa oshishda davom etsa, Consumer’ning iste’mol oqimi to‘xtab qolgan bo‘lishi mumkin. Bunday holatda muammo Consumer’dami yoki ilovadagi qayta ishlash jarayonidami — buni ajratish uchun Waiting Pulls, Redelivered Messages va ilova jurnallarini birgalikda tekshiring.

Ushbu nosozlik holatlarida mavjud Durable Consumer o‘chirilib, yangi Consumer yaratish uchun ilova qayta ishga tushirilgandan so‘ng xabarlarni iste’mol qilish odatdagidek davom etdi. Bu muammo Publisher yoki Stream’ning o‘zidan emas, balki noodatiy tugatilishdan oldin mavjud Durable Consumer tomonidan saqlab qolingan holat xabarlarni iste’mol qilishga ta’sir qilganini tasdiqladi.

Shundan so‘ng server qayta ishga tushganda mavjud Consumer’ni o‘chirib, qayta yaratadigan va shu orqali xabar almashish tizimi holatini boshlang‘ich holatga keltiradigan tiklash skriptini yaratdik. Bu kema bortidagi NATS JetStream bilan bog‘liq nosozliklarni kamaytirishga yordam berdi.

4. Xulosa

Amaliy ishlash muhitlarida NATS JetStream’da xabarlarni qayta ishlash serverning kutilmaganda majburiy o‘chirilishi yoki ilovaning noodatiy tarzda tugatilishi kabi holatlar sababli muvaffaqiyatsiz yakunlanishi mumkin. Xususan, xabarlarni qayta ishlash xizmatlar o‘rtasida ma’lumot uzatish bilan bog‘liq asosiy funksiya hisoblanadi. Shu sababli nosozlik yuz berganda uning sababini tezda aniqlash va tegishli choralarni ko‘rish muhimdir.

Shu sababli, kelajakda shunga o‘xshash nosozliklar yuz berganda, ushbu maqolada bayon qilingan asosiy Consumer holati qiymatlari va holatga qarab tahlil qilish usullari asosida ularning sabablarini tezda aniqlash va tegishli choralarni ko‘rish zarur. Bu xizmatning ishlamay qolish vaqtini minimallashtirish va barqaror ishlashni ta’minlash imkonini beradi.

deeeneee