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

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

Consensus ও Raft: এক সিদ্ধান্তে সম্মতি

Consensus and Raft

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

আগে পড়ে নিনLeader Election ও Service Discovery-এর ভূমিকা ↗

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

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

Consensus-এর safety ও liveness বুঝুন
Raft term ও majority দেখুন
Database client হিসেবে consensus-এর সীমা জানুন

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

তিন node-এ product configuration আছে। দুটি admin একই setting বদলাচ্ছেন। প্রতিটি node আলাদা order-এ update apply করলে final configuration ভিন্ন হয়। Replication থাকলেই একই সিদ্ধান্ত আসে না; কোন command আগে স্থায়ী হবে তা নিয়ে agreement লাগে।

সহজ করে বুঝি

Consensus replicated log-এর জন্য node-গুলোকে একই ordered decision-এ একমত করে। Raft-এ follower, candidate ও leader ভূমিকা থাকে; term একটি election epoch। Leader log entry replicate করে এবং protocol-এর commitment rule মেনে apply করে। Safety মানে conflicting committed decision না হওয়া; liveness মানে উপযুক্ত network ও majority থাকলে অগ্রগতি হওয়া।

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

তিন সদস্যের কমিটি numbered resolution খাতায় লেখে। চেয়ারম্যান প্রস্তাব দেন, সংখ্যাগরিষ্ঠ নথিভুক্ত করার পর resolution কার্যকর হয়। একা বিচ্ছিন্ন সদস্য পুরোনো খাতায় নতুন সিদ্ধান্ত লিখলেও সেটি কমিটির অনুমোদিত সিদ্ধান্ত নয়। বাস্তব protocol-এ term এবং log matching নিয়মও থাকে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Consensus-এর safety ও liveness বুঝুন

Diagram-এর text flow দেখুন

sequenceDiagram
 participant C as Client
 participant L as Leader term 8
 participant F as Follower 1
 participant G as Follower 2
 C->>L: Configuration change
 L->>F: Append entry
 L->>G: Append entry
 F-->>L: Durable acknowledgment
 L-->>C: Committed result

Client leader-এ command দেয়। Leader followers-এ log পাঠায়। নিজের copy ও একটি follower তিন node-এর majority গঠন করতে পারে, protocol-এর অন্য শর্ত সাপেক্ষে। Diagram সরলীকৃত; actual Raft-এ current-term commitment এবং log consistency checks গুরুত্বপূর্ণ।

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

Laravel app-এর জন্য নিজে Raft লেখা এই পাঠের লক্ষ্য নয়। Consensus-backed configuration service-এর HTTP API ব্যবহার করার fragment দেখানো হয়েছে। URL internal trusted service, response schema validated এবং admin authorization আগে হয়েছে ধরে নিন।

use Illuminate\Support\Facades\Http;

$response = Http::baseUrl(config('services.config.url'))
    ->withToken(config('services.config.token'))
    ->connectTimeout(1)->timeout(3)
    ->put('/settings/checkout-limit', [
        'expected_version' => $expectedVersion,
        'value' => $validated['limit'],
    ]);

if ($response->status() === 409) {
    abort(409, 'Configuration changed; read the latest version.');
}
$response->throw();
return response()->json($response->json());

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

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

Consensus coordination state নিরাপদ রাখে, কিন্তু majority ছাড়া write availability হারায় এবং network round trip লাগে। সব page view consensus দিয়ে serialize করলে অপ্রয়োজনীয় bottleneck। Ownership, metadata ও critical configuration-এর মতো ছোট state-এ এটি বেশি উপযোগী।

সাধারণ ভুল

Replica সংখ্যা বাড়ালেই সব node বন্ধ থাকলেও write চলবে ভাবা।
Leader response-কে durable majority commit না জেনে success ধরা।
Raft malicious node-এর বিরুদ্ধে সুরক্ষা দেয় দাবি করা।

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

পাঁচ node-এর majority তিন; তখন দুটির failure সহ্য করা সম্ভব, যদি অবশিষ্ট তিন একে অন্যের সঙ্গে যোগাযোগ করতে পারে। Membership পরিবর্তনও protocol-এর অংশ; সরাসরি পুরোনো list বদলে দিলে overlapping majority হারাতে পারে।

তিন-node test cluster-এ leader isolate করুন। Minority side যেন নতুন committed write না দেয় এবং majority side নতুন leader বেছে নেয় দেখুন। Client timeout হলে operation-এর result অজানা থাকতে পারে; consensus service থাকলেও application idempotency দরকার।

মনে রাখুন

একই log order consensus-এর কেন্দ্রে।
Safety এবং progress পৃথক।
Consensus service ব্যবহার করুন, অনুমান নয়।

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

তিন-node ও পাঁচ-node cluster-এ কোন network split-এ write হবে তার table লিখুন। Majority আছে মানে client সব সময় পৌঁছাতে পারবে কি না ব্যাখ্যা করুন।

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

1. Raft কী মেলায়?

Replicated log-এর ordered commands; application একই commands deterministicভাবে apply করলে state মিলতে পারে।

2. Term কেন?

Election epoch চেনায় এবং পুরোনো leadership শনাক্ত করতে সাহায্য করে; timestamp নয়।

3. Majority হারালে?

সাধারণত নতুন commitment থামে। Safety রাখার জন্য এটি ইচ্ছাকৃত availability সীমা।

4. সব failure সহ্য করে?

না। Crash ও network failure model-এর protocol; Byzantine আচরণের জন্য আলাদা assumptions লাগে।

5. Laravel retry কি নিরাপদ?

একই command দুইবার apply হওয়া ঠেকাতে operation identity ও server-side deduplication দরকার।

এই পাঠের কুইজ

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

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

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

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

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