مستقیم میرم سر اصل مطلب دیگه . . .
اصلا نیازی نیست حاشیه برم چون این موضوع شفافه
چطوری پیام های ارسال شده توسط producer توسط consumer مصرف میشه
1) At-most-once
اینجا میگیم که آقا جان حداکثر یبار، ینی این پیام اومد لطفا تمومش کن هر چی شد
ممکنه پیام از دست بره، ولی تکراری نمیشهههههه هرگززززز، تو این حالت consumer اول offset رو پردازش میکنه بعدش میگه خب حالا بریم سراغ کاری که پیامه ازم خواسته ببینم چه تسکی داریم پردازش کنیم
تو این حالا اگر بعد از commit کردن offset پردازش انجام نشه به هر دلیلی و یا کرش کنه دیگه پیام خونده نمیشه ، این یارو به درد پیام های کم اهمیت و لاگ های کم اهمیت میخوره و در کل میگن برای event هایی خوبه که از دست رفتنشون قابل تحمله برامون(ینی اگر از دست رفتن سکته نمیکنیم)
2) At-least-once
در اینجا شاهد رایج ترین حالت توی کافکا هستیم، وقتی اتفاق میوفته که بگی آقا جان حداقللللللللللل یه بار پیام منو پردازش کن دیگهههه، در نتیجه consumer اول پیام رو پردازش میکنه و در صورت موفق بودن پردازش میاد و offset رو commit میکنه خیلی شیک و مجلسی اگر پردازش به ارور بخوره در نتیجه اون offset دیگه commit نمیشه و و اینطوری میشه که باز دوباره از اول خونده میشه، صف مسدود میشه پیام ها پشت این یارو منتظر میمونن تا این انجام بشه(من بدبخت همین سه روز پیش با این موضوع داشتم سرو کله میزدم) و بعدش بیان انجام بشن، حالا موضوعی که هست اینه که این پترن وقتی خوبه که شما idempotency رو رعایت کنی که مباااااااادااااااااااااااا duplicate اتفاق بیوفته یه وقت خدایی نکرده
3) Exactly-once
این ینی پیام دقیقا یه بار پردازش بشه
ینی نه از دست بره و تکراری پردازش بشه
حالا این چطوری انجام میشه؟؟؟؟
کافکا اینو با ترکیب چیز میزای زیر مدیریت میکنه شیک:
Idempotent Producer
Transactions
مدیریت دقیق offset و commit
کجا به درد میخوره؟؟؟ ساده بگم حاجی مهمترین جاها، پردازش های مالی، pipeline های حساس، و در کل بخام بگم هرجایی که duplicate و یا loss data هردو مشکل ساز میشن و یقتونو میگیره
Exactly-once در Kafka بهصورت end-to-end همیشه ساده نیست، و معمولاً باید کل زنجیرهی پردازش درست طراحی شود.(توی مقاله بعدی در مورد این قراره مفصللللل صحبت کنیم)
4) Broadcast / Fan-out
این بیشتر برای وقتیه که میخای چنتا سرویس مختلف یه event رو ببینن و از یه event مطلع بشن،
مثلا یارو کاربر ثبت نام کرد خب نا خودآگاه یه ولت میخاد و یه سبد خرید دیگه مثلا پس یه event میفرستیم که فلانی اومد ثبت نام کرد هم ولت دریافتش کنه هم مثلا سفارشات (که سبد خرید توشه)
5) Load balancing داخل یک Consumer Group
این بیشتر برا وقتیه که چنتا consumer داری که تو یه group هستن، ینی دقیقا یه groupId دارن
در این شرایط کافکا اگر برای producer یه partition تعریف شده باشه مسیج هارو فقط توی همون partition میفرسته و قانون طلایی کافکا <هر partition فقط به یک consumer در group مشخص متصل میشود> باعث میشه که علنا بقیه ی consumer ها بی فایده بشینن و مسیج ها همه به consumer اول بره
در نتیجه این روش میاد میگه آقا جان بیا به تعداد دوبرابر consumer های موجود در یک group هنگام ساخت اون topic پارتیشن تعریف کن دیگههههههه
اینجوری میتونید load balancing انجام بدید، و یا خود کافکا به صورت دیفالت (اگر key نداشته باشید) round-robin هست انجام میده و هر پیام رو تو یه پارتیش ارسال میکنه.
مقاله بعدی قراره در مورد سومین پترن حرف بزیم
مقاله بعد ترش میخام درمورد load balancing در کافکا حرف بزنم
من حسینم و امیدوارم کمی به دیدتون نسبت به کافکا کمک کرده باشم
دوستون دارم
همچنین میتونید منو توی بله هم پیدا کنید(به امید اینترنت آزاد و تلگرام)
https://ble.ir/sungeek
