Taqsimlangan konsensusni o'zlashtirish: Global tizimlar uchun Raft algoritmini amalga oshirishga chuqur nazar

Bizning tobora o'zaro bog'lanib borayotgan dunyomizda taqsimlangan tizimlar deyarli har bir raqamli xizmatning, jumladan, elektron tijorat platformalari va moliyaviy muassasalardan tortib, bulutli hisoblash infratuzilmasi va real vaqtdagi aloqa vositalarigacha bo'lgan asosini tashkil etadi. Bu tizimlar ish yuklamalari va ma'lumotlarni bir nechta mashinalar bo'ylab taqsimlash orqali misli ko'rilmagan masshtablashuvchanlik, mavjudlik va chidamlilikni taklif qiladi. Biroq, bu qudrat bilan birga jiddiy muammo ham keladi: tarmoq kechikishlari, tugunlar ishdan chiqishi va bir vaqtda bajariladigan operatsiyalar sharoitida ham barcha komponentlarning tizim holati bo'yicha kelishuvini ta'minlash. Bu fundamental muammo taqsimlangan konsensus deb nomlanadi.

Asinxron, nosozliklarga moyil taqsimlangan muhitda konsensusga erishish juda murakkabdir. O'nlab yillar davomida Paxos bu muammoni hal qilish uchun dominant algoritm bo'lib kelgan, uning nazariy asosliligi uchun hurmat qilingan, lekin ko'pincha murakkabligi va amalga oshirish qiyinligi uchun tanqid qilingan. Keyin Raft paydo bo'ldi, bu algoritm asosiy maqsad - tushunarlilik bilan yaratilgan. Raft nosozliklarga chidamlilik va unumdorlik jihatidan Paxosga teng bo'lishni maqsad qiladi, lekin dasturchilar uchun tushunish va uning asosida qurish ancha osonroq bo'lgan tarzda tuzilgan.

Ushbu keng qamrovli qo'llanma Raft algoritmini chuqur o'rganadi, uning asosiy tamoyillari, ishlash mexanizmlari, amaliy amalga oshirish mulohazalari va mustahkam, global miqyosda taqsimlangan ilovalarni yaratishdagi muhim rolini ochib beradi. Siz tajribali arxitektor, taqsimlangan tizimlar muhandisi yoki yuqori darajadagi mavjud xizmatlarni yaratishga intilayotgan dasturchi bo'lasizmi, Raft'ni tushunish zamonaviy hisoblashning murakkabliklarini o'zlashtirish yo'lidagi muhim qadamdir.

Zamonaviy arxitekturalarda taqsimlangan konsensusning ajralmas zarurati

Har soniyada millionlab tranzaksiyalarni qayta ishlaydigan global elektron tijorat platformasini tasavvur qiling. Mijoz ma'lumotlari, inventar darajalari, buyurtma holatlari — barchasi qit'alar bo'ylab joylashgan ko'plab ma'lumotlar markazlarida izchil bo'lib qolishi kerak. Bir nechta serverlarga tarqalgan bank tizimining hisob daftari hisob balansi bo'yicha bir lahzalik kelishmovchilikka ham yo'l qo'ya olmaydi. Bu stsenariylar taqsimlangan konsensusning o'ta muhimligini ko'rsatadi.

Taqsimlangan tizimlarning o'ziga xos qiyinchiliklari

Taqsimlangan tizimlar o'z tabiatiga ko'ra monolit ilovalarda mavjud bo'lmagan ko'plab qiyinchiliklarni keltirib chiqaradi. Bu qiyinchiliklarni tushunish Raft kabi algoritmlarning nafisligi va zarurligini anglash uchun juda muhimdir:

• Qisman nosozliklar: Ishlaydigan yoki butunlay ishdan chiqadigan yagona serverdan farqli o'laroq, taqsimlangan tizimda ba'zi tugunlar ishdan chiqishi mumkin, boshqalari esa ishlashda davom etadi. Server ishdan chiqishi, uning tarmoq ulanishi uzilishi yoki diski buzilishi mumkin, shu bilan birga klasterining qolgan qismi funksional bo'lib qoladi. Tizim ushbu qisman nosozliklarga qaramay to'g'ri ishlashda davom etishi kerak.
• Tarmoq bo'linishlari: Tugunlarni bog'laydigan tarmoq har doim ham ishonchli emas. Tarmoq bo'linishi tugunlar kichik to'plamlari o'rtasidagi aloqa uzilganda yuz beradi, bu esa ba'zi tugunlar hali ham ishlayotgan bo'lsa-da, ishdan chiqqandek tuyulishiga olib keladi. Tizimning turli qismlari eskirgan yoki nomuvofiq ma'lumotlarga asoslanib mustaqil ishlaydigan "split-brain" stsenariylarini hal qilish asosiy konsensus muammosidir.
• Asinxron aloqa: Tugunlar orasidagi xabarlar kechikishi, qayta tartiblanishi yoki butunlay yo'qolishi mumkin. Global soat yoki xabar yetkazib berish vaqti haqida kafolat yo'q, bu esa hodisalar izchil tartibini yoki aniq tizim holatini o'rnatishni qiyinlashtiradi.
• Bir vaqtda ishlash (konkurentlik): Bir nechta tugunlar bir xil ma'lumotni yangilashga yoki bir vaqtda harakatlarni boshlashga urinishi mumkin. Ushbu operatsiyalarni muvofiqlashtirish mexanizmisiz ziddiyatlar va nomuvofiqliklar muqarrar.
• Kutilmagan kechikishlar: Ayniqsa, global miqyosda taqsimlangan joylashtiruvlarda tarmoq kechikishi sezilarli darajada o'zgarishi mumkin. Bir mintaqada tez bo'lgan operatsiyalar boshqasida sekin bo'lishi mumkin, bu esa qaror qabul qilish jarayonlari va muvofiqlashtirishga ta'sir qiladi.

Nima uchun konsensus ishonchlilikning asosiy poydevori hisoblanadi

Konsensus algoritmlari ushbu qiyinchiliklarni hal qilish uchun fundamental qurilish blokini ta'minlaydi. Ular ishonchsiz komponentlar to'plamiga birgalikda yagona, yuqori darajada ishonchli va izchil birlik sifatida harakat qilish imkonini beradi. Xususan, konsensus quyidagilarga erishishga yordam beradi:

