Kafka، RabbitMQ، Outbox و SagaKafka, RabbitMQ, Outbox & Saga

بیشتر باگ‌های ترسناکِ سیستم‌های بزرگ آنجا زاده می‌شوند که یک پیام از یک سرویس خارج می‌شود و به سرویسِ دیگری می‌رود. این فصل درباره‌ی همان مرز است: چطور دو تکه از نرم‌افزار بدون اینکه هم‌زمان روشن باشند با هم حرف بزنند، و چطور کاری کنی که وقتی چیزی خراب شد — و حتماً خراب می‌شود — سیستم به‌جای گم‌کردنِ سفارش یا دوبار پول‌گرفتن از مشتری، درست بماند.

بیا اول با یک قول شروع کنیم: تا آخرِ این فصل، هر واژه‌ای که در مصاحبه‌ی سنیور می‌شنوی — broker، partition، offset، at-least-once، idempotent، Outbox، Saga، compensation — را نه‌فقط می‌شناسی، بلکه می‌توانی از صفر بسازی و توضیح بدهی.

بخش ۰ — واژه‌هایی که باید بلد باشی

قبل از هرچیز، چهار واژه را از ریشه باز کنیم تا بعداً سردرگم نشوی.

• producer (تولیدکننده): برنامه‌ای که پیام می‌فرستد (فرستنده‌ی نامه).
• consumer (مصرف‌کننده): برنامه‌ای که پیام را می‌گیرد و کاری با آن می‌کند (گیرنده‌ی نامه).
• idempotent (خنثی‌به‌تکرار): عملی که اگر دوبار انجامش بدهی، نتیجه با یک‌بار فرقی نکند. کلیدِ برق را «خاموش‌کن» idempotent است — هرچند بار بزنی، لامپ خاموش می‌ماند؛ اما «دکمه‌ی پرداختِ ۱۰۰ تومان» idempotent نیست، چون دوبار زدن یعنی ۲۰۰ تومان.
• at-least-once (حداقل یک‌بار): تضمینِ اینکه پیام حتماً می‌رسد، اما شاید بیش از یک‌بار. این کلمه در کلِ فصل ستون است؛ همین‌جا نگهش دار.

مدل ذهنی: یک بروکر واقعاً چه چیزی به تو می‌دهد

یک message broker زیرساختی است که producer و consumer را در زمان و مکان از هم جدا می‌کند. در مکان، چون producer نیازی نیست بداند چه کسی مصرف می‌کند؛ در زمان، چون consumer می‌تواند هنگام ارسالِ پیام down (خاموش) باشد. همین جداسازی کلِ ارزشِ کار است — و در عین حال کلِ منشأِ درد.

حالا مهم‌ترین جمله‌ی این فصل: دو مدلِ ذهنیِ غالب وجود دارد و اشتباه‌گرفتنشان ریشه‌ی بیشتر تصمیم‌های معماریِ بد است.

• RabbitMQ یعنی بروکرِ باهوش / consumerِ ساده. بروکر منطقِ مسیریابی (exchangeها و bindingها) را نگه می‌دارد، وضعیتِ هر پیام را دنبال می‌کند و پیام را پس از ack (تأیید) حذف می‌کند. این یک صف (queue) است: کار مصرف می‌شود و می‌رود.
• Kafka یعنی بروکرِ ساده / consumerِ باهوش. بروکر یک commit log فقط‌افزودنی (append-only)، پارتیشن‌بندی‌شده و replicate‌شده (تکثیرشده روی چند ماشین برای دوام) است. فراتر از یک offset به‌ازای هر consumer group، دنبال نمی‌کند «چه کسی چه چیزی را خواند». پیام‌ها طبقِ سیاستِ زمان/حجم نگه‌داری می‌شوند، مستقل از مصرف، پس قابلِ بازپخش (replay) هستند. این یک لاگ (log) است، نه صف.

(نکته‌ی جلوجلو: Kafka 4.0 با KIP-932 و «share group»ها معنای صف را هم به‌صورت opt-in اضافه می‌کند — بعداً می‌رسیم، ولی مرز دارد کمی محو می‌شود.)

RabbitMQ: exchangeها، queueها، bindingها

RabbitMQ پروتکلِ AMQP 0-9-1 را پیاده می‌کند. اولین چیزی که تازه‌کارها را غافلگیر می‌کند این است: producer هرگز مستقیم به یک queue منتشر نمی‌کند. به یک exchange با یک routing key منتشر می‌کند، و exchange تصمیم می‌گیرد کدام queueها کپی بگیرند.

انواعِ exchange تعیین می‌کنند این «قوانین توزیع» چطور کار می‌کنند:

بیایید یک مثالِ topic را تصویری ببینیم. * یعنی «دقیقاً یک کلمه» و # یعنی «صفر یا چند کلمه» — پس order.created.* به order.created.eu می‌خورد ولی order.# به هر چیزی که با order. شروع شود:

                 binding: order.created.*
producer --publish("order.created.eu")--> [topic exchange] ---> [queue: eu-fulfilment]
                                                            \--> [queue: analytics]  (binding: order.#)

تأییدها: ack، nack، reject

اینجا محلِ زندگیِ بیشترِ باگ‌هاست، پس آرام برویم.

وقتی consumer یک پیام می‌گیرد، RabbitMQ آن را unacked علامت می‌زند — تحویل‌شده اما تأییدنشده. consumer باید به بروکر بگوید چه شد:

• basic.ack — با موفقیت پردازش شد؛ بروکر حذفش می‌کند.
• basic.nack / basic.reject — پردازش شکست خورد. با requeue=true به صف برمی‌گردد؛ با requeue=false دور ریخته یا dead-letter می‌شود.

اگر channel/connectionِ مصرف‌کننده پیش از ack بمیرد، RabbitMQ به consumerِ دیگری redeliver می‌کند (دوباره تحویل می‌دهد). همین redelivery دقیقاً دلیلِ at-least-once بودن است — و همین‌جاست که باید idempotent باشی.

// مصرف‌کننده‌ی Spring AMQP با ack دستی و DLQ برای شکست غیرقابل‌تکرار
@RabbitListener(queues = "orders.q", ackMode = "MANUAL")
public void onOrder(Message msg, Channel channel) throws IOException {
    long tag = msg.getMessageProperties().getDeliveryTag();
    try {
        OrderEvent e = deserialize(msg.getBody());
        handle(e);                             // باید idempotent باشد
        channel.basicAck(tag, false);          // false = فقط همین پیام، نه «چندتایی»
    } catch (TransientException ex) {
        // requeue=true -> بعداً retry. مراقب حلقه‌ی بی‌نهایتِ redelivery باش.
        channel.basicNack(tag, false, true);
    } catch (PoisonMessageException ex) {
        // requeue=false -> به DLX/DLQ برو؛ روی پیام خراب تا ابد حلقه نزن
        channel.basicNack(tag, false, false);
    }
}

به آن deliveryTag دقت کن — این شماره‌ی رسیدِ همان پیام است روی همان channel، و false دومی یعنی «فقط همین یکی را ack کن، نه همه‌ی قبلی‌ها».

Dead Letter Exchange (DLX) و DLQ

یک پیام «dead-lettered» می‌شود وقتی با requeue=false رد شود، از TTL بگذرد (Time To Live، عمرِ مجازِ پیام)، یا queue به x-max-length برسد. آن‌گاه RabbitMQ آن را به یک dead-letter exchange پیکربندی‌شده بازمنتشر می‌کند که به یک DLQ مسیریابی می‌شود. این تورِ نجاتِ تو برای poison message است (پیامِ زهرآگین: پیامی که هربار می‌خواهی پردازشش کنی خطا می‌دهد و اگر بی‌نهایت requeue شود، سیستم را فلج می‌کند).

یک توپولوژیِ retryِ رایج و باهوش: صفِ اصلی → روی شکست، dead-letter به یک صفِ تأخیر با TTL → پس از پایانِ TTL، دوباره dead-letter به صفِ اصلی. این بدونِ هیچ schedulerی به تو retryِ تأخیری می‌دهد. همیشه تعدادِ تلاش‌ها را سقف بگذار (شمارنده‌ی headerِ x-death را دنبال کن) تا پیامِ دائماً‌خراب در یک DLQِ نهایی برای بررسیِ انسانی بنشیند، نه در حلقه‌ی بی‌نهایت.

Prefetch (QoS): پیچِ throughput در برابر انصاف

به‌طور پیش‌فرض یک consumer حریصانه پیام‌های unackedِ زیادی buffer می‌کند، پس یک مصرف‌کننده‌ی کند کار را انبار می‌کند در حالی که بقیه بیکارند. basic.qos(prefetchCount) تعدادِ پیام‌های unackedی را که بروکر یک‌جا به یک channel می‌فرستد سقف می‌گذارد.

• prefetch = 1 ← بیشترین انصاف، کمترین throughput (یک round-trip به‌ازای هر پیام). برای کارهای طولانی و ناهموار خوب است.
• prefetch = بالا ← throughputِ بالا، انصافِ بد، حافظه‌ی بیشتر، و پنجره‌ی از‌دست‌رفتِ بزرگ‌تر روی crash.

آن را حدوداً روی ceil(round_trip_latency / processing_time) به‌ازای هر مصرف‌کننده تنظیم کن. اشتباه‌کردنِ همین، شماره‌یِ‌یکِ تیکت‌های «RabbitMQ کند است» است که در واقع اصلاً تقصیرِ RabbitMQ نیست.

دوام (durability) و quorum queue

برای اینکه پیام از restartِ بروکر جان سالم به‌در ببرد به سه چیز با هم نیاز داری — و جاافتادنِ هرکدام یعنی بخارشدنِ پیام‌ها هنگام restart:

1. صفِ durable (خودِ صف روی دیسک ثبت شود، نه فقط در حافظه).
2. پیامِ persistent (delivery mode 2 — یعنی خودِ پیام هم روی دیسک نوشته شود).
3. publisher confirms (بروکر به producer تأیید بدهد که «گرفتم و روی دیسک نوشتم»).

Kafka: پارتیشن‌ها، offsetها، consumer groupها

یک topic در Kafka به پارتیشن‌ها (partition) تقسیم می‌شود. هر پارتیشن یک دنباله‌ی مرتب، تغییرناپذیر و فقط‌افزودنی است؛ موقعیتِ هر پیام در آن دنباله، offset آن است (یک عددِ long اکیداً صعودی، مثل شماره‌ی خطِ یک دفتر).

سه حقیقتِ کلیدی که بقیه از آن‌ها مشتق می‌شوند:

1. ترتیب فقط درونِ یک پارتیشن تضمین می‌شود، هرگز در سطحِ topic. اگر به ترتیبِ به‌ازای هر موجودیت نیاز داری (همه‌ی رویدادهای order-42 به‌ترتیب)، باید آن‌ها را به یک پارتیشن بفرستی — با استفاده از یک partition key. کافکا key را hash می‌کند و از رویش پارتیشن را انتخاب می‌کند، پس هر پیامی که همان key را داشته باشد به همان پارتیشن می‌رود.
2. یک consumer group مجموعه‌ای از مصرف‌کننده‌ها با group.idِ مشترک است. Kafka هر پارتیشن را به دقیقاً یک consumer در گروه اختصاص می‌دهد. پس بیشینه‌ی موازی‌سازیِ مفیدِ یک گروه برابرِ تعدادِ پارتیشن‌هاست. ۲۰ پارتیشن ⇐ حداکثر ۲۰ مصرف‌کننده‌ی فعال؛ نفرِ بیست‌ویکم بیکار می‌نشیند.
3. offsetها به‌ازای هر گروه commit می‌شوند، ذخیره در topicِ داخلیِ __consumer_offsets. این مکان‌نمای Kafka است — جایی که گروه از آن ادامه می‌دهد. دو گروهِ مختلف که همان topic را می‌خوانند کاملاً مستقل‌اند، هرکدام offsetِ خودش را دارد. اینطوری Kafka هم‌زمان هم pub/sub می‌کند و هم work-queue.

Topic "orders" (۳ پارتیشن)، Group "billing" (۲ مصرف‌کننده)

  P0: [o0 o1 o2 o3 ...]  --\
  P1: [o0 o1 o2 ...]      ---> consumer A  (مالک P0, P1)
  P2: [o0 o1 ...]         ---> consumer B  (مالک P2)
        ^offset commit‌شده به‌ازای (group, partition)

Rebalancing

وقتی یک consumer اضافه/حذف می‌شود یا می‌میرد، گروه rebalance می‌کند — پارتیشن‌ها بازتخصیص می‌شوند.

پروتکلِ قدیمیِ «eager» متوقف‌کننده‌ی کلِ دنیا بود: همه، همه‌چیز را revoke می‌کردند، بعد بازتخصیص (یک جهشِ latency). تخصیصِ cooperative sticky (پیش‌فرض از نسخه‌ی 2.4) فقط پارتیشن‌هایی را جابه‌جا می‌کند که باید. Kafka 4.0 پروتکلِ KIP-848 را می‌آورد، یک پروتکلِ rebalanceِ broker-driven (بروکر هدایت می‌کند، نه خودِ مصرف‌کننده‌ها) که افزایشی و به‌مراتب سریع‌تر است؛ مصرف‌کننده‌ها با group.protocol=consumer opt-in می‌کنند.

نگه‌داری (retention): لاگ یک صف نیست

Kafka پیام‌ها را طبقِ retention.ms (پیش‌فرض ۷ روز) یا retention.bytes نگه می‌دارد، مستقل از اینکه کسی مصرفشان کرد یا نه. مصرف‌کردن حذف نمی‌کند.

log compaction (cleanup.policy=compact) یک حالتِ retentionِ متفاوت است که فقط آخرین مقدار به‌ازای هر key را نگه می‌دارد و topic را به یک changelogِ durable / فضای‌کلیدِ materialized تبدیل می‌کند (stateِ Kafka Streams و snapshotهای CDC اینطور کار می‌کنند).

زمان‌بندیِ commit و تله‌اش

Properties p = new Properties();
p.put("bootstrap.servers", "kafka:9092");
p.put("group.id", "billing");
p.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
p.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
p.put("enable.auto.commit", "false");         // دستی commit کن، بعد از پردازش
p.put("auto.offset.reset", "earliest");
p.put("isolation.level", "read_committed");   // رکوردهای transactionalِ abort‌شده را نادیده بگیر

try (KafkaConsumer<String,String> c = new KafkaConsumer<>(p)) {
    c.subscribe(List.of("orders"));
    while (true) {
        ConsumerRecords<String,String> records = c.poll(Duration.ofMillis(500));
        for (ConsumerRecord<String,String> r : records) {
            process(r);                        // idempotent!
        }
        c.commitSync();                        // at-least-once: اول پردازش، بعد commit
    }
}

ترتیبِ process در برابر commit دقیقاً معنای تحویلِ تو را تعریف می‌کند:

• اول پردازش، بعد commit ← at-least-once (crash بعد از پردازش، پیش از commit ⇐ redelivery). این پیش‌فرضِ امن است.
• اول commit، بعد پردازش ← at-most-once (crash بعد از commit، پیش از پردازش ⇐ پیامِ گم‌شده). تقریباً هرگز چیزی نیست که بخواهی.

معنای تحویل و idempotency

حالا سه واژه‌ای که کلِ فصل حول آن‌ها می‌چرخد را کنار هم بگذاریم:

حقیقتِ سنیور: چون هرگز مطمئن نیستی ackت رسید، پس باید retry کنی، پس تکرار اجتناب‌ناپذیر است. آنچه هست پردازشِ دقیقاً‌یک‌بار (effectively-once) است که با بی‌ضررکردنِ تکرارها به‌دست می‌آید. دو مکانیزم:

۱. idempotency سمتِ مصرف‌کننده — پاسخِ جهانی. به هر پیام یک شناسه‌ی پایدارِ کسب‌وکاری/پیام بده و شناسه‌های پردازش‌شده را ثبت کن. پیش از عمل، به‌صورت atomic چک‌وست (check-and-set) کن.

// مصرف‌کننده‌ی idempotent با جدول dedup. قید unique روی message_id نگهبان است.
@Transactional
public void handle(PaymentEvent e) {
    try {
        jdbc.update("INSERT INTO processed_messages(message_id, at) VALUES (?, now())", e.id());
    } catch (DuplicateKeyException dup) {
        return;                    // قبلاً پردازش شده — no-opِ امن
    }
    applyPayment(e);               // همان tx: نشانه‌ی dedup + اثر با هم commit می‌شوند
}

نبوغِ این کد در قیدِ unique روی message_id است: دیتابیس خودش نگهبان می‌شود. اگر پیام تکراری بیاید، INSERT خطای DuplicateKeyException می‌دهد و ما امن برمی‌گردیم. چون هم درجِ نشانه و هم اثرِ واقعی در یک @Transactional هستند، یا هر دو با هم commit می‌شوند یا هیچ‌کدام.

۲. producerِ idempotent + transactions در Kafka — تکرارها را درونِ Kafka حل می‌کند.

روی آن transactions بگذار (با ست‌کردنِ transactional.id) تا به‌صورت atomic روی چند پارتیشن/topic بنویسی و offsetهای مصرف‌کننده را در یک واحدِ atomic کامیت کنی — حلقه‌ی «consume-transform-produce». مصرف‌کننده‌ها باید isolation.level=read_committed را ست کنند تا رکوردهای abort‌شده را رد کنند.

مسئله‌ی dual-write ← Transactional Outbox

حالا به یکی از مهم‌ترین باگ‌های معماری می‌رسیم؛ باگی که تقریباً در هر سیستمِ «میکروسرویس یک رویداد منتشر می‌کند» پنهان است.

// خراب: دو سیستم، بدون transaction مشترک
@Transactional
public void placeOrder(Order o) {
    orderRepo.save(o);            // (۱) به Postgres commit می‌شود
    kafka.send("orders", event); // (۲) به Kafka فرستاده می‌شود
}

راه‌حلِ کتابیِ 2PC (Two-Phase Commit، تراکنشِ دو-فازیِ XA) بینِ یک DB و Kafka است، اما Kafka از XA خوب پشتیبانی نمی‌کند و 2PC از نظرِ عملیاتی سمی است (coordinatorِ blocking، availabilityِ بد). نکن.

Transactional Outbox دو نوشتن را به یک نوشتن تبدیل می‌کند:

CREATE TABLE outbox (
    id           UUID PRIMARY KEY,
    aggregate_id TEXT NOT NULL,          -- partition keyِ Kafka می‌شود
    type         TEXT NOT NULL,          -- مثل 'OrderCreated'
    payload      JSONB NOT NULL,
    created_at   TIMESTAMPTZ DEFAULT now()
);

@Transactional  // یک local transaction — با ساختار، atomic
public void placeOrder(Order o) {
    orderRepo.save(o);
    outboxRepo.save(new OutboxRecord(
        UUID.randomUUID(), o.id().toString(), "OrderCreated", toJson(o)));
}

حالا یا هر دو ردیف commit می‌شوند یا هیچ‌کدام. سؤالِ باقی‌مانده این است: outbox چطور به Kafka می‌رسد؟ دو رویکرد:

• Polling publisher (ناشرِ نظرسنجی‌کننده): یک jobِ پس‌زمینه مدام SELECT ... FROM outbox WHERE published=false ORDER BY created_at FOR UPDATE SKIP LOCKED می‌زند، هرکدام را منتشر می‌کند، بعد mark/delete می‌کند. ساده، بدونِ زیرساختِ اضافه؛ عیب‌هایش latencyِ ناشی از polling و بارِ اضافه است. آن SKIP LOCKED اجازه می‌دهد چند pollerِ موازی بی‌خطر اجرا کنی — هر کدام ردیف‌های قفل‌شده‌ی دیگری را رد می‌کند.
• CDC (Change Data Capture، ثبتِ تغییرِ داده) با Debezium — انتخابِ سطحِ production. Debezium دنباله‌ی WAL پستگرس (Write-Ahead Log، لاگی که پستگرس قبل از هر تغییر می‌نویسد) را از راهِ logical replication می‌خواند، پس درج‌های commit‌شده‌ی outbox را بدونِ هیچ polling و با سربارِ نزدیک‌به‌صفر می‌بیند. Outbox Event Routerِ آن (یک SMT، تبدیلِ سبکِ پیام) هر ردیفِ outbox را به یک پیامِ درستِ Kafka باز می‌کند، بر اساسِ type مسیریابی و با aggregate_id کلیدگذاری می‌کند. این یک طراحیِ «log-follows-log» است: خودِ لاگِ durableِ دیتابیس منبعِ حقیقتِ رویدادها می‌شود.

Saga: تراکنشِ توزیع‌شده بدونِ 2PC

وقتی یک عملیاتِ کسب‌وکاری چند سرویس را در بر می‌گیرد (order ← payment ← inventory ← shipping) که هرکدام دیتابیسِ خودش را دارد، نمی‌توانی از یک تراکنشِ ACIDِ واحد استفاده کنی. یک Saga آن را با دنباله‌ای از تراکنش‌های محلی جایگزین می‌کند، که هر گام یک رویداد منتشر می‌کند که گامِ بعدی را راه می‌اندازد.

در Saga هیچ rollbackی در سطحِ سرویس‌ها نیست؛ در عوض هر گام یک عملِ جبران‌کننده (compensating action) دارد که آن را به‌طور معنایی خنثی می‌کند (بازپرداختِ یک شارژ، آزادسازیِ یک رزرو). Sagaها اتمیک‌بودن را با سازگاریِ نهایی (eventual consistency) معامله می‌کنند — سیستم از حالت‌های میانیِ قابل‌مشاهده عبور می‌کند.

Choreography در برابر Orchestration

Choreography — بدونِ هماهنگ‌کننده‌ی مرکزی. هر سرویس به رویدادها واکنش می‌دهد و رویدادِ خودش را منتشر می‌کند. OrderCreated → Payment گوش می‌دهد، شارژ می‌کند، PaymentCompleted می‌فرستد → Inventory گوش می‌دهد، رزرو می‌کند، StockReserved می‌فرستد → Shipping گوش می‌دهد…

• مزیت‌ها: کاملاً decoupled، بدونِ نقطه‌ی کنترلِ واحد، افزودنِ یک گام آسان است (فقط یک listenerِ جدید).
• عیب‌ها: جریانِ کسب‌وکار ضمنی و پخش‌شده در بینِ سرویس‌هاست — هیچ جای واحدی کلِ saga را نشان نمی‌دهد. دیباگ یک نوع باستان‌شناسی است؛ وابستگی‌های رویدادیِ حلقوی کم‌کم پیدا می‌شوند. برای جریان‌های کوتاه (۲ تا ۴ گام) بهترین است.

Orchestration — یک orchestratorِ مرکزی (اغلب یک state machine، ماشینِ حالت) جریان را مالک است، commandهای صریح می‌فرستد و منتظرِ پاسخ می‌ماند. تصمیم می‌گیرد گامِ بعدی چیست و روی شکست، جبران‌ها را به ترتیبِ معکوس می‌راند.

• مزیت‌ها: جریان در یک جای خوانا زندگی می‌کند؛ منطقِ شرطیِ پیچیده و timeoutها قابلِ مدیریت‌اند؛ ترتیبِ جبران آسان فهمیده می‌شود.
• عیب‌ها: orchestrator یک مؤلفه‌ای است که باید بسازی/بگردانی؛ خطرِ god-service شدن اگر منطقِ کسب‌وکار را در آن تلنبار کنی.

ORCHESTRATION (مسیرِ خوش‌فرجام بعد جبران)
 Orchestrator --Charge--> Payment      (ok)
 Orchestrator --Reserve--> Inventory   (FAILS: out of stock)
 Orchestrator --Refund---> Payment     (جبرانِ گامِ ۱، ترتیبِ معکوس)
 Orchestrator: saga = FAILED

// طرحِ یک گامِ orchestrator که با جبرانِ معکوس، شکست را مدیریت می‌کند
void onInventoryReserved(SagaState s) { s.markReserved(); dispatch(new ArrangeShipping(s.orderId())); }

void onInventoryFailed(SagaState s) {
    // ترتیبِ معکوس: پرداختی را که قبلاً انجام دادیم خنثی کن
    dispatch(new RefundPayment(s.paymentId()));
    s.markFailed("out_of_stock");
}

جبران، rollback نیست

بعضی اثرها اصلاً برگشت‌ناپذیرند (ایمیل فرستاده شد، موشک شلیک شد) — برای آن‌ها یک گامِ pivot/confirmation (لولا/تأیید) بگذار تا تا زمانِ commit شدنِ saga هیچ کارِ برگشت‌ناپذیری رخ ندهد. برای rollbackِ معنایی طراحی کن و انتظار داشته باش مسیرِ «بازیابیِ روبه‌عقب» به‌اندازه‌ی مسیرِ روبه‌جلو کد داشته باشد.

انتخاب یک بروکر

توجه: مرز دارد محو می‌شود. share groupهای KIP-932 در Kafka 4.0 معنای صف را به‌صورت opt-in اضافه می‌کنند (چند مصرف‌کننده به‌ازای هر پارتیشن، ack/lockِ per-message) — اما early-access است، تا 4.0/4.1 آماده‌ی production نیست، پس هنوز رویش طراحی نکن.

دام‌ها و گیرهای رایج

• @Transactional دورِ kafka.send — هیچ کاری نمی‌کند؛ بروکر در txِ DB نیست. از Outbox استفاده کن.
• فرضِ اینکه Kafka یک topic را مرتب می‌کند — یک پارتیشن را مرتب می‌کند. تغییرِ تعدادِ پارتیشن، پایداریِ key→partition و در نتیجه ترتیب را می‌شکند.
• مصرف‌کننده‌ها ≫ پارتیشن‌ها — مصرف‌کننده‌های اضافه‌ی Kafka بیکار می‌نشینند. با افزودنِ پارتیشن مقیاس بده (اما به‌سادگی نمی‌توانی کمشان کنی).
• autoAck در RabbitMQ — از‌دست‌رفتنِ بی‌صدای پیام روی crash. از ack دستی استفاده کن.
• بدونِ idempotency در downstream — هر سیستمِ at-least-once به تو تکرار تحویل می‌دهد؛ اگر پردازش idempotent نباشد، حتماً از کسی دوبار پول می‌گیری.
• حلقه‌ی poison-message — requeue/redeliveryِ بی‌نهایت که بروکر را می‌کوبد. تلاش‌ها را سقف بگذار → DLQ.
• پردازشِ طولانی > max.poll.interval.ms — Kafka فرض می‌کند consumer مرده و rebalance می‌کند، که پردازشِ تکراری می‌سازد. یا سریع‌تر پردازش کن، یا سقف را بالا ببر، یا کار را offload کن.
• باورِ اینکه «exactly-once» همه‌چیز را حل می‌کند — EOSِ Kafka فقط داخلِ Kafka است. اثرهای جانبیِ بیرونی هنوز idempotency می‌خواهند.
• prefetchِ بی‌کرانِ RabbitMQ — یک مصرف‌کننده‌ی حریص بقیه را گرسنه می‌گذارد و پنجره‌ی از‌دست‌رفتِ crash را بزرگ می‌کند.

سؤالات مصاحبه

هر سؤال را با صدای بلند تمرین کن؛ در مصاحبه‌ی سنیور نه‌فقط جوابِ درست، بلکه چراییِ آن ارزیابی می‌شود.

producer.send(new ProducerRecord<>("t", "k1", "a"));
producer.send(new ProducerRecord<>("t", "k2", "b"));
producer.send(new ProducerRecord<>("t", "k1", "c"));
// مصرف‌کننده مقادیر را به ترتیبی که از یک پارتیشنِ خودش می‌خواند چاپ می‌کند