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

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

Kafka বনাম RabbitMQ: workload অনুযায়ী broker

Kafka vs. RabbitMQ

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

আগে পড়ে নিনKafka: partition, offset ও consumer group ↗RabbitMQ: exchange, queue ও message routing ↗

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

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

Workload দিয়ে broker নির্বাচন করুন
Replay routing ও operations তুলনা করুন
ছোট system-এর সহজ বিকল্প রাখুন

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

Team পাঁচ হাজার দৈনিক email পাঠাতে Kafka cluster বানাতে চাইছে, কারণ বড় কোম্পানি ব্যবহার করে। অন্য team সাত দিনের clickstream history Laravel Redis queue দিয়ে রাখতে চায়। দুটো সিদ্ধান্তেই actual access pattern-এর বদলে technology popularity কাজ করছে।

সহজ করে বুঝি

Broker নির্বাচন একটি requirements decision। Task dispatch, per-message routing, replay, retention, throughput, ordering scope এবং team operations একসঙ্গে দেখতে হয়। RabbitMQ queue/exchange model task routing-এ উপযোগী; Kafka partitioned log independent replayable consumption-এ শক্তিশালী। দুই platform-এর অন্য feature-ও আছে, তাই কঠোর slogan দিয়ে বিচার নয়।

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

চিঠি একজন কর্মীকে দিয়ে কাজ করানো এবং সবার জন্য সংবাদ archive রাখা ভিন্ন ব্যবস্থা। Sorting desk ও library দুটোতেই কাগজ আছে, কিন্তু খোঁজার পদ্ধতি, সংরক্ষণকাল এবং দায়িত্ব আলাদা। দৈনিক দশটি চিঠির জন্য বড় archive ভবন দরকার নাও হতে পারে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Workload দিয়ে broker নির্বাচন করুন

Diagram-এর text flow দেখুন

flowchart TD
 R[Requirements] --> Q[Task routing and acknowledgments]
 R --> L[Replayable event history]
 Q --> A[Compare Redis Queue and RabbitMQ]
 L --> B[Compare Kafka and managed logs]
 A --> O[Operational budget]
 B --> O

প্রথম split primary workload আলাদা করে, definitive product rule দেয় না। Task workload-এ Laravel Redis queue যথেষ্ট কি না দেখুন। Replay দরকার হলে log retention গুরুত্বপূর্ণ। শেষে failure recovery, cost এবং team দক্ষতা দিয়ে candidate যাচাই করা হয়।

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

Laravel queue configuration fragment-এ সহজ Redis connection বেছে dispatch দেখানো হয়েছে। এটি Kafka বা RabbitMQ-এর API নয়। SendReceipt job idempotent এবং redis connection configured আছে। Future adapter লাগলেও business payload একই রাখতে stable contract তৈরি করুন।

use App\Jobs\SendReceipt;

$event = [
    'event_id' => $eventId,
    'type' => 'order.paid.v1',
    'order_id' => $order->id,
];
SendReceipt::dispatch($event)
    ->onConnection('redis')
    ->onQueue('receipts')
    ->afterCommit();

logger()->info('receipt.queued', [
    'event_id' => $eventId,
    'queue' => 'receipts',
]);
// A requirement for historical replay would need a durable event log too.

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

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

একটি broker দিয়ে সব workload চালালে operations কমতে পারে, কিন্তু mismatch থেকে application জটিল হয়। দুটি broker দিলে সঠিক tool পাওয়া যায়, কিন্তু security, monitoring, upgrades ও incident burden দ্বিগুণের দিকে যেতে পারে। Demonstrated need ছাড়া দ্বিতীয় infrastructure যোগ করবেন না।

সাধারণ ভুল

Kafka সব সময় দ্রুত এবং RabbitMQ সব সময় ছোট workload—এমন absolute claim করা।
Managed service-এর bill দেখে staff operations cost বাদ দেওয়া।
Queue থেকে replay history পাওয়া যাবে ধরে data retention না লেখা।

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

Benchmark তুলনায় message size, replication, acknowledgment, durability, network এবং failure recovery সমান রাখতে হয়। Publish throughput একা end-to-end latency নয়। Backlog drain time ও consumer outage-এর পরে recovery capacity বেশি গুরুত্বপূর্ণ হতে পারে।

এক ঘণ্টার consumer outage ধরে incoming rate এবং recovery service rate হিসাব করুন। Recovery rate incoming rate-এর চেয়ে বেশি না হলে backlog কখনও শেষ হবে না। দুই candidate-এ একই durability policy দিয়ে test চালান; ফল নিজের workload-এর estimate হিসেবে লিখুন।

মনে রাখুন

Product name নয় access pattern আগে।
Replay এবং task retry আলাদা চাহিদা।
Operations-ও architecture cost।

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

Email jobs, payment events ও click analytics-এর জন্য decision matrix লিখুন। প্রতিটিতে retention, ordering, loss tolerance এবং staffing দিন।

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

1. সব ক্ষেত্রে Kafka?

না। Replay দরকার না হলে simple queue operationalভাবে যথেষ্ট হতে পারে।

2. RabbitMQ replay পারে না?

Platform-এর stream feature-ও আছে; নির্দিষ্ট queue/log feature ও version দেখে তুলনা করতে হবে।

3. এক broker ভালো?

Complexity কমায়, তবে requirement মেলেনি হলে application workaround বাড়তে পারে।

4. কোন metric প্রধান?

আপনার workload-এর end-to-end latency, recovery এবং correctness; headline throughput নয়।

5. Laravel adapter কী দেখব?

Maintained version, acknowledgment, retries, transaction dispatch এবং failure behavior; শুধু install success নয়।

এই পাঠের কুইজ

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

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

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

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

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