• Holat mashinasi replikatsiyasi (SMR): Ko'plab nosozliklarga chidamli taqsimlangan tizimlar ortidagi asosiy g'oya. Agar barcha tugunlar operatsiyalar tartibi bo'yicha kelishsa va har bir tugun bir xil boshlang'ich holatdan boshlab, ushbu operatsiyalarni bir xil tartibda bajarsa, u holda barcha tugunlar bir xil yakuniy holatga keladi. Konsensus bu global operatsiyalar tartibi bo'yicha kelishish mexanizmidir.
• Yuqori darajadagi mavjudlik: Tizimga tugunlarning ozchiligi ishdan chiqqan taqdirda ham ishlashda davom etishiga imkon berish orqali konsensus xizmatlarning mavjud va funksional bo'lib qolishini ta'minlaydi, bu esa ishlamay qolish vaqtini minimallashtiradi.
• Ma'lumotlar izchilligi: U ma'lumotlarning barcha nusxalari sinxronlangan bo'lishini kafolatlaydi, ziddiyatli yangilanishlarning oldini oladi va mijozlar har doim eng so'nggi va to'g'ri ma'lumotni o'qishini ta'minlaydi.
• Nosozliklarga chidamlilik: Tizim ma'lum miqdordagi ixtiyoriy tugun nosozliklariga (odatda, ishdan chiqish nosozliklari) bardosh bera oladi va inson aralashuvisiz taraqqiyotda davom etadi.

Raft bilan tanishuv: Konsensusga tushunarli yondashuv

Raft akademik dunyodan aniq bir maqsad bilan paydo bo'ldi: taqsimlangan konsensusni tushunarli qilish. Uning mualliflari, Diego Ongaro va Jon Ousterhout, Raft'ni aynan tushunarlilik uchun yaratdilar, bu esa konsensus algoritmlarini kengroq qo'llash va to'g'ri amalga oshirish imkonini berishni maqsad qilgan.

Raft'ning asosiy dizayn falsafasi: Birinchi o'rinda tushunarlilik

Raft murakkab konsensus muammosini har biri o'zining maxsus qoidalari va xatti-harakatlariga ega bo'lgan bir nechta nisbatan mustaqil kichik muammolarga ajratadi. Bu modullilik tushunishga sezilarli darajada yordam beradi. Asosiy dizayn tamoyillari quyidagilardan iborat:

• Liderga yo'naltirilgan yondashuv: Barcha tugunlar qaror qabul qilishda teng ishtirok etadigan ba'zi boshqa konsensus algoritmlaridan farqli o'laroq, Raft yagona liderni belgilaydi. Lider replikatsiya qilingan logni boshqarish va barcha mijoz so'rovlarini muvofiqlashtirish uchun mas'uldir. Bu log boshqaruvini soddalashtiradi va tugunlar o'rtasidagi o'zaro ta'sirlarning murakkabligini kamaytiradi.
• Kuchli lider: Lider yangi log yozuvlarini taklif qilish va ularning qachon tasdiqlanishini aniqlash uchun mutlaq vakolatga ega. Kuzatuvchilar passiv ravishda liderning logini replikatsiya qiladilar va liderning so'rovlariga javob beradilar.
• Deterministik saylovlar: Raft tasodifiy saylov taymautidan foydalanadi, bu esa odatda ma'lum bir saylov muddatida faqat bitta nomzod lider sifatida paydo bo'lishini ta'minlaydi.
• Log izchilligi: Raft o'zining replikatsiya qilingan logida kuchli izchillik xususiyatlarini qo'llaydi, bu esa tasdiqlangan yozuvlar hech qachon bekor qilinmasligini va barcha tasdiqlangan yozuvlar oxir-oqibat barcha mavjud tugunlarda paydo bo'lishini ta'minlaydi.

Paxos bilan qisqacha taqqoslash

