Consensus — taqsimlangan tizimdagi bir nechta node nosozlik va xabar kechikishlariga qaramay bitta qiymat yoki amallar tartibi bo‘yicha kelishish jarayonidir. U leader saylash, replicated log, konfiguratsiya va metadata boshqaruvida ishlatiladi. Consensus barcha distributed muammoni hal qilmaydi, ammo umumiy qaror uchun qat’iy model beradi.
Asosiy xususiyatlar
Safety ikki sog‘lom node qarama-qarshi yakuniy qaror qabul qilmasligini bildiradi. Liveness tizim yetarli sharoitda yangi qaror qila olishini anglatadi. Network partition paytida safety saqlash uchun minority odatda write qabul qilmaydi; bu availabilityning vaqtincha kamayishidir.
Consensus algoritmi crash fault yoki Byzantine fault modelida ishlashi mumkin. Raft va Paxos odatda node yolg‘on zararli xabar yubormaydi, balki to‘xtashi yoki aloqa uzilishi mumkin degan crash modeliga qaratilgan. Byzantine consensus zararli yoki ixtiyoriy xatti-harakatni ham hisobga oladi va boshqa quorum talabiga ega.
Quorum
Ko‘pchilik quorum n node uchun floor(n/2)+1 ovozdir. Uch node cluster bitta, besh node ikki failurega chidashi mumkin, agar qolganlar o‘zaro aloqa qila olsa. Juft node qo‘shish failure tolerance ni har doim oshirmaydi; to‘rt node ham ikki failuredan keyin majority yo‘qotadi.
Quorum guruhlar kesishishi sabab ikki alohida majority bir xil termda qarama-qarshi qiymatni commit qila olmaydi. Node sonini faqat ko‘paytirish latency va operatsion xarajatni oshiradi. Geografik tarqatishda quorum round-trip va write latency o‘rtasida muvozanat tanlanadi.
Leader va log
Raftda node follower, candidate yoki leader bo‘ladi. Election timeout tugasa follower candidatega aylanib ovoz so‘raydi. Majority olgan node term davomida leader bo‘ladi. Randomized timeout bir nechta candidate doim teng qolishini kamaytiradi.
Client write leaderning replicated logiga kiradi. Entry majorityga yetgach commit qilinadi va state machinega qo‘llanadi. Follower keyinroq yetishmayotgan entrylarni olishi mumkin. Clientga javob qachon berilishi durability va linearizability talabiga bog‘liq.
Nosozlik holatlari
Eski leader partitionda qolib, majority yangi leader saylashi mumkin. Term yoki epoch eski leaderning keyingi yozuvlarini rad etish uchun ishlatiladi. Fencing bo‘lmasa eski node tashqi storagega write qilib split-brain side effect keltirishi mumkin.
Disk to‘lishi, soat siljishi, sekin node va uzoq GC pause oddiy “node down”dan murakkabroq. Timeout juda qisqa bo‘lsa keraksiz election, juda uzun bo‘lsa failure detection kechikadi. Monitoring term change, commit latency va replication lagni ko‘rsatadi.
Snapshot va membership
Log cheksiz o‘smasligi uchun state snapshot olinadi va eski entrylar compact qilinadi. Yangi node snapshot hamda keyingi logni olib qo‘shiladi. Snapshotning checksum va atomik o‘rnatilishi muhim.
Cluster membershipni bir bosqichda noto‘g‘ri almashtirish ikki quorum xavfini yaratishi mumkin. Joint consensus eski va yangi konfiguratsiya kesishadigan o‘tish holatidan foydalanadi. Operator node almashtirish runbookini algoritm talabiga mos bajaradi.
Client semantikasi
Leader almashganda client timeout olishi mumkin, holbuki yozuv commit bo‘lgan bo‘lishi ehtimol. So‘rovni oddiy qayta yuborish duplicate amal yaratadi. Client ID va monoton request sequence yordamida state machine oldin bajarilgan buyruq javobini taniydi. Read uchun ham faqat istalgan followerdan qiymat olish linearizable natija bermaydi; leader lease, quorum confirmation yoki read index kabi mexanizm kerak. Consensus logning kelishuvini beradi, lekin client retry va tashqi side effect semantikasini ilova hal qiladi.
Bog‘liq tushunchalar
Raft, Paxos, Quorum, Leader election, Replicated log, Network partition, Linearizability