تضمین سفارش پیام

1) «نظم» چیست و چرا لازم است

منظور از پیام ها یک رابطه «آنچه باید قبل از پردازش» برای رویدادهای یک نهاد (سفارش، کاربر، کیف پول) و یا برای کل جریان است. برای ناوردایی مهم است: «وضعیت A قبل از B»، «تعادل قبل از نوشتن»، «نسخه n قبل از n + 1».
در سیستم های توزیع شده، نظم کلی جهانی گران است و به ندرت مورد نیاز است. یک سفارش محلی برای کلید معمولا کافی است.

2) انواع ضمانت های سفارش

1. Per-partition (نظم محلی در بخش ورود به سیستم) - کافکا: نظم در داخل حزب حفظ شده است, بین احزاب - هیچ.
2. Per-key (سفارش کلید/گروه پیام) - تمام پیام ها با یک کلید به یک «موضوع» پردازش (کلید کافکا، SQS FIFO MessageGroupId، کلید Pub/Sub سفارش) روت می شوند.
3. سفارش کلی جهانی - کل سیستم یک سفارش واحد را می بیند (مجله توزیع شده/ترتیب سنج). گران، کاهش در دسترس بودن و توان.
4. نظم علی - «رویداد B پس از A اگر B اثر A را مشاهده کند». قابل دسترسی از طریق ابرداده (نسخه ها، Lamport-times/ساعتهای بردار) بدون ترتیب سنج جهانی.
5. سفارش بهترین تلاش - کارگزار تلاش می کند تا نظم را حفظ کند، اما در صورت شکست، جایگزینی ممکن است (اغلب در NATS Core، RabbitMQ با چندین مصرف کننده).

3) جایی که سفارش خراب می شود

مصرف کنندگان موازی از همان صف (RabbitMQ: چندین مصرف کننده در هر صف → interleaving).
Retrays/دوباره تحویل (حداقل یک بار)، «ACK» وقفه، دوباره صف.
تعادل مجدد/feilover (کافکا: حرکت حزب/رهبر).
DLQ/پردازش مجدد - پیام «سمی» به DLQ می رود، موارد بعدی بیشتر می شوند.
چند منطقه و تکرار - تاخیر های مختلف → ناهماهنگی.

4) طراحی سفارش کلیدی

• از کلیدهای طبیعی استفاده کنید: «order _ id»، «wallet _ id»، «aggregate _ id».
• سازمان دیده بان برای «کلید های داغ» - یک کلید می تواند «مسدود کردن» جریان (سر از خط مسدود کردن). در صورت لزوم، کلید را تقسیم کنید: "order _ id # shard (0.. k-1) "با بازسازی قطعی نظم روی سینک.
• در کافکا - یک کلید → یک بخش، ترتیب در داخل کلید حفظ خواهد شد.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(کلید = «سفارش» نظم محلی را تضمین می کند.)

5) «سفارش در مقابل پهنای باند»

• یک مصرف کننده در هر صف سفارش را حفظ می کند اما همزمانی را کاهش می دهد.
• حداقل یک بار + همزمانی عملکرد را بهبود می بخشد، اما نیاز به idempointency و/یا دوباره مرتب سازی.
• نظم جهانی می افزاید هاپ به ترتیب سنج → ↑latentnost و خطر شکست.

سازش: نظم در هر کلید، موازی = تعداد احزاب/گروه ها، + کبودی های بی نظیر.

6) کنترل سفارش در کارگزاران خاص

کافکا

نظم در حزب

مواظب باش. در. پرواز. درخواست ها برای اتصال ≤ 5 'с' فعال کنید. idempotence = true 'به طوری که retrays تولید کننده ترتیب را تغییر نمی دهد.
گروه مصرف کننده: یک حزب → یک کارگر در یک زمان. تحویل های مکرر امکان پذیر است → نگه داشتن دنباله/نسخه در لایه کسب و کار.
تراکنشهای read-process-write ثبات افست read/write/crumb را حفظ میکنند، اما یک نظم جهانی ایجاد نمیکنند.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

سفارش در یک صف برای یک مصرف کننده تضمین شده است. با چندین مصرف کننده پیام می تواند «مخلوط» شود.
برای سفارش: یک consummer یا prefetch = 1 + ack هنگامی که به پایان رسید. برای همزمانی، صفها را با کلیدها جدا کنید (sharding exchanges/consistent-hash exchange).

NATS/جت استریم

هسته NATS - بهترین تلاش، تاخیر کم، سفارش ممکن است مختل شود.
JetStream: سفارش در جریان/دنباله ؛ در طول تحویل مجدد، تنظیم مجدد در کنسول ممکن است → استفاده از دنباله و بافر بازیابی.

SQS FIFO

پردازش دقیق یک بار (به طور موثر، به دلیل deduplication) و سفارش در MessageGroupId. همروندی - تعداد گروه ها در یک گروه سر خط.

میخانه گوگل/زیر

کلید سفارش می دهد سفارش در کلید ؛ در صورت خطا، انتشار تا زمانی که بازسازی شود مسدود شده است - مراقب فشار پشتی باشید.

7) الگوهای حفظ و بازگرداندن نظم

7. 1 توالی/نسخه

• فقط در صورتی که 'seq = last_seq + 1';
• در غیر این صورت - بافر انتظار را قبل از ورود گمشده ('last _ seq + 1') قرار می دهد.

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 بافرها و پنجره ها (پردازش جریان)

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

7. 3 مسیریابی چسبنده با کلید

هش (کلید)٪ هش مسیریابی تمام رویدادهای کلیدی را به یک کارگر ارسال می کند.
در Kubernetes - حفظ یک جلسه (چسبنده) در سطح صف/شرد، نه در تعادل L4 HTTP.

7. 4 بازیگر مدل/» یک جریان در هر کلید«

برای aggregates بحرانی (کیف پول): بازیگر به طور متوالی پردازش می کند، بقیه موازی - تعداد بازیگران.

7. 5 Idempotence + مرتب سازی مجدد

حتی با بازسازی نظم، تکرار امکان پذیر است. ترکیب UPSERT توسط کلید + نسخه و صندوق (ببینید دقیقا یک بار در مقابل حداقل در یک بار).

8) کار با پیام های «سمی» (قرص های سمی)

حفظ نظم با وظیفه مواجه است: «چگونه می توان زندگی کرد اگر یک پیام پردازش نشود ؟»

سفارش دقیق: مسدود کردن جریان کلید (SQS FIFO: کل گروه). راه حل توسط کلید DLQ است: ما فقط کلید مشکل/گروه را به یک صف/تجزیه دستی جداگانه انتقال می دهیم.
سفارش انعطاف پذیر: ما اجازه می دهد پرش/جبران ؛ ما وارد سیستم می شویم و ادامه می دهیم (نه برای جمع آوری های مالی/انتقادی).
سیاست Retray: محدود 'حداکثر تحویل' + بازگشت + اثرات avidempotent.

9) سیستم های چند منطقه ای و جهانی

پیوند خوشه ای/تکرار (کافکا) نظم جهانی بین منطقه ای را تضمین نمی کند. اولویت را به ترتیب کلید محلی و کبودی های بی نظیر اختصاص دهید.
برای نظم واقعا جهانی، از یک ترتیب سنج (ورود به سیستم مرکزی) استفاده کنید، اما این در دسترس بودن تاثیر می گذارد (CAP: منهای A برای شکستن شبکه).
جایگزین: نظم علی + CRDT برای برخی از دامنه (شمارنده، مجموعه) - هیچ نظم دقیق مورد نیاز است.

10) قابل مشاهده بودن سفارش

Метрики: 'out _ of _ order _ total', 'reorded _ in _ window _ total', 'late _ events _ total', 'buffer _ size _ current', 'blocked _ keys _ total', 'fifo _ group _ backlog'.

11) ضد الگوهای

یک صف + بسیاری از مصرف کنندگان بدون sharding بر روی کلید - سفارش فورا خراب می شود.
Retray از طریق دوباره عمومی در همان صف بدون idempotency - دو برابر + خارج از دستور.
نظم جهانی «فقط در مورد» انفجار تاخیر و ارزش بدون سود واقعی است.
SQS FIFO یک گروه برای همه - سر خط کامل. استفاده از شناسۀ گروه پیام برای هر کلید.
نادیده گرفتن «کلید های داغ» - یک «کیف پول» همه چیز را کند می کند ؛ در صورت امکان کلید را به زیر کلیدها تقسیم کنید.
مخلوط کردن جریان بحرانی و فله در همان صف/گروه - نفوذ متقابل و از دست دادن نظم.

12) چک لیست پیاده سازی

• Per-key/per-partition/causial/global ؟
• کلید توالی و استراتژی کلید ضد داغ طراحی شده است.
• روتر پیکربندی شده: پارتیشن بندی/MessageGroupId/سفارش کلید.
• کنسول ها توسط کلید ها جدا می شوند (مسیریابی چسبنده، کارگران شارد).
• Idempotency و/یا صندوق ورودی/UPSERT در کبودی گنجانده شده است.
• دنباله/نسخه اجرا و مرتب کردن بافر (در صورت لزوم).
• DLQ توسط سیاست های کلیدی و بازپرداخت بازپرداخت.
• معیارهای خارج از ترتیب، blocked_keys، نظم late_events و هشدار.
• روز بازی: تعادل مجدد، از دست دادن گره، پیام سمی، تاخیر شبکه.
• مستندات: سفارش ثابت، مرزهای پنجره، تاثیر در SLA ها.

13) نمونه های پیکربندی

13. 1 مصرف کننده کافکا (به حداقل رساندن نقض سفارش)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (سفارش بر اساس قیمت همزمانی)

یک مصرف کننده در هر صف + 'اساسی. qos (prefetch = 1) '

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

تنظیم شناسۀ گروه پیام = کلید. همروندی = تعداد گروهها

MessageDeduplicationId برای محافظت در برابر تکراری (در پنجره ارائه دهنده).

13. 4 NATS JetStream (سفارش مصرف کننده، طرح)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

کلید> نظارت بر 'sequence' و مرتب کردن بافر در برنامه.

14) سوالات متداول

س: آیا من نیاز به یک نظم جهانی دارم ؟

A: تقریبا هرگز. تقریبا همیشه به اندازه کافی برای هر کلید. نظم جهانی گران و مقرون به صرفه است.

س: در مورد پیام «سمی» تحت نظم دقیق چیست ؟

A: فقط کلید/گروه خود را به DLQ انتقال دهید، بقیه - ادامه دهید.

س: آیا می توانید همزمان سفارش و مقیاس را دریافت کنید ؟

A: بله، سفارش کلید + بسیاری از کلید ها/قطعات + عملیات idempotent و مرتب کردن بافر در صورت لزوم.

س: کدام مهم تر است: سفارش یا دقیقا یک بار ؟

A: برای اکثر دامنه ها - منظور کلیدی + به طور موثر دقیقا یک بار اثرات (idempotency/UPSERT). حمل و نقل می تواند حداقل یک بار باشد.

15) مجموع

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