پیام های معاملاتی

پیام های معاملاتی مجموعه ای از تکنیک های معماری است که اطمینان از هماهنگی بین تغییرات وضعیت محلی (پایگاه داده/کش) و پیام ها در کارگزار/اتوبوس است. هدف: «حالت ثابت است ↔ پیام از دست رفته یا تکراری نیست» در صورت شکست، بازپرداخت، مقیاس بندی و چند اجاره.

1) معانی تحویل

در یک بار: سریع و ارزان، تلفات ممکن است، بدون طول می کشد.
حداقل یک بار: پیام ها را از دست نمی دهد، تکراری امکان پذیر است → idempotency مورد نیاز است.
(موثر) دقیقا یک بار: بدون از دست دادن و بدون طول می کشد قابل مشاهده برای اثرات کسب و کار، به دست آمده توسط ترکیبی از تکنیک های (صندوق/صندوق، معاملات تولید کننده/مصرف کننده، dedup).

2) چرا «دو حرف» خطرناک است

منطق ساده و بی تکلف «برای اولین بار به پایگاه داده ارسال، پس از آن به اتوبوس ارسال» (و یا بالعکس) می شکند زمانی که در حال سقوط بین مراحل: داده ها ثابت است، و این رویداد از دست داده است ؛ یا این رویداد از بین رفته است، اما هیچ اطلاعاتی وجود ندارد. پیام های معاملاتی این شکاف را برطرف می کند.

3) الگوهای اساسی

3. 1 جعبه خروجی (تولید کننده)

در یک معامله محلی، تغییر کسب و کار و ردیف را به جدول «خروجی» می نویسیم ؛ یک ناشر جداگانه خروجی را می خواند و در یک کارگزار با retras و backoff منتشر می کند. از دست دادن حذف شدند ؛ دو برابر توسط idempotency در میان مصرف کنندگان خاموش است.

3. 2 صندوق پستی/مصرف کننده بی نظیر

قبل از اجرای اثر، مصرف کننده «INSERT» را در «صندوق ورودی (مصرف کننده، event_id)» به عنوان کلید اصلی ایجاد می کند. درگیری کلید = رویداد در حال حاضر پردازش → جست و خیز. این است که چگونه «به طور موثر دقیقا یک بار» به دست می آید.

3. 3 خواندن فرآیند نوشتن با معامله افست

الگو برای buses log-oriented: مصرف کننده دسته را می خواند، در همان معامله تغییرات کسب و کار را ثبت می کند و «افست منتقل می شود». پس از تعهد، کارگزار پیام های مصرف شده را در نظر می گیرد. این حذف «خواندن → سقوط → تکرار» بدون تکرار در اثر.

3. 4 TSS/Sagas برای اثرات متقابل خدمات

هنگامی که شما نیاز به یک فرایند چند مرحله ای سازگار دارید، از TCC یا sagas استفاده کنید ؛ پیام ها - انتقال دستورات/رویدادها و معاملات - در سطح مراحل و جبران خسارت.

4) تولیدکنندگان و مصرف کنندگان بی نظیر

تولید کننده: پایدار 'message _ id '/' idempotency _ key'، ارسال مجدد با همان کلید اثرات جدیدی برای مشترکین ایجاد نمی کند ؛ حفظ توالی توسط کلید.
مصرف کننده: 'inbox' + idemotency کسب و کار (upsert/ادغام، بررسی آخرین نسخه/تجدید نظر).

5) نظم و علیت

مشارکت با کلید کسب و کار (به عنوان مثال، 'aggregate _ id'، 'tenant _ id') به طوری که رویدادهای یک شی به ترتیب می رسند.
شماره های متوالی/برچسب های زمانی را در داخل تعداد زیادی نگه دارید. هنگامی که دوباره ترسیم از DLQ، مشاهده «توسط کلید و پی در پی».
اگر نظم جهانی مهم نیست، نظم محلی را با کلید تضمین کنید و ثابت های دامنه را ثابت کنید.

6) جبران و رفع اثرات

گزینه A: «افست در DB»

«آخرین افست پردازش شده (پارتیشن، افست)» را به همان معامله ای که در آن داده های دامنه را تغییر می دهید بنویسید. هنگام راه اندازی مجدد، از افست بعدی ادامه دهید، از یک اثر تکراری جلوگیری کنید.

گزینه B: معامله کارگزار

برخی از کارگزاران از ضبط اتمی پیام ها و جبران خسارت در یک معامله تولید کننده/مصرف کننده حمایت می کنند. در صورت موجود بودن استفاده کنید، اما همیشه با توانایی مصرف کننده مکمل باشید.

7) Retrai، عقب نشینی، DLQ

فقط خطاهای قابل برگشت (timeouts، 5xx) را تکرار کنید، با عقب نشینی نمایی و لرزش.
غیر قابل برگشت (طرح/اعتبار سنجی) - بلافاصله در DLQ با ابرداده (مستاجر، کلید، افست، دلیل).
دوز redrave از DLQ (دسته، حد مجاز)، قبل از تکرار مدار را بررسی کنید، سفارش را با کلید مشاهده کنید.

