واحد موازیسازی رو کجا بذاریم: بروکر یا کلاینت؟
خلاصهٔ کاملتر
این پست یه انشعاب از سری «Share Groupهای کافکا و موازیسازی مصرف»ه. نویسنده تو بخشهای قبلی نشون داده بود که share groupها رو خیلی راحت میشه اشتباه استفاده کرد: با ترکیب بدی از تنظیمات، چندتا کانسیومر همهچی رو برمیدارن و بقیه گشنه میمونن و همزمان lag بالا میره.
حالا سؤال بنیادیتر رو میپرسه: اصلاً share group برای موازیسازی ساخته شده؟ جوابش نهست. به گفتهٔ نویسنده، اینها اومدن که معنای صف رو روی لاگ سوار کنن. کانسیومر گروپ فقط یه آفست کامیتشده به ازای هر پارتیشن نگه میداره، ولی share group باید وضعیت تکتک رکوردها رو دنبال کنه: کدوم در دسترسه، کدوم تحویل کی شده، کدوم تأیید شده و کدوم باید دوباره در دسترس بشه.
البته این یعنی share group ابزار بدی برای موازیسازی نیست؛ اگه پیامهات مستقل باشن یا با ترتیب شل مشکلی نداشته باشی، گزینهٔ سادهایه برای اینکه واحد موازیسازی رو از تعداد پارتیشن جدا کنی. ولی نویسنده میگه حرف اصلی اینه که موازیسازی بالاخره یه جایی باید حساب بشه.
اون دو حالت رو مقابل هم میذاره. اگه واحد موازیسازی خودِ کانسیومر باشه، برای هر واحد کار باید یه مصرفکنندهٔ سریالی اضافه کنی و هر کدوم برای بروکر یه سری تعامل پروتکلی، وضعیت و دستکم یه کانکشن TCP میسازه. اگه موازیسازی از داخل کلاینت بیاد — ترد مجازی، تسک ناهمگام یا حتی ترد سیستمعامل — بروکر اصلاً ازش خبردار نمیشه.
برای اینکه بفهمی چقدر موازیسازی لازم داری، یه حساب ساده میده: aggregate parallelism = rate * avg processing time in seconds. یعنی نرخ ورودی ضرب در میانگین زمان پردازش هر پیام.
نتیجهش وقتی عدد میذاری ترسناک میشه. با ۶۰ هزار پیام در ثانیه و یک ثانیه زمان پردازش، به ۶۰ هزار واحد موازی نیاز داری؛ اگه واحدت کانسیومر سریالی باشه یعنی ۶۰ هزار کانسیومر. با ۱۰ ثانیه پردازش، عدد به ۶۰۰ هزار کانسیومر و بیش از یک میلیون کانکشن میرسه. ولی اگه بیشتر کار I/O باشه و یه کلاینت بتونه هزار پیام رو همزمان پردازش کنه، همون سناریوی اول با ۶۰ کانسیومر جمع میشه.
جمعبندی نویسنده اینه که مدیریت ترد مجازی یا حتی ترد سیستمعامل خیلی ارزونتر از نگه داشتن کانکشن و متادیتا به ازای هر واحد کاره، و این حرف مخصوص کافکا نیست و تو هر سیستم پیامرسانی صدق میکنه. هزینهش پیچیدگی بیشتر سمت کلاینته؛ کتابخونههایی برای این کار هست، هرچند ParallelConsumer دیگه نگهداری نمیشه و شاید حالا به یه کتابخونهٔ تازه برای موازیسازی سمت کلاینت روی share groupها نیاز باشه.
نکات کلیدی:
- share group اومده تا معنای صف رو روی لاگ بیاره، نه اینکه راهحل موازیسازی باشه
- کانسیومر گروپ یه آفست به ازای پارتیشن نگه میداره، share group وضعیت تکتک رکوردها رو
- فرمول تخمین: نرخ پیام ضرب در میانگین زمان پردازش
- واحد موازیسازی اگه کانسیومر باشه، برای بروکر یعنی کانکشن و وضعیت پروتکلی بیشتر
- ترد مجازی و تسک ناهمگام برای بروکر نامرئیان و خیلی ارزونتر تموم میشن