Raft'dan oldin Paxos taqsimlangan konsensus uchun de-fakto standart edi. Kuchli bo'lishiga qaramay, Paxos'ni tushunish va to'g'ri amalga oshirish juda qiyin. Uning dizayni, ya'ni rollarni (taklif qiluvchi, qabul qiluvchi, o'rganuvchi) ajratishi va bir vaqtning o'zida bir nechta lider mavjud bo'lishiga imkon berishi (garchi faqat bittasi qiymatni tasdiqlay olsa ham), murakkab o'zaro ta'sirlar va chekka holatlarga olib kelishi mumkin.

Raft esa, aksincha, holat fazosini soddalashtiradi. U kuchli lider modelini qo'llaydi, bunda lider barcha log o'zgarishlari uchun mas'uldir. U rollarni (Lider, Kuzatuvchi, Nomzod) va ular o'rtasidagi o'tishlarni aniq belgilaydi. Bu tuzilma Raft'ning xatti-harakatini intuitivroq va muhokama qilish uchun osonroq qiladi, bu esa kamroq amalga oshirish xatolariga va tezroq rivojlanish sikllariga olib keladi. Dastlab Paxos bilan qiynalgan ko'plab real dunyo tizimlari Raft'ni qabul qilish orqali muvaffaqiyatga erishgan.

Raft'dagi uchta asosiy rol

Har qanday vaqtda Raft klasteridagi har bir server uchta holatdan birida bo'ladi: Lider, Kuzatuvchi yoki Nomzod. Bu rollar eksklyuziv va dinamik bo'lib, serverlar maxsus qoidalar va hodisalarga asoslanib ular o'rtasida o'tishadi.

1. Kuzatuvchi

• Passiv rol: Kuzatuvchilar Raft'dagi eng passiv holatdir. Ular shunchaki liderlar va nomzodlarning so'rovlariga javob beradilar.
• Yurak urishlarini qabul qilish: Kuzatuvchi muntazam ravishda liderdan yurak urishlarini (bo'sh AppendEntries RPC'larini) qabul qilishni kutadi. Agar kuzatuvchi ma'lum bir election timeout davri ichida yurak urishini yoki AppendEntries RPC'sini olmasa, u lider ishdan chiqqan deb hisoblaydi va nomzod holatiga o'tadi.
• Ovoz berish: Saylov paytida kuzatuvchi har bir muddat uchun ko'pi bilan bitta nomzodga ovoz beradi.
• Log replikatsiyasi: Kuzatuvchilar liderning ko'rsatmasiga binoan o'zlarining mahalliy loglariga log yozuvlarini qo'shadilar.

2. Nomzod

• Saylovlarni boshlash: Kuzatuvchining vaqti tugaganda (liderdan xabar kelmasa), u yangi saylovni boshlash uchun nomzod holatiga o'tadi.
• O'ziga ovoz berish: Nomzod o'zining current term'ini oshiradi, o'zi uchun ovoz beradi va klasterdagi boshqa barcha serverlarga RequestVote RPC'larini yuboradi.
• Saylovda g'alaba qozonish: Agar nomzod bir xil muddat uchun klasterdagi serverlarning ko'pchiligidan ovoz olsa, u lider holatiga o'tadi.
• Orqaga chekinish: Agar nomzod yuqoriroq muddatli boshqa serverni topsa yoki qonuniy liderdan AppendEntries RPC'sini olsa, u kuzatuvchi holatiga qaytadi.

3. Lider

• Yagona vakolat: Har qanday vaqtda Raft klasterida (ma'lum bir muddat uchun) faqat bitta lider bo'ladi. Lider barcha mijozlar bilan o'zaro aloqalar, log replikatsiyasi va izchillikni ta'minlash uchun mas'uldir.
• Yurak urishlarini yuborish: Lider o'z vakolatini saqlab qolish va yangi saylovlar oldini olish uchun barcha kuzatuvchilarga vaqti-vaqti bilan AppendEntries RPC'larini (yurak urishlari) yuboradi.
• Log boshqaruvi: Lider mijoz so'rovlarini qabul qiladi, yangi log yozuvlarini o'zining mahalliy logiga qo'shadi va keyin bu yozuvlarni barcha kuzatuvchilarga replikatsiya qiladi.
• Tasdiqlash (Commitment): Lider yozuv serverlarning ko'pchiligiga xavfsiz tarzda replikatsiya qilinganini va holat mashinasiga tasdiqlanishi mumkinligini hal qiladi.
• Orqaga chekinish: Agar lider yuqoriroq term'ga ega serverni topsa, u darhol orqaga chekinadi va kuzatuvchiga aylanadi. Bu tizim har doim eng yuqori ma'lum bo'lgan muddat bilan oldinga siljishini ta'minlaydi.

Raft'ning operatsion bosqichlari: Batafsil tahlil

Raft lider saylovi va log replikatsiyasining uzluksiz sikli orqali ishlaydi. Ushbu ikkita asosiy mexanizm, muhim xavfsizlik xususiyatlari bilan birgalikda, klaster izchillik va nosozliklarga chidamlilikni saqlab qolishini ta'minlaydi.

1. Lider saylovi

Lider saylovi jarayoni Raft'ning ishlashi uchun fundamental bo'lib, klaster har doim harakatlarni muvofiqlashtirish uchun yagona, vakolatli tugunga ega bo'lishini ta'minlaydi.

• Saylov taymauti: Har bir kuzatuvchi tasodifiy election timeout'ni saqlaydi (odatda 150-300ms). Agar kuzatuvchi ushbu taymaut davrida joriy liderdan hech qanday aloqa (yurak urishi yoki AppendEntries RPC) olmasa, u lider ishdan chiqqan yoki tarmoq bo'linishi yuz bergan deb hisoblaydi.
• Nomzodga o'tish: Taymaut tugagach, kuzatuvchi Nomzod holatiga o'tadi. U o'zining current term'ini oshiradi, o'zi uchun ovoz beradi va saylov taymerini qayta o'rnatadi.
• RequestVote RPC: Keyin nomzod klasterdagi boshqa barcha serverlarga RequestVote RPC'larini yuboradi. Ushbu RPC nomzodning current term'i, candidateId'si va uning last log index va last log term haqidagi ma'lumotlarni o'z ichiga oladi (bu nima uchun xavfsizlik uchun muhimligi haqida keyinroq).
• Ovoz berish qoidalari: Server nomzodga o'z ovozini beradi, agar:
  1. Uning current term'i nomzodning muddatidan kichik yoki teng bo'lsa.
  2. U joriy muddatda boshqa nomzod uchun hali ovoz bermagan bo'lsa.
  3. Nomzodning logi o'zinikidan kamida shunchalik yangi bo'lsa. Bu avval last log term'ni, keyin esa muddatlar bir xil bo'lsa last log index'ni solishtirish orqali aniqlanadi. Nomzod, agar uning logi ovoz beruvchining logidagi barcha tasdiqlangan yozuvlarni o'z ichiga olsa, "yangilangan" hisoblanadi. Bu saylov cheklovi deb nomlanadi va xavfsizlik uchun juda muhimdir.
• Saylovda g'alaba qozonish: Agar nomzod bir xil muddat uchun klasterdagi serverlarning ko'pchiligidan ovoz olsa, u yangi liderga aylanadi. Saylangandan so'ng, yangi lider darhol o'z vakolatini o'rnatish va yangi saylovlar oldini olish uchun boshqa barcha serverlarga AppendEntries RPC'larini (yurak urishlari) yuboradi.
• Bo'lingan ovozlar va qayta urinishlar: Bir vaqtning o'zida bir nechta nomzod paydo bo'lishi mumkin, bu esa hech bir nomzod ko'pchilik ovozini ololmaydigan bo'lingan ovozga olib keladi. Buni hal qilish uchun har bir nomzodda tasodifiy saylov taymauti mavjud. Agar nomzodning taymauti saylovda g'alaba qozonmasdan yoki yangi liderdan xabar eshitmasdan tugasa, u o'z muddatini oshiradi va yangi saylovni boshlaydi. Tasodifiylashtirish bo'lingan ovozlar kamdan-kam bo'lishini va tezda hal qilinishini ta'minlashga yordam beradi.
• Yuqori muddatlarni aniqlash: Agar nomzod (yoki har qanday server) o'zining current term'idan yuqoriroq term'ga ega RPC olsa, u darhol o'zining current term'ini yuqoriroq qiymatga yangilaydi va kuzatuvchi holatiga qaytadi. Bu eskirgan ma'lumotga ega bo'lgan server hech qachon lider bo'lishga yoki qonuniy liderga xalaqit berishga urinmasligini ta'minlaydi.

2. Log replikatsiyasi

Lider saylangach, uning asosiy mas'uliyati replikatsiya qilingan logni boshqarish va klaster bo'ylab izchillikni ta'minlashdir. Bu mijoz buyruqlarini qabul qilish, ularni o'z logiga qo'shish va kuzatuvchilarga replikatsiya qilishni o'z ichiga oladi.

• Mijoz so'rovlari: Barcha mijoz so'rovlari (holat mashinasi tomonidan bajariladigan buyruqlar) liderga yuboriladi. Agar mijoz kuzatuvchiga murojaat qilsa, kuzatuvchi so'rovni joriy liderga yo'naltiradi.
• Liderning logiga qo'shish: Lider mijoz buyrug'ini olganda, u buyruqni o'zining mahalliy logiga yangi log yozuvi sifatida qo'shadi. Har bir log yozuvi buyruqning o'zini, u qabul qilingan term'ni va uning log index'ini o'z ichiga oladi.
• AppendEntries RPC: Keyin lider barcha kuzatuvchilarga AppendEntries RPC'larini yuborib, ulardan yangi log yozuvini (yoki yozuvlar to'plamini) o'z loglariga qo'shishni so'raydi. Ushbu RPC'lar quyidagilarni o'z ichiga oladi:
  • term: Liderning joriy muddati.
  • leaderId: Liderning IDsi (kuzatuvchilar mijozlarni yo'naltirishlari uchun).
  • prevLogIndex: Yangi yozuvlardan oldingi log yozuvining indeksi.
  • prevLogTerm: prevLogIndex yozuvining muddati. Bu ikkisi (prevLogIndex, prevLogTerm) log mosligi xususiyati uchun juda muhimdir.
  • entries[]: Saqlanadigan log yozuvlari (yurak urishlari uchun bo'sh).
  • leaderCommit: Liderning commitIndex'i (tasdiqlangani ma'lum bo'lgan eng yuqori log yozuvi indeksi).
• Izchillikni tekshirish (Log mosligi xususiyati): Kuzatuvchi AppendEntries RPC'sini olganda, u izchillikni tekshiradi. U o'z logida prevLogIndex'da prevLogTerm'ga mos keladigan muddatli yozuv mavjudligini tekshiradi. Agar bu tekshiruv muvaffaqiyatsiz bo'lsa, kuzatuvchi AppendEntries RPC'sini rad etadi va liderga uning logi nomuvofiqligini bildiradi.
• Nomuvofiqliklarni hal qilish: Agar kuzatuvchi AppendEntries RPC'sini rad etsa, lider ushbu kuzatuvchi uchun nextIndex'ni kamaytiradi va AppendEntries RPC'sini qayta urinadi. nextIndex - lider ma'lum bir kuzatuvchiga yuboradigan keyingi log yozuvining indeksi. Bu jarayon nextIndex lider va kuzatuvchining loglari mos keladigan nuqtaga yetguncha davom etadi. Moslik topilgandan so'ng, kuzatuvchi keyingi log yozuvlarini qabul qila oladi va oxir-oqibat o'z logini lidernikiga moslashtiradi.
• Yozuvlarni tasdiqlash (Committing Entries): Yozuv lider uni serverlarning ko'pchiligiga (o'zi ham kiradi) muvaffaqiyatli replikatsiya qilganda tasdiqlangan hisoblanadi. Tasdiqlangandan so'ng, yozuv mahalliy holat mashinasiga qo'llanilishi mumkin. Lider o'zining commitIndex'ini yangilaydi va buni keyingi AppendEntries RPC'lariga qo'shib, kuzatuvchilarni tasdiqlangan yozuvlar haqida xabardor qiladi. Kuzatuvchilar o'zlarining commitIndex'ini liderning leaderCommit'iga asoslanib yangilaydilar va ushbu indeksgacha bo'lgan yozuvlarni o'zlarining holat mashinasiga qo'llaydilar.
• Liderning to'liqlik xususiyati: Raft, agar log yozuvi ma'lum bir muddatda tasdiqlangan bo'lsa, keyingi barcha liderlarda ham ushbu log yozuvi bo'lishini kafolatlaydi. Bu xususiyat saylov cheklovi bilan ta'minlanadi: nomzod faqat uning logi boshqa serverlarning ko'pchiliginikidan kamida shunchalik yangi bo'lsa, saylovda g'alaba qozonishi mumkin. Bu tasdiqlangan yozuvlarni qayta yozishi yoki o'tkazib yuborishi mumkin bo'lgan lider saylanishining oldini oladi.

3. Xavfsizlik xususiyatlari va kafolatlari

Raft'ning mustahkamligi nomuvofiqliklarning oldini oladigan va ma'lumotlar yaxlitligini ta'minlaydigan bir nechta puxta ishlab chiqilgan xavfsizlik xususiyatlaridan kelib chiqadi:

• Saylov xavfsizligi: Ma'lum bir muddatda ko'pi bilan bitta lider saylanishi mumkin. Bu ovoz berish mexanizmi bilan ta'minlanadi, bunda kuzatuvchi har bir muddat uchun ko'pi bilan bitta ovoz beradi va nomzodga ko'pchilik ovozi kerak bo'ladi.
• Liderning to'liqligi: Agar log yozuvi ma'lum bir muddatda tasdiqlangan bo'lsa, u holda ushbu yozuv keyingi barcha liderlarning loglarida mavjud bo'ladi. Bu tasdiqlangan ma'lumotlarning yo'qolishini oldini olish uchun juda muhim va asosan saylov cheklovi bilan ta'minlanadi.
• Log mosligi xususiyati: Agar ikkita logda bir xil indeks va muddatga ega yozuv mavjud bo'lsa, u holda loglar barcha oldingi yozuvlarda bir xil bo'ladi. Bu log izchilligini tekshirishni soddalashtiradi va liderga kuzatuvchilarning loglarini samarali ravishda yangilash imkonini beradi.
• Tasdiqlash xavfsizligi: Yozuv tasdiqlangandan so'ng, u hech qachon bekor qilinmaydi yoki qayta yozilmaydi. Bu Liderning to'liqligi va Log mosligi xususiyatlarining bevosita natijasidir. Yozuv tasdiqlangandan so'ng, u doimiy saqlangan hisoblanadi.

Raft'dagi asosiy tushunchalar va mexanizmlar

Rollar va operatsion bosqichlardan tashqari, Raft holatni boshqarish va to'g'rilikni ta'minlash uchun bir nechta asosiy tushunchalarga tayanadi.

1. Termlar

Raft'dagi term (muddat) doimiy o'sib boruvchi butun sondir. U klaster uchun mantiqiy soat vazifasini bajaradi. Har bir muddat saylov bilan boshlanadi va agar saylov muvaffaqiyatli bo'lsa, ushbu muddat uchun yagona lider saylanadi. Termlar eskirgan ma'lumotlarni aniqlash va serverlar har doim eng yangi ma'lumotlarga bo'ysunishini ta'minlash uchun juda muhimdir:

• Serverlar barcha RPC'larda o'zlarining current term'larini almashadilar.
• Agar server yuqoriroq term'ga ega bo'lgan boshqa serverni topsa, u o'zining current term'ini yangilaydi va kuzatuvchi holatiga qaytadi.
• Agar nomzod yoki lider o'zining term'i eskirganligini (boshqa serverning term'idan past) aniqlasa, u darhol orqaga chekinadi.

2. Log yozuvlari

Log Raft'ning markaziy komponentidir. Bu tartiblangan yozuvlar ketma-ketligi bo'lib, har bir log yozuvi holat mashinasi tomonidan bajariladigan buyruqni ifodalaydi. Har bir yozuv quyidagilarni o'z ichiga oladi:

• Buyruq: Bajarilishi kerak bo'lgan haqiqiy operatsiya (masalan, "set x=5", "create user").
• Term (muddat): Yozuv liderda yaratilgan muddat.
• Indeks: Yozuvning logdagi o'rni. Log yozuvlari indeks bo'yicha qat'iy tartiblangan.

Log doimiydir, ya'ni yozuvlar mijozlarga javob berishdan oldin barqaror saqlash qurilmasiga yoziladi, bu esa ishdan chiqish paytida ma'lumotlar yo'qolishidan himoya qiladi.

3. Holat mashinasi

Raft klasteridagi har bir server holat mashinasini saqlaydi. Bu tasdiqlangan log yozuvlarini qayta ishlaydigan dasturga xos komponentdir. Izchillikni ta'minlash uchun holat mashinasi deterministik (bir xil boshlang'ich holat va buyruqlar ketma-ketligi berilganda, u har doim bir xil natija va yakuniy holatni ishlab chiqaradi) va idempotent (bir xil buyruqni bir necha marta qo'llash uni bir marta qo'llash bilan bir xil ta'sirga ega bo'lishi, bu esa qayta urinishlarni osonlashtiradi, garchi Raft'ning log tasdiqlanishi asosan bitta qo'llanilishni kafolatlaydi) bo'lishi kerak.

4. Tasdiqlash indeksi (Commit Index)

commitIndex tasdiqlangani ma'lum bo'lgan eng yuqori log yozuvi indeksidir. Bu u serverlarning ko'pchiligiga xavfsiz tarzda replikatsiya qilinganini va holat mashinasiga qo'llanilishi mumkinligini anglatadi. Liderlar commitIndex'ni aniqlaydilar va kuzatuvchilar o'zlarining commitIndex'larini liderning AppendEntries RPC'lariga asoslanib yangilaydilar. commitIndex'gacha bo'lgan barcha yozuvlar doimiy hisoblanadi va bekor qilinishi mumkin emas.

5. Snyapshotlar (Holat suratlari)

Vaqt o'tishi bilan replikatsiya qilingan log juda katta bo'lib, sezilarli disk maydonini egallashi va log replikatsiyasi hamda tiklanishini sekinlashtirishi mumkin. Raft buni snyapshotlar bilan hal qiladi. Snyapshot - bu ma'lum bir vaqt nuqtasida holat mashinasi holatining ixcham ko'rinishi. Butun logni saqlash o'rniga, serverlar vaqti-vaqti bilan o'z holatlarini "snyapshot" qilishlari, snyapshot nuqtasigacha bo'lgan barcha log yozuvlarini tashlab yuborishlari va keyin snyapshotni yangi yoki orqada qolayotgan kuzatuvchilarga replikatsiya qilishlari mumkin. Bu jarayon samaradorlikni sezilarli darajada yaxshilaydi:

• Ixcham log: Doimiy log ma'lumotlari hajmini kamaytiradi.
• Tezroq tiklanish: Yangi yoki ishdan chiqqan serverlar butun logni boshidan qayta ijro etish o'rniga snyapshotni olishlari mumkin.
• InstallSnapshot RPC: Raft snyapshotlarni liderdan kuzatuvchilarga uzatish uchun InstallSnapshot RPC'sini belgilaydi.

Samarali bo'lishiga qaramay, snyapshotlash amalga oshirishga murakkablik qo'shadi, ayniqsa bir vaqtda snyapshot yaratish, logni qisqartirish va uzatishni boshqarishda.

Raft'ni amalga oshirish: Global joylashtirish uchun amaliy mulohazalar

Raft'ning nafis dizaynini mustahkam, ishlab chiqarishga tayyor tizimga aylantirish, ayniqsa global auditoriya va turli xil infratuzilmalar uchun, bir qator amaliy muhandislik muammolarini hal qilishni o'z ichiga oladi.

1. Global kontekstda tarmoq kechikishi va bo'linishlari

Global miqyosda taqsimlangan tizimlar uchun tarmoq kechikishi muhim omil hisoblanadi. Raft klasteri odatda log yozuvini tasdiqlashdan oldin tugunlarning ko'pchiligining kelishuvini talab qiladi. Qit'alar bo'ylab tarqalgan klasterda tugunlar orasidagi kechikish yuzlab millisekund bo'lishi mumkin. Bu to'g'ridan-to'g'ri quyidagilarga ta'sir qiladi:

• Tasdiqlash kechikishi: Mijoz so'rovining tasdiqlanishi uchun ketadigan vaqt ko'pchilik nusxalarga eng sekin tarmoq aloqasi bilan cheklanishi mumkin. Faqat o'qish uchun mo'ljallangan kuzatuvchilar (eskirgan o'qishlar uchun lider bilan o'zaro aloqani talab qilmaydigan) yoki geografik jihatdan xabardor kvorum konfiguratsiyasi (masalan, 5 tugunli klaster uchun bir mintaqada 3 tugun, boshqasida 2 tugun, bu yerda ko'pchilik bitta tez mintaqa ichida bo'lishi mumkin) kabi strategiyalar buni yumshatishi mumkin.
• Lider saylovi tezligi: Yuqori kechikish RequestVote RPC'larini kechiktirishi mumkin, bu esa ko'proq bo'lingan ovozlarga yoki uzoqroq saylov vaqtlariga olib kelishi mumkin. Saylov taymautlarini odatiy tugunlararo kechikishdan ancha kattaroq qilib sozlash juda muhimdir.
• Tarmoq bo'linishini boshqarish: Haqiqiy dunyo tarmoqlari bo'linishlarga moyil. Raft bo'linishlarni to'g'ri boshqaradi, faqat serverlarning ko'pchiligini o'z ichiga olgan bo'linmagina lider saylashi va oldinga siljishi mumkinligini ta'minlaydi. Ozchilik bo'linmasi yangi yozuvlarni tasdiqlay olmaydi, bu esa split-brain stsenariylarining oldini oladi. Biroq, global miqyosda taqsimlangan tuzilmada uzoq muddatli bo'linishlar ma'lum mintaqalarda mavjud bo'lmaslikka olib kelishi mumkin, bu esa kvorum joylashuvi bo'yicha ehtiyotkor arxitektura qarorlarini talab qiladi.

2. Doimiy saqlash va chidamlilik

Raft'ning to'g'riligi uning logi va holatining doimiyligiga katta bog'liq. Server RPCga javob berishdan yoki yozuvni o'zining holat mashinasiga qo'llashdan oldin, tegishli ma'lumotlar (log yozuvlari, current term, votedFor) barqaror saqlash qurilmasiga yozilgani va fsync'd (diskka yozib qo'yilgan) qilinganiga ishonch hosil qilishi kerak. Bu ishdan chiqish holatida ma'lumotlar yo'qolishining oldini oladi. Mulohazalar quyidagilardan iborat:

• Unumdorlik: Tez-tez diskka yozish unumdorlikda to'siq bo'lishi mumkin. Yozuvlarni to'plab yozish va yuqori unumdorlikdagi SSD'lardan foydalanish keng tarqalgan optimallashtirishlardir.
• Ishonchlilik: Mustahkam va chidamli saqlash yechimini (mahalliy disk, tarmoqqa ulangan saqlash qurilmasi, bulutli blokli saqlash) tanlash juda muhimdir.
• WAL (Write-Ahead Log): Ko'pincha, Raft implementatsiyalari chidamlilik uchun ma'lumotlar bazalariga o'xshash yozishdan oldingi logdan foydalanadi, bu esa o'zgarishlar xotirada qo'llanilishidan oldin diskka yozilishini ta'minlaydi.

3. Mijoz bilan o'zaro aloqa va izchillik modellari

Mijozlar Raft klasteri bilan liderga so'rovlar yuborish orqali o'zaro aloqada bo'lishadi. Mijoz so'rovlarini boshqarish quyidagilarni o'z ichiga oladi:

• Liderni topish: Mijozlarga joriy liderni topish uchun mexanizm kerak. Bu servisni topish mexanizmi, qayta yo'naltiradigan qat'iy belgilangan nuqta yoki serverlardan biri lider sifatida javob bermaguncha sinab ko'rish orqali bo'lishi mumkin.
• So'rovlarni qayta urinish: Lider o'zgarsa yoki tarmoq xatosi yuz bersa, mijozlar so'rovlarni qayta urinishga tayyor bo'lishlari kerak.
• O'qish izchilligi: Raft asosan yozishlar uchun kuchli izchillikni kafolatlaydi. O'qishlar uchun bir nechta model mumkin:
  • Kuchli izchil o'qishlar: Mijoz liderdan o'z holati yangilanganligiga ishonch hosil qilishni so'rashi mumkin, buning uchun lider o'qishni bajarishdan oldin o'z kuzatuvchilarining ko'pchiligiga yurak urishini yuboradi. Bu yangilikni kafolatlaydi, lekin kechikish qo'shadi.
  • Lider-Lizing o'qishlari: Lider qisqa muddatga tugunlarning ko'pchiligidan 'lizing' olishi mumkin, bu davrda u hali ham lider ekanligini biladi va keyingi konsensussiz o'qishlarni bajarishi mumkin. Bu tezroq, lekin vaqt bilan cheklangan.
  • Eskirgan o'qishlar (kuzatuvchilardan): To'g'ridan-to'g'ri kuzatuvchilardan o'qish pastroq kechikishni taklif qilishi mumkin, ammo kuzatuvchining logi liderdan orqada qolsa, eskirgan ma'lumotlarni o'qish xavfi mavjud. Bu yakuniy izchillik o'qishlar uchun etarli bo'lgan ilovalar uchun maqbuldir.

4. Konfiguratsiya o'zgarishlari (Klaster a'zoligi)

Raft klasterining a'zoligini o'zgartirish (serverlarni qo'shish yoki olib tashlash) nomuvofiqliklar yoki split-brain stsenariylaridan qochish uchun konsensus orqali bajarilishi kerak bo'lgan murakkab operatsiyadir. Raft Birgalikdagi konsensus deb nomlangan texnikani taklif qiladi:

• Ikki konfiguratsiya: Konfiguratsiya o'zgarishi paytida tizim vaqtincha ikki bir-birini qoplaydigan konfiguratsiya bilan ishlaydi: eski konfiguratsiya (C_old) va yangi konfiguratsiya (C_new).
• Birgalikdagi konsensus holati (C_old, C_new): Lider birgalikdagi konfiguratsiyani ifodalovchi maxsus log yozuvini taklif qiladi. Ushbu yozuv tasdiqlangandan so'ng (bu C_old va C_new'ning har ikkalasidagi ko'pchilikning roziligini talab qiladi), tizim o'tish holatiga o'tadi. Endi qarorlar ikkala konfiguratsiyadan ham ko'pchilikni talab qiladi. Bu o'tish davrida na eski, na yangi konfiguratsiya bir tomonlama qaror qabul qila olmasligini ta'minlaydi va bu ajralishning oldini oladi.
• C_new'ga o'tish: Birgalikdagi konfiguratsiya log yozuvi tasdiqlangandan so'ng, lider faqat yangi konfiguratsiyani (C_new) ifodalovchi yana bir log yozuvini taklif qiladi. Ushbu ikkinchi yozuv tasdiqlangandan so'ng, eski konfiguratsiya bekor qilinadi va tizim faqat C_new ostida ishlaydi.
• Xavfsizlik: Ushbu ikki bosqichli tasdiqlashga o'xshash jarayon hech qanday vaqtda ikkita ziddiyatli lider (biri C_old ostida, ikkinchisi C_new ostida) saylanishi mumkin emasligini va o'zgarish davomida tizim ishlayotgan bo'lishini ta'minlaydi.

Konfiguratsiya o'zgarishlarini to'g'ri amalga oshirish Raft implementatsiyasining eng qiyin qismlaridan biridir, chunki o'tish holatida ko'plab chekka holatlar va nosozlik stsenariylari mavjud.

5. Taqsimlangan tizimlarni sinovdan o'tkazish: Qat'iy yondashuv

Raft kabi taqsimlangan konsensus algoritmini sinovdan o'tkazish uning nodeterministik tabiati va ko'plab nosozlik rejimlari tufayli juda qiyin. Oddiy birlik testlari etarli emas. Qat'iy sinov quyidagilarni o'z ichiga oladi:

• Nosozliklarni kiritish: Tugunlarning ishdan chiqishi, tarmoq bo'linishlari, xabarlarning kechikishi va xabarlarning qayta tartiblanishi kabi nosozliklarni muntazam ravishda kiritish. Jepsen kabi vositalar aynan shu maqsad uchun mo'ljallangan.
• Xususiyatlarga asoslangan testlash: Invariantlar va xavfsizlik xususiyatlarini (masalan, har bir muddat uchun ko'pi bilan bitta lider, tasdiqlangan yozuvlar hech qachon yo'qolmaydi) aniqlash va implementatsiyaning turli sharoitlarda ularni qo'llab-quvvatlashini sinab ko'rish.
• Modelni tekshirish: Algoritmning muhim qismlari uchun to'g'rilikni isbotlash uchun rasmiy verifikatsiya usullaridan foydalanish mumkin, garchi bu juda ixtisoslashgan bo'lsa ham.
• Simulyatsiya qilingan muhitlar: Global joylashtiruvlarga xos bo'lgan tarmoq sharoitlarini (kechikish, paketlar yo'qolishi) simulyatsiya qiladigan muhitlarda testlarni o'tkazish.

Qo'llash holatlari va real dunyodagi amaliyotlar

Raft'ning amaliyligi va tushunarliligi uning turli muhim infratuzilma komponentlarida keng qo'llanilishiga olib keldi:

1. Taqsimlangan kalit-qiymat omborlari va ma'lumotlar bazasi replikatsiyasi

• etcd: Kubernetes'ning asosiy komponenti bo'lgan etcd Raft'dan konfiguratsiya ma'lumotlarini, servisni topish ma'lumotlarini saqlash va replikatsiya qilish hamda klaster holatini boshqarish uchun foydalanadi. Uning ishonchliligi Kubernetes'ning to'g'ri ishlashi uchun juda muhimdir.
• Consul: HashiCorp tomonidan ishlab chiqilgan Consul o'zining taqsimlangan saqlash backend'i uchun Raft'dan foydalanadi, bu esa dinamik infratuzilma muhitlarida servisni topish, sog'liqni tekshirish va konfiguratsiyani boshqarish imkonini beradi.
• TiKV: TiDB (taqsimlangan SQL ma'lumotlar bazasi) tomonidan ishlatiladigan taqsimlangan tranzaksiyaviy kalit-qiymat ombori o'zining ma'lumotlar replikatsiyasi va izchillik kafolatlari uchun Raft'ni amalga oshiradi.
• CockroachDB: Bu global miqyosda taqsimlangan SQL ma'lumotlar bazasi ma'lumotlarni bir nechta tugunlar va geografiyalar bo'ylab replikatsiya qilish, mintaqa miqyosidagi nosozliklar sharoitida ham yuqori mavjudlik va kuchli izchillikni ta'minlash uchun Raft'dan keng foydalanadi.

2. Servislarni topish va konfiguratsiyani boshqarish

Raft servislar va konfiguratsiyalar haqidagi muhim metama'lumotlarni klaster bo'ylab saqlash va tarqatish kerak bo'lgan tizimlar uchun ideal asosni ta'minlaydi. Servis ro'yxatdan o'tganda yoki uning konfiguratsiyasi o'zgarganda, Raft barcha tugunlar oxir-oqibat yangi holat bo'yicha kelishishini ta'minlaydi, bu esa qo'lda aralashuvsiz dinamik yangilanishlarni amalga oshirish imkonini beradi.

3. Taqsimlangan tranzaksiya koordinatorlari

Bir nechta operatsiyalar yoki servislar bo'ylab atomlikni talab qiladigan tizimlar uchun Raft taqsimlangan tranzaksiya koordinatorlarini qo'llab-quvvatlashi mumkin, bu esa tranzaksiya loglarining ishtirokchilar bo'ylab o'zgarishlarni tasdiqlashdan oldin izchil replikatsiya qilinishini ta'minlaydi.

4. Boshqa tizimlarda klaster koordinatsiyasi va lider saylovi

Ma'lumotlar bazasi yoki kalit-qiymat omboridan aniq foydalanishdan tashqari, Raft ko'pincha kutubxona yoki asosiy komponent sifatida koordinatsiya vazifalarini boshqarish, boshqa taqsimlangan jarayonlar uchun liderlarni saylash yoki kattaroq tizimlarda ishonchli boshqaruv tekisligini ta'minlash uchun o'rnatiladi. Masalan, ko'plab bulutli-mahalliy yechimlar o'zlarining boshqaruv tekisligi komponentlari holatini boshqarish uchun Raft'dan foydalanadi.

Raft'ning afzalliklari va kamchiliklari

Raft sezilarli afzalliklarni taklif qilsa-da, uning o'zaro kelishuvlarini tushunish muhimdir.

Afzalliklari:

• Tushunarlilik: Uning asosiy dizayn maqsadi, bu esa uni Paxos kabi eski konsensus algoritmlariga qaraganda amalga oshirish, nosozliklarni tuzatish va muhokama qilishni osonlashtiradi.
• Kuchli izchillik: Tasdiqlangan log yozuvlari uchun kuchli izchillik kafolatlarini beradi, bu esa ma'lumotlar yaxlitligi va ishonchliligini ta'minlaydi.
• Nosozliklarga chidamlilik: Mavjudlik yoki izchillikni yo'qotmasdan tugunlarning ozchiligining (N-tugunli klasterda (N-1)/2 gacha nosozliklar) ishdan chiqishiga bardosh bera oladi.
• Unumdorlik: Barqaror sharoitlarda (lider o'zgarishlari yo'q), Raft yuqori o'tkazuvchanlikka erisha oladi, chunki lider barcha so'rovlarni ketma-ket qayta ishlaydi va parallel ravishda replikatsiya qiladi, tarmoq o'tkazuvchanligidan samarali foydalanadi.
• Aniq belgilangan rollar: Aniq rollar (Lider, Kuzatuvchi, Nomzod) va holat o'tishlari aqliy modelni va amalga oshirishni soddalashtiradi.
• Konfiguratsiya o'zgarishlari: Klasterdan tugunlarni izchillikni buzmasdan xavfsiz qo'shish yoki olib tashlash uchun mustahkam mexanizmni (Birgalikdagi konsensus) taklif qiladi.

Kamchiliklari:

• Lider to'siqligi: Barcha mijoz yozish so'rovlari lider orqali o'tishi kerak. Juda yuqori yozish o'tkazuvchanligi bo'lgan yoki liderlar mijozlardan geografik jihatdan uzoq bo'lgan stsenariylarda bu unumdorlikda to'siq bo'lishi mumkin.
• O'qish kechikishi: Kuchli izchil o'qishlarga erishish ko'pincha lider bilan aloqani talab qiladi, bu esa potentsial kechikish qo'shadi. Kuzatuvchilardan o'qish eskirgan ma'lumotlarni o'qish xavfini tug'diradi.
• Kvorum talabi: Yangi yozuvlarni tasdiqlash uchun tugunlarning ko'pchiligi mavjud bo'lishini talab qiladi. 5 tugunli klasterda 2 ta nosozlikka bardosh berish mumkin. Agar 3 ta tugun ishdan chiqsa, klaster yozish uchun mavjud bo'lmaydi. Bu yuqori darajada bo'lingan yoki geografik jihatdan tarqalgan muhitlarda qiyin bo'lishi mumkin, bu yerda mintaqalar bo'ylab ko'pchilikni saqlab qolish qiyin.
• Tarmoqqa sezgirlik: Ayniqsa, keng tarqalgan joylashtiruvlarda saylov vaqtlariga va umumiy tizim o'tkazuvchanligiga ta'sir qilishi mumkin bo'lgan tarmoq kechikishi va bo'linishlariga juda sezgir.
• Konfiguratsiya o'zgarishlarining murakkabligi: Mustahkam bo'lishiga qaramay, Birgalikdagi konsensus mexanizmi Raft algoritmining to'g'ri amalga oshirish va sinchkovlik bilan sinab ko'rish uchun eng murakkab qismlaridan biridir.
• Yagona nosozlik nuqtasi (yozishlar uchun): Liderning ishdan chiqishiga nisbatan nosozliklarga chidamli bo'lsa-da, agar lider doimiy ravishda ishdan chiqsa va yangi lider saylana olmasa (masalan, tarmoq bo'linishlari yoki juda ko'p nosozliklar tufayli), tizim yozishlar bo'yicha oldinga siljiy olmaydi.

Xulosa: Chidamli global tizimlar uchun taqsimlangan konsensusni o'zlashtirish

Raft algoritmi murakkab muammolarni soddalashtirishda o'ylangan dizaynning kuchiga dalolatdir. Uning tushunarlilikka urg'u berishi taqsimlangan konsensusni demokratlashtirdi, bu esa kengroq doiradagi dasturchilar va tashkilotlarga avvalgi yondashuvlarning sirli murakkabliklariga berilmasdan yuqori darajadagi mavjud va nosozliklarga chidamli tizimlarni yaratish imkonini berdi.

Kubernetes (etcd orqali) bilan konteyner klasterlarini boshqarishdan tortib, CockroachDB kabi global ma'lumotlar bazalari uchun chidamli ma'lumotlar omborini ta'minlashgacha, Raft bizning raqamli dunyomiz izchil va ishchan bo'lib qolishini ta'minlaydigan jim ishchidir. Raft'ni amalga oshirish oson ish emas, lekin uning spetsifikatsiyasining aniqligi va uning atrofidagi ekotizimning boyligi uni mustahkam, masshtablanuvchi infratuzilmaning keyingi avlodini qurishga bel bog'laganlar uchun foydali harakatga aylantiradi.

Dasturchilar va arxitektorlar uchun amaliy tavsiyalar:

• Tushunishga ustuvorlik bering: Amalga oshirishga urinishdan oldin, Raft'ning har bir qoidasi va holat o'tishini chuqur tushunishga vaqt ajrating. Asl maqola va vizual tushuntirishlar bebaho manbalardir.
• Mavjud kutubxonalardan foydalaning: Ko'pchilik ilovalar uchun, agar talablaringiz juda ixtisoslashgan bo'lmasa yoki siz akademik tadqiqot olib bormayotgan bo'lsangiz, noldan qurish o'rniga yaxshi sinovdan o'tgan mavjud Raft implementatsiyalaridan (masalan, etcd, HashiCorp'ning Raft kutubxonasi) foydalanishni o'ylab ko'ring.
• Qat'iy sinov muhokama qilinmaydi: Har qanday taqsimlangan konsensus tizimi uchun nosozliklarni kiritish, xususiyatlarga asoslangan testlash va nosozlik stsenariylarining keng qamrovli simulyatsiyasi juda muhimdir. Hech qachon uni sinchkovlik bilan buzmasdan "u ishlaydi" deb o'ylamang.
• Global kechikish uchun loyihalang: Global miqyosda joylashtirganda, turli geografik mintaqalarda ham izchillik, ham unumdorlikni optimallashtirish uchun kvorum joylashuvingizni, tarmoq topologiyasini va mijoz o'qish strategiyalarini diqqat bilan ko'rib chiqing.
• Doimiylik va chidamlilik: Asosiy saqlash qatlamingiz mustahkam ekanligiga va ishdan chiqish stsenariylarida ma'lumotlar yo'qolishining oldini olish uchun fsync yoki shunga o'xshash operatsiyalar to'g'ri ishlatilishiga ishonch hosil qiling.

Taqsimlangan tizimlar rivojlanishda davom etar ekan, Raft tomonidan mujassamlangan tamoyillar — aniqlik, mustahkamlik va nosozliklarga chidamlilik — ishonchli dasturiy ta'minot muhandisligining asosiy tamoyillari bo'lib qoladi. Raft'ni o'zlashtirish orqali siz taqsimlangan hisoblashning muqarrar xaosi oldida bardosh bera oladigan chidamli, global masshtabli ilovalarni yaratish uchun kuchli vosita bilan o'zingizni qurollantirasiz.