Ticketing Raft প্যারামিটার
| বিষয় | মান |
|---|---|
| হার্টবিট ব্যবধান | ৫০০ms (cluster_heartbeat_ms) |
| সাড়াহীন বিবেচনার সময় | ২০০০ms (cluster_election_timeout_ms) — হার্টবিট এতক্ষণ বন্ধ থাকলে লিডার মারা গেছে ধরা হয় |
| প্রকৃত নির্বাচন শুরুর পরিসর | ১৭৫০ ~ ২০০০ms — প্রতিটি নোডে এলোমেলোভাবে ছড়ানো, যাতে একসাথে প্রার্থী হওয়া (split vote) না ঘটে। সর্বোচ্চ মানটিই সেট করা সাড়াহীন-বিবেচনার সময় |
| লিডার ব্যর্থতায় ক্লায়েন্টের থমকে থাকা | পরিমাপে সাড়াহীন বিবেচনার সময় + ০.৩~০.৫ সেকেন্ড (ডিফল্টে প্রায় ২.৩~২.৫ সেকেন্ড) — শনাক্তকরণের পর একবার রিডাইরেক্ট |
| নোড সংখ্যা | ৩ অথবা ৫ (কনফিগ লোডে বাধ্যতামূলক — অন্য সংখ্যায় বুট প্রত্যাখ্যাত) |
| নোড ID | cluster_peers তালিকায় নিজের (cluster_self) অবস্থান — তাই তালিকার ক্রম সব নোডে অভিন্ন হতে হবে |
| বুটস্ট্র্যাপ | চালুর ৫০০ms পর সব নোড একই মেম্বার গঠন দিয়ে ইনিশিয়ালাইজড হয় — ইতিমধ্যে ইনিশিয়ালাইজড ক্লাস্টারে যোগ দিলে উপেক্ষিত হয় |
| লগ সংরক্ষণ | ইন-মেমরি (উদ্বায়ী) — পুনরায় চালু হওয়া নোড রেপ্লিকেশন/স্ন্যাপশট দিয়ে পুনরুদ্ধার করে |
| lease মেয়াদ-শেষ শনাক্তকরণ | লিডার ১০০ms পর্যায়ক্রমে শনাক্ত করে ঐকমত্যের মাধ্যমে Expire কমিট করে |
wait টাইমআউটের সূক্ষ্মতা | অপেক্ষা টাইমআউট (T)-ও একই ১০০ms টিকে নির্ধারিত হয় — সর্বোচ্চ ১০০ms দেরিতে আসতে পারে |
| লিডার বদলের বিজ্ঞপ্তি | লিডার বদলালে সংযুক্ত সব ক্লায়েন্টকে সঙ্গে সঙ্গে L পাঠানো হয় |
হার্টবিট ও সাড়াহীন-বিবেচনার সময় বাছাই
দুটি মানই কনফিগে cluster_heartbeat_ms ও cluster_election_timeout_ms দিয়ে নিয়ন্ত্রণ করা হয়। সাড়াহীন বিবেচনার সময় (T)-ই লিডার ব্যর্থ হলে সেবা যতক্ষণ থমকে থাকে সেই সময়; উল্টো দিকে খুব ছোট হলে জীবিত লিডারকেই মৃত ধরে অপ্রয়োজনীয় নির্বাচন ঘটে।
| হার্টবিট / T | শনাক্তকরণের পরিসর | লিডার kill-এ সর্বোচ্চ বিলম্ব (পরিমাপ) | প্রস্তাবিত পরিবেশ |
|---|---|---|---|
| ১০০ms / ৬০০ms | ৪৫০~৬০০ms | প্রায় ০.৯ সেকেন্ড | একই র্যাক·একই AZ, অত্যন্ত স্থিতিশীল লেটেন্সি |
| ১০০ms / ১০০০ms | ৭৫০~১০০০ms | প্রায় ১.২ সেকেন্ড | একই AZ |
| ২৫০ms / ২৫০০ms | ১৮৭৫~২৫০০ms | প্রায় ২.৮ সেকেন্ড | মাল্টি-AZ |
| ৫০০ms / ২০০০ms | ১৭৫০~২০০০ms | প্রায় ২.৪ সেকেন্ড | ডিফল্ট — মাল্টি-AZ-এ ভারসাম্য |
| ৫০০ms / ৫০০০ms | ৩৭৫০~৫০০০ms | প্রায় ৫.৩ সেকেন্ড | ক্রস-রিজিয়ন, বা লেটেন্সি বেশি ওঠানামা করে এমন পরিবেশ |
- স্বাভাবিক অবস্থায় প্রক্রিয়াকরণের বিলম্ব এই মানগুলোর সাথে সম্পর্কহীন (পরিমাপে p50 বদলায়নি) — এগুলো শুধু ব্যর্থতার সময় পুনরুদ্ধারের সময় নির্ধারণ করে।
- ফলোয়ার মারা গেলে কোনো মানেই ক্লায়েন্টে প্রভাব পড়ে না। উপরের বিলম্ব শুধু লিডার মারা গেলেই ঘটে।
- সীমাবদ্ধতা:
cluster_election_timeout_msঅন্তত ৬০০ms হতে হবে, এবং হার্টবিটের ৪ গুণ বা বেশি হতে হবে। (লোডের সময় একবার শিডিউলিং বিলম্বে দুটি হার্টবিট পুরোপুরি গিলে ফেলার ঘটনা পরিমাপ করা হয়েছে।)
নোড সংখ্যা ৩ বা ৫ কেন
কমিটের জন্য সংখ্যাগরিষ্ঠতা দরকার। জোড় সংখ্যার গঠন শুধু খরচ বাড়ায়, ব্যর্থতা-সহনশীলতা বাড়ায় না, তাই সার্ভার তা প্রত্যাখ্যান করে।
| নোড সংখ্যা | সংখ্যাগরিষ্ঠতা | একসাথে সহনীয় ব্যর্থতা |
|---|---|---|
| ২ | ২ | ০টি — একটি মারা গেলেই থেমে যায়। সিঙ্গেল মোডের চেয়ে ভালো কিছু না |
| ৩ | ২ | ১টি |
| ৪ | ৩ | ১টি — ৩-এর মতোই (শুধু খরচ বাড়ে) |
| ৫ | ৩ | ২টি |
ব্যর্থতার সময় আচরণের সারসংক্ষেপ
| পরিস্থিতি | আচরণ |
|---|---|
| লিডার নয় এমন নোডে ক্লায়েন্ট অনুরোধ | M (লিডারের ঠিকানা), লিডার অজানা হলে E no_leader |
| লিডার ব্যর্থতা | ৫০০-১০০০ms-এর মধ্যে নতুন লিডার নির্বাচিত। এর মাঝে অনুরোধে E no_leader → ক্লায়েন্ট আবার চেষ্টা করে |
| লিডার বদলের মুহূর্তে | অপেক্ষমাণ অর্জন অনুরোধ M/E no_leader দিয়ে পরিষ্কার হয় এবং ক্লায়েন্ট নতুন লিডারে আবার চেষ্টা করে |
| নোড পুনরায় চালু | খালি স্টেটে বুট → পিয়ারের লগ রেপ্লিকেশন/স্ন্যাপশট দিয়ে ধরে ফেলে |
| সংখ্যাগরিষ্ঠতা হারানো | কমিট অসম্ভব হয়ে যায় → লেখা বন্ধ (নিরাপত্তা প্রথম), সংখ্যাগরিষ্ঠতা ফিরে এলে স্বয়ংক্রিয়ভাবে আবার শুরু |
পরিভাষা
- সংখ্যাগরিষ্ঠতা (quorum) — মোট নোডের অর্ধেকের বেশি (৩-এ ২টি, বা ৫-এ ৩টি)। যেকোনো সিদ্ধান্তে সংখ্যাগরিষ্ঠতার সম্মতি লাগে বলে, বিচ্ছিন্ন হয়ে যাওয়া দুটি গ্রুপ কখনো একই সাথে ভিন্ন সিদ্ধান্ত কমিট করতে পারে না।
- নির্বাচন টাইমআউট (election timeout) — হার্টবিট ছাড়া কতক্ষণ অপেক্ষার পর একজন ফলোয়ার লিডার মারা গেছে ধরে নিয়ে নির্বাচন শুরু করে। প্রতি নোডে এলোমেলোভাবে ভিন্ন, যাতে একসাথে অনেকে প্রার্থী না হয়ে যায়।