ডিস্ট্রিবিউটেড সিস্টেমের ইতিহাসে ঐকমত্য বা কনসেনসাস প্রটোকল দীর্ঘকাল ধরে প্যাক্সোস (Paxos)-এর একচ্ছত্র আধিপত্যে ছিল। কিন্তু প্যাক্সোসের চরম জটিলতা এবং বাস্তব সফটওয়্যারে ত্রুটিহীন ইমপ্লিমেন্টেশনের দুঃসাধ্যতার কারণে ২০১৪ সালে ডিয়েগো ওঙ্গারো এবং জন অউস্টারহাউট তৈরি করেন র্যাফ্ট (Raft) কনসেনসাস অ্যালগরিদম। র্যাফ্টের মূল দর্শন ছিল: সুরক্ষা ও নিরাপত্তার সঙ্গে কোনো আপস না করে সর্বোচ্চ বোধগম্যতা নিশ্চিত করা। সমগ্র সমস্যাকে তিনটি পরিষ্কার ধাপে—লিডার নির্বাচন (Leader Election), লগ রেপ্লিকেশন (Log Replication) এবং সেফটি (Safety)—ভাগ করে র্যাফ্ট আধুনিক ক্লাউড আর্কিটেকচার (Kubernetes etcd, TiKV, Consul, CockroachDB)-এর মূল ভিত্তিতে পরিণত হয়েছে।
১. র্যাফ্টের ত্রি-স্তরীয় নোড আর্কিটেকচার
র্যাফ্ট একটি শক্তিশালী ও কর্তৃত্বপরায়ণ লিডার-ভিত্তিক মডেল ব্যবহার করে। যেকোনো মুহূর্তে প্রতিটি নোড তিনটি অবস্থার যেকোনো একটিতে অবস্থান করে:
- লিডার (Leader): ক্লায়েন্টের সমস্ত রিকোয়েস্ট গ্রহণ করে, লগের ক্রমধারা নির্ধারণ করে এবং ফলোয়ারদের মধ্যে লগ রেপ্লিকেট করে।
- ফলোয়ার (Follower): নিষ্ক্রিয়ভাবে শুধুমাত্র লিডার ও ক্যান্ডিডেটের RPC বার্তার উত্তর দেয়। নির্দিষ্ট সময় কোনো বার্তা না পেলে সে ক্যান্ডিডেটে রূপান্তরিত হয়।
- ক্যান্ডিডেট (Candidate): নোডদের সংখ্যাগরিষ্ঠ ভোট পেয়ে নতুন লিডার হওয়ার প্রতিদ্বন্দ্বিতা করে।
সময়কে র্যাফ্টে টার্ম (Term) নামক ধারাবাহিক লজিক্যাল সংখ্যায় ($ au in mathbb{N}$) ভাগ করা হয়। এই টার্ম মূলত লজিক্যাল ঘড়ি হিসেবে কাজ করে এবং কোনো লিডার পুরনো বা বিচ্ছিন্ন হয়ে গেছে কিনা তা তাৎক্ষণিকভাবে শনাক্ত করে:
$$ au_{i} < au_{j} implies ext{নোড } i ext{ তৎক্ষণাৎ লিডারশিপ ত্যাগ করবে এবং টার্ম } au_j ext{-তে উন্নীত হবে}$$
২. র্যান্ডমাইজড লিডার নির্বাচন ও স্প্লিট-ভোট প্রতিরোধ
যখন কোনো ফলোয়ার নোড একটি নির্দিষ্ট সময়সীমার (Election Timeout) মধ্যে লিডারের হার্টবিট (`AppendEntries`) পেতে ব্যর্থ হয়, তখন সে নির্বাচন শুরু করে:
- টার্ম সংখ্যা বৃদ্ধি করে: $ au leftarrow au + 1$।
- ক্যান্ডিডেট অবস্থায় গিয়ে নিজের জন্য একটি ভোট প্রদান করে।
- অন্যান্য সমস্ত নোডের কাছে `RequestVote(term, candidateId, lastLogIndex, lastLogTerm)` RPC বার্তা পাঠায়।
একসাথে একাধিক ফলোয়ার ক্যান্ডিডেট হয়ে পড়লে ভোট সমানভাবে ভাগ হয়ে স্প্লিট-ভোট (Split-Vote) অচলাবস্থা তৈরি হতে পারে। র্যাফ্ট এই সমস্যা দূর করে র্যান্ডমাইজড ইলেকশন টাইমআউট (Randomized Election Timeout) ব্যবহার করে:
$$T_{ ext{election}} sim mathcal{U}(150, ext{ms}, 300, ext{ms})$$
প্রতিটি নোডের টাইমআউট এলোমেলো হওয়ায় একটি নোড সবার আগে ক্যান্ডিডেট হয় এবং অন্য নোডগুলো টাইমআউট হওয়ার আগেই সংখ্যাগরিষ্ঠ কোরামের ভোট পেয়ে নিশ্চিতভাবে লিডার নির্বাচিত হয়ে যায়।
৩. লগ ম্যাচিং ইনভেরিয়েন্ট (Log Matching Invariant)
নেটওয়ার্কের চরম অস্থিরতার মধ্যেও সমস্ত সার্ভারে ডেটা স্টেট মেশিনের ধারাবাহিকতা বজায় রাখতে র্যাফ্ট একটি কঠোর গাণিতিক নিয়ম নিশ্চিত করে। প্রতিটি লগ এন্ট্রিতে ইনডেক্স $i$, টার্ম $ au$, এবং কমান্ড $c$ থাকে: $e = langle i, au, c
angle$।
- ইনডেক্স ও টার্মের অভিন্নতা: দুটি পৃথক সার্ভারের লগে যদি একই ইনডেক্স এবং একই টার্মের এন্ট্রি থাকে, তবে তাদের ভেতরে সংরক্ষিত কমান্ড সম্পূর্ণ অভিন্ন হবে:
$$(e_1.i = e_2.i land e_1. au = e_2. au) implies e_1.c = e_2.c$$ - প্রিফিক্স সংগতি (Prefix Coherence): দুটি পৃথক সার্ভারের লগে কোনো একটি নির্দিষ্ট পজিশনে ইনডেক্স ও টার্ম মিলে গেলে, শুরুর ১ নম্বর ইনডেক্স থেকে শুরু করে সেই পজিশন পর্যন্ত পূর্ববর্তী সমস্ত এন্ট্রি একে অপরের সাথে নিখুঁতভাবে হুবহু মিলে যাবে।
লিডার যখন `AppendEntries` পাঠায়, তখন সে নতুন এন্ট্রির ঠিক আগের এন্ট্রির ইনডেক্স (`prevLogIndex`) এবং টার্ম (`prevLogTerm`) পাঠিয়ে দেয়। ফলোয়ার যদি দেখে তার লোকাল লগে এই পূর্ববর্তী এন্ট্রিটি নেই বা টার্ম মিলেনি, তবে সে রিকোয়েস্ট প্রত্যাখ্যান করে। তখন লিডার ফলোয়ারের লগের পিছন দিকে গিয়ে যেখানে মিল খুঁজে পায়, সেখান থেকে পুনরায় লগ সিঙ্ক করে প্রিফিক্স ইনভেরিয়েন্ট রক্ষা করে।
৪. লিডার কমপ্লিটনেস ও আপ-টু-ডেট ভোটিং নিয়ম
অন্যান্য প্রোটোকলে অনভিজ্ঞ নোডও লিডার হয়ে অন্য নোড থেকে মিসিং ডেটা নিয়ে আসতে পারে। কিন্তু র্যাফ্টে ডেটা প্রবাহ একমুখী (Strictly Unidirectional)—কেবল লিডার থেকে ফলোয়ারের দিকে। তাই এমন কাউকে লিডার হতে দেওয়া যাবে না যার লগে পূর্বে কমিট হওয়া কোনো ডেটা অনুপস্থিত রয়েছে। এটি নিশ্চিত করতে ভোটার নোডগুলো `RequestVote` যাচাইয়ের সময় আপ-টু-ডেট নিয়ম (Up-to-Date Rule) প্রয়োগ করে:
- ক্যান্ডিডেটের শেষ এন্ট্রির টার্ম $ au_c$ ভোটারের টার্ম $ au_v$-এর চেয়ে বড় হতে হবে ($ au_c > au_v$)।
- যদি উভয়ের টার্ম সমান হয় ($ au_c = au_v$), তবে ক্যান্ডিডেটের লগ দৈর্ঘ্য ভোটারের সমান বা বেশি হতে হবে ($i_c ge i_v$)।
পিজিয়নহোল নীতি অনুযায়ী, যে ডেটা ইতিপূর্বে কমিট হয়েছে তা অন্তত একটি নোডের লগে সংরক্ষিত আছেই। সেই নোডটি কখনোই কম আপ-টু-ডেট ক্যান্ডিডেটকে ভোট দেবে না। ফলে কোনো অবস্থাতেই অপরিপূর্ণ লগের ক্যান্ডিডেট লিডার হতে পারে না।
৫. জয়েন্ট কনসেনসাস ও ক্লাস্টার মেম্বারশিপ পরিবর্তন
চলমান সিস্টেমে সার্ভার যোগ বা অপসারণের ক্ষেত্রে পুরনো কনফিগারেশন $mathcal{C}_{ ext{old}}$ এবং নতুন কনফিগারেশন $mathcal{C}_{ ext{new}}$-এর মধ্যে ট্রানজিশন চলাকালীন স্প্লিট-ব্রেন এড়াতে র্যাফ্ট জয়েন্ট কনসেনসাস (Joint Consensus) ব্যবহার করে:
- লিডার একটি ট্রানজিশন এন্ট্রি $mathcal{C}_{ ext{old,new}}$ লগ করে।
- এই মধ্যবর্তী অবস্থায় যেকোনো সিদ্ধান্ত অনুমোদনের জন্য $mathcal{C}_{ ext{old}}$ এবং $mathcal{C}_{ ext{new}}$—উভয় কোরামের সংখ্যাগরিষ্ঠ ভোট পৃথকভাবে বাধ্যতামূলক করা হয়।
- জয়েন্ট কনসেনসাস সফলভাবে কমিট হওয়ার পর চূড়ান্ত একক কনফিগারেশন $mathcal{C}_{ ext{new}}$ চালু করা হয়, যা ক্লাস্টার কনফিগারেশনকে শূন্য ডাউনটাইমে নিরাপদ রাখে।
