WIUNIX ACADEMY
مصرف‌کنندهٔ Kafka عقب افتاده؛ علت‌یابی و تمرین امن تغییر offset
قبل از جابه‌جایی offset، نرخ پردازش، commit و اعضای گروه را بررسی کنید. سپس تغییر موقعیت یک partition را با مصرف‌کننده‌های خاموش و ثبت وضعیت قبلی تمرین کنید.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من9 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
فرق کندی پردازش و دیر ثبت‌شدن موقعیت را تشخیص دهید و برای یک گروه آزمایشیِ غیرفعال، تغییر موقعیت دقیق و بازگشت پیش از شروع دوباره را بررسی کنید.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
مسیرهای مستند برای Ubuntu، Debian و خانوادهٔ Red Hat؛ محصول و کلاینت سازگار باید از قبل نصب باشند. محدودیت هر شاخه در گام نخست آمده است. فرمان‌ها هنگام نگارش روی سرویس واقعی اجرا نشده‌اند.
قبل از شروع
- کلاستر موجود، topic مخصوص دادهٔ آزمایشی و گروه مصرف‌کنندهٔ معمولی؛ ابزارهای مدیریت Kafka 4.2 باید با محیط سازگار باشند.
- فایل محافظت‌شدهٔ اتصال با TLS/SASL، مجوز خواندن وضعیت و تغییر offset همان گروه آزمایشی و مسیر خصوصی برای ثبت موقعیت قبلی.
- امکان توقف همهٔ مصرف‌کننده‌ها و جلوگیری از روشن‌شدن خودکار آن‌ها؛ اگر کار بیرونی به تکرار حساس است، پیش از هر بازخوانی باید راه جلوگیری از تکرار آن مشخص باشد.
عدد lag دقیقاً چه چیزی را نشان می‌دهد؟
lag فاصلهٔ موقعیت ثبت‌شدهٔ گروه تا یک موقعیت انتهایی در log است؛ لزوماً مدت قدیمی‌بودن داده یا تعداد کارهای کسب‌وکار نیست. compaction، تراکنش‌ها و فاصله‌های بین offsetها می‌توانند رابطهٔ سادهٔ عدد و تعداد رخداد را به هم بزنند.
تغییر offset فقط جای خواندن را عوض می‌کند. با این کار مصرف‌کننده سریع‌تر نمی‌شود و نتیجهٔ کار قبلی هم برنمی‌گردد. ابتدا علت عقب‌افتادن را بررسی می‌کنیم؛ تمرین تغییر موقعیت نیز فقط روی دادهٔ آزمایشی و با همهٔ مصرف‌کننده‌ها خاموش انجام می‌شود.
این روش برای گروه معمولی است
از ابزارهای سازگار Kafka 4.2 و تنظیمات محافظت‌شدهٔ فعلی استفاده کنید. Kafka Streams، Connect و share group وضعیت و روش بازنشانی مخصوص خود را دارند و نباید دستورهای این مطلب را به آن‌ها تعمیم دهید.
برای دنبال‌کردن این راهنما کلاستر یا گروه را حذف نکنید و retention را عوض نکنید. اگر پردازش پیام در برنامه اثر بیرونی می‌سازد، عقب‌بردن موقعیت می‌تواند آن اثر را تکرار کند؛ پیش از چنین تصمیمی، طراحی برنامه برای تشخیص کار قبلی باید معلوم و آزموده باشد.
گروه، topic و partition را دقیق انتخاب کنید
نام‌ها و offset هدف را در فرم تنظیم کنید؛ رمز در فایل اتصال موجود می‌ماند. مقدارها در همین تب ذخیره و پس از «اعمال» در همهٔ پنل‌ها یکسان می‌شوند. هدف، موقعیتی است که مصرف بعدی باید از آن آغاز شود، نه شمارهٔ آخرین رکورد پردازش‌شده.
صفرِ نمونه را بی‌بررسی انتخاب نکنید. باید بدانید چه offsetهایی هنوز در topic موجودند و چرا شروع از آن نقطه از نظر برنامه درست است. فیلد فعلی مقاله حداکثر۱۰رقم می‌پذیرد؛ برای عدد بزرگ‌تر از۹۹۹۹۹۹۹۹۹۹، از رویهٔ جداگانه و بررسی‌شدهٔ همان محیط استفاده کنید و عدد را کوتاه نکنید.
قدم بعدی
پیش از شروع، مسیر ابزار و محل اجرای فرمان‌ها را بررسی کنید
این انتخاب مربوط به کلاینت مدیریت Kafka نسخهٔ ۴٫۲ روی Ubuntu نسخه‌های ۲۶٫۱۰ و ۲۶٫۰۴، Debian نسخه‌های ۱۳ و ۱۲ یا خانوادهٔ RHEL، Rocky و Alma شاخه‌های ۹ و ۱۰ است. Apache سازگاری نسخهٔ Java را مستند کرده، نه تأیید تک‌تک این توزیع‌ها را؛ با java -version بررسی کنید Java نسخهٔ ۱۷، ۲۱ یا ۲۵ از قبل در دسترس باشد. مسیر /opt/kafka/bin محل توزیع باینریِ موجود Apache در این مثال است و مسیر تضمین‌شدهٔ بستهٔ سیستم‌عامل نیست. اگر نصب شما پوشهٔ نسخه‌دار دارد، پیش از ادامه مقدار مسیر را اصلاح کنید. فایل محافظت‌شدهٔ تنظیمات کلاینت باید متعلق به همین کاربر و متصل به TLS/SASL موجود باشد؛ سرویس broker، پورت‌ها، فایروال و نصب Java در این تمرین تغییر نمی‌کنند.
این مسیرها از مستندات استخراج شده‌اند و آزمون عملی سازگاری محسوب نمی‌شوند. ابتدا /etc/os-release و نسخهٔ دقیق محصول را بررسی کنید. حساب‌ها، دسترسی شبکه و اعتبارنامه‌های محافظت‌شده باید از قبل آماده باشند. برای آماده‌کردن ابزارها، سرویس موجود را دوباره راه‌اندازی نکنید، دیتابیس تازه مقداردهی اولیه نکنید، پورتی روی فایروال باز نکنید و Python سیستم را تغییر ندهید.
کلاینت مدیریت مجاز؛ بررسی‌های مخصوص گره فقط روی همان گرهٔ موجود
cat /etc/os-release
id
java -version
test -x "/opt/kafka/bin/kafka-consumer-groups.sh"
"/opt/kafka/bin/kafka-consumer-groups.sh" --version
test -r "/etc/kafka/academy-client.properties"سیستم‌عامل، مسیر و نسخهٔ ابزار با محیط انتخابی سازگار است؛ در صورت تفاوت، پیش از تغییر داده توقف کنید.
قدم بعدی
عقب‌ماندگی را برای هر partition ببینید
از کلاینت مجاز، موقعیت ثبت‌شده، lag، اعضا و وضعیت گروه را بخوانید. فقط جمع نمودار را نبینید؛ ممکن است یک partition بیشترِ کار را نگه داشته باشد. این مشاهده را در بازه‌ای با بار کاری شبیه شرایط عادی برنامه و با مانیتورینگ موجود تکرار کنید.
اگر یک partition عقب می‌افتد، توزیع key و اندازهٔ رکوردها را بررسی کنید. رکوردهای همان partition باید به ترتیب پردازش شوند؛ صرف افزودن مصرف‌کننده، این کار را خودبه‌خود موازی نمی‌کند. گروهی که مدام عضو عوض می‌کند با برنامه‌ای که یک handler کند دارد، مسئلهٔ یکسانی ندارد.
کلاینت دارای مجوز مدیریت Kafka
'/opt/kafka/bin/kafka-consumer-groups.sh' --bootstrap-server 'kafka.example.com:9093' --command-config '/etc/kafka/academy-client.properties' --group 'academy_replay' --describe
'/opt/kafka/bin/kafka-consumer-groups.sh' --bootstrap-server 'kafka.example.com:9093' --command-config '/etc/kafka/academy-client.properties' --group 'academy_replay' --describe --members --verbose
'/opt/kafka/bin/kafka-consumer-groups.sh' --bootstrap-server 'kafka.example.com:9093' --command-config '/etc/kafka/academy-client.properties' --group 'academy_replay' --describe --state
'/opt/kafka/bin/kafka-topics.sh' --bootstrap-server 'kafka.example.com:9093' --command-config '/etc/kafka/academy-client.properties' --describe --topic 'academy_events'می‌دانید عقب‌ماندگی مربوط به کدام partition، کدام عضو و چه وضعیت گروهی است.
نرخ پردازش و فاصلهٔ commit را از هم جدا کنید
نرخ ورود، نرخ پردازش، زمان ثبت موقعیت، سن رکورد و مدت اجرای handler را کنار هم ببینید. ممکن است برنامه پیوسته کار کند، ولی commit را دسته‌ای انجام دهد و lag در نمودار پله‌ای پایین بیاید.
اگر پردازش نسبت به max.poll.interval.ms طول می‌کشد، rebalance را بررسی کنید؛ تغییر صرف session timeout این علت را حل نمی‌کند. هم‌زمانی بیشتر هم ممکن است مقصدی مثل دیتابیس را اشباع کند. جلو بردن offset برای صفرشدن نمودار می‌تواند کارهای پردازش‌نشده را جا بیندازد.