পাঠ্যক্রম খুলুন

মধ্যবর্তী পর্যায়

Leader Election ও Service Discovery-এর ভূমিকা

Leader Election and Service Discovery

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনPartial Failure: কিছু component সচল, কিছু অনিশ্চিত ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

Leader election ও discovery আলাদা করুন
Split-brain ঝুঁকি চিনুন
Scheduler coordination সঠিকভাবে ব্যবহার করুন

সমস্যা দিয়ে শুরু

দুটি Laravel server একই সময়ে মাসের invoice generation চালাল। প্রত্যেকেই নিজেকে scheduler ভেবেছে। অন্যদিকে client পুরোনো leader address cache করে down server-এ request দিচ্ছে। একজন কাজের নেতা কে এবং তাকে কোথায় পাওয়া যাবে—দুটি আলাদা প্রশ্ন উঠেছে।

সহজ করে বুঝি

Leader election কিছু participant-এর মধ্যে নির্দিষ্ট দায়িত্বের একজন owner নির্বাচন করে। Service discovery healthy instance-এর address খুঁজে দেয়; leader নির্বাচন করে না। Lease expiry বা term-এর মাধ্যমে পুরোনো leadership শেষ হয়। একাধিক process নিজেকে leader ভাবতে পারলে protected resource-এ stale owner ঠেকানোর ব্যবস্থা লাগে।

পরিচিত একটি উপমা

একটি সভায় সভাপতি নির্বাচন করা এবং সভাপতির বর্তমান কক্ষের নম্বর জানা ভিন্ন কাজ। পুরোনো সভাপতি নতুন সিদ্ধান্ত পাঠালে দপ্তরকে মেয়াদ দেখতে হয়। শুধু দরজায় নতুন নাম ঝোলালে পুরোনো নির্দেশ স্বয়ংক্রিয়ভাবে বাতিল হয় না।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Leader election ও discovery আলাদা করুন

Diagram-এর text flow দেখুন

flowchart LR
 A[Scheduler A] --> C[(Shared Lock Store)]
 B[Scheduler B] --> C
 C -->|Lease granted| A
 A --> J[Invoice Job]
 D[Client] --> S[Discovery Registry]
 S -->|Healthy address| A

দুই scheduler একই shared store-এর lock নিতে চায়। এই সময়ে এক owner grant পায়। Job arrow নেতৃত্বের কাজ বোঝায়। Client registry থেকে address পায়, কিন্তু registry lookup একা সেই instance-এর current lease বৈধ প্রমাণ করে না।

PHP ও Laravel-এ প্রয়োগ

routes/console.php-তে Laravel Scheduler fragment। সব server একই central cache store ব্যবহার করবে। GenerateMonthlyInvoices command-এ নিজস্ব unique invoice constraint থাকা চাই; scheduler lock business deduplication-এর বিকল্প নয়। Sub-minute tasks বা দীর্ঘ command-এর expiry আলাদা বিবেচনা করুন।

use Illuminate\Support\Facades\Schedule;

Schedule::command('invoices:generate')
    ->monthlyOn(1, '02:00')
    ->name('monthly-invoices')
    ->onOneServer()
    ->withoutOverlapping(120);

// The command must still protect each customer's invoice identity.
// Example database uniqueness: customer_id + billing_month.
logger()->info('scheduler.configured', [
    'task' => 'monthly-invoices',
    'coordination_store' => config('cache.default'),
]);

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

সুবিধা, সীমাবদ্ধতা ও trade-off

Single leader কাজের ordering ও coordination সহজ করে; failure-এ election delay হয় এবং leader bottleneck হতে পারে। Partitioned ownership দিলে throughput বাড়ে, কিন্তু কোন shard-এর owner কে তার metadata ও rebalance দরকার।

সাধারণ ভুল

Discovery থেকে address পাওয়াকে valid leadership ভাবা।
প্রতি server-এ local file cache দিয়ে distributed lock আশা করা।
Election আছে বলে invoice unique constraint বাদ দেওয়া।

আরও একটু গভীরে

Lease client-এর clock ও pause behavior-এর সঙ্গে সম্পর্কিত। Process দীর্ঘক্ষণ থেমে পুনরায় চালু হলে নিজের পুরোনো ownership ব্যবহার করতে পারে। Fencing token resource-কে নতুন owner-এর পর পুরোনো request reject করতে দেয়।

দুটি scheduler একসঙ্গে চালিয়ে একই task claim দেখুন। Owner process বন্ধ করে recovery delay মাপুন। এরপর job-এর মাঝখানে pause দিন এবং অন্য worker কাজ নিলে duplicate invoice হয় কি না পরীক্ষা করুন। Database uniqueness business নিরাপত্তার শেষ স্তর হিসেবে কাজ করবে।

মনে রাখুন

Election ownership, discovery address দেয়।
Leadership চিরস্থায়ী নয়।
Business invariant আলাদা enforce করুন।

নিজে চেষ্টা করুন

Invoice task-এ leader বন্ধ হলে কোন অসমাপ্ত invoice পুনরায় হবে লিখুন। এক command চালু থাকা আর প্রত্যেক invoice একবার হওয়া কেন আলাদা ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. Discovery কি election?

না। Healthy address পাওয়া যায়; একমাত্র write authority বা lease বৈধতা নিজে থেকে আসে না।

2. Shared cache কেন?

সমস্ত scheduler-কে একই coordination state দেখতে হয়; আলাদা local store-এ সবাই lock পেয়ে যাবে।

3. Leader মারা গেলে?

Lease বা election timeout শেষে নতুন owner আসে; মাঝের সময় কাজ থামতে পারে।

4. onOneServer যথেষ্ট?

Scheduling duplication কমায়, কিন্তু business side effect crash ও retry থেকে আলাদা সুরক্ষা চায়।

5. Fencing কে মানবে?

যে database বা external resource write গ্রহণ করে; শুধু token তৈরি করে ব্যবহার না করলে লাভ নেই।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।