8) چند اجاره و مناطق

شامل «tenant _ id»، «plan»، «region» در ابرداده پیام و کلیدهای پارتیشن.
عدالت هر مستاجر: انتشار/پردازش را محدود کنید تا مشتری «پر سر و صدا» بودجه را از بقیه کسر نکند.
اقامت: پیام ها و صندوق پستی را در همان منطقه به عنوان داده های دامنه ذخیره کنید. تکثیر بین منطقه ای - aggregates آسنکرون.

9) قابلیت مشاهده و حسابرسی

ردیابی: همبستگی 'event _ id '/' aggregate _ id '/' saga _ id', دهانه «خواندن → فرآیند → نوشتن/تعهد».
معیارها: تاخیر انتشار/پردازش (p95/p99)، میزان موفقیت، نرخ DLQ، موفقیت مجدد، «تکراری سرکوب شده».
سیاهههای مربوط: کوتاه برای موفقیت ؛ جزئیات مربوط به خطاها (دلیل، تلاش، کلید، جبران).
حسابرسی: که redrawn/نورد تماس، چه دسته و با چه نتیجه.

10) ایمنی و انطباق

به حداقل رساندن PII در payload ؛ ماسک هنگام انتقال به DLQ/سیاهههای مربوط.

امضاء/رمزبندی پیامها برای گذرگاههای خارجی ؛ استفاده از mTLS بین سرویس ها

مدیریت عمر مفید و «حق فراموش کردن» در هر مستاجر/منطقه.

11) طرح های ادغام معمولی

1. منبع خدمات (سمت نوشتن)

معامله محلی: رکورد دامنه + صندوق پستی.
ناشر: دسته، «SKIP LOCKED»، عقب نشینی، محدودیت در هر مستاجر.
نظارت بر تاخیر در حال حاضر − occurred_at'.

2. خدمات مصرف کننده (سمت خواندن)

خواندن دسته → تلاش برای "INSERT صندوق ورودی (مصرف کننده، event_id) → اگر موفقیت آمیز باشد، اثر را اجرا می کنیم.
در همان معامله، ما «افست منتقل شده» (گزینه A) را اصلاح می کنیم یا به معامله کارگزار (گزینه B) تکیه می کنیم.
در خطا: retray یا DLQ توسط سیاست.

3. نمایش پروژکتور/مادی شده

فقط به روز رسانی idempotent (upsert)، کلید deduplication جمع و جور، تایید checksum دوره ای.

12) قالب های پیکربندی (مثال)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) چک لیست پیش فروش

• حذف «دو حرف»: صندوق پستی در تولید کننده و یا رفع جبران و اثر در یک معامله در مصرف کننده.
• مصرف کننده idempotent: مجله 'inbox '/dedup، idempotency کسب و کار از عملیات.
• تقسیم بندی توسط کلید کسب و کار، سفارش محلی دنبال می شود.
• عقب نشینی + ردیابی لرزش، طبقه بندی خطا، DLQ غنی از ابرداده.
• Redrave دوز، امن ؛ کتابهای بازی وجود دارد.
• محدودیت ها و اولویت های چند مستاجر ؛ برچسبهای 'tenant _ id/plan/region'
• تله متری: تاخیر، میزان موفقیت، «تکراری سرکوب»، هشدار توسط p95/p99.
• سیاست های PII/حفظ/رمزگذاری اجرا می شود.
• تست: قطره بین مراحل، تکراری، منظور کلیدی، redraw توده.

14) خطاهای معمول

ارسال به اتوبوس و نوشتن به پایگاه داده در مراحل جداگانه بدون معامله outbox/offset.
مصرف کننده بدون idempotency → عوارض جانبی تکراری.
نظم جهانی «هر چه ممکن است» گران است و به ندرت توجیه می شود ؛ سفارش به اندازه کافی با کلید.
بازسازی عظیم بدون محدودیت → یک حادثه ثانویه.
فقدان معیارهای ردیابی/تاخیر → «تخریب پنهان».
PII مخلوط در DLQ/سیاهههای مربوط.

15) دستور العمل های سریع

رویدادهای SaaS: Outbox + مصرف کننده بی نظیر (صندوق ورودی)، پارتیشن بندی شده توسط 'tenant _ id: aggregate _ id'.
ETL/پیش بینی: خوانده شده روند نوشتن با جبران رفع در یک معامله، دسته 500-1000، uppert.
بار بالا: انتشار shardings، 'SKIP LOCKED'، WFQ در هر مستاجر، کنترل تاخیر.
منطقه انطباق دقیق: صندوق پستی منطقه ای، رمزگذاری بار، نگهداری و حسابرسی redrives.

نتیجه گیری

پیام رسانی تعاملی نظم و انضباط اتصال داده ها و پیام ها است. با ترکیب outbox/inbox، idempotency، offsets fixation همراه با اثرات و مدیریت مجدد با DLQ، شما رفتار عملی دقیقا یک بار بدون قفل جهانی و حفظ SLO حتی با سقوط، قله و بهره برداری پیچیده چند مستاجر.