نصب Kafka در Ubuntu دیگر نباید از دستورهای قدیمی Kafka 2.8.2 و ZooKeeper این صفحه شروع شود. این راهنما اکنون یک آزمایش محلی با KRaft را توضیح می‌دهد. اگر کلاستر و دادهٔ موجود دارید، این مراحل نصب تازه را روی آن اجرا نکنید؛ ارتقا و مهاجرت به برنامهٔ جداگانه نیاز دارند.
وضعیت Ubuntu 20.04 و نسخهٔ Kafka
طبق چرخهٔ Ubuntu، پشتیبانی امنیتی استاندارد 20.04 در مه ۲۰۲۵ پایان یافته و پوشش توسعه‌یافته شرایط جداگانه دارد. برای استقرار تازه، نسخهٔ تحت پشتیبانی و سازگار را انتخاب کنید. نگه داشتن URL قدیمی مقاله به معنی توصیهٔ نصب تازه روی 20.04 نیست.
Kafka بستر رویداد است. نگهداری پیام به سیاست retention، ظرفیت و پیکربندی بستگی دارد و ذاتاً به معنی ذخیرهٔ همیشگی نیست. مصرف‌کننده‌ها نیز با سازوکار دریافت داده کار می‌کنند؛ ادعای قدیمی برتری همیشگی بر RabbitMQ بدون آزمون کاربرد معتبر نیست.
پیش‌نیاز نصب Kafka در Ubuntu
یک محیط آزمایشی جدا، کاربر عادی و جاوای سازگار با نسخهٔ انتخابی لازم است. راهنمای شروع رسمی در زمان بازبینی Java 17 یا جدیدتر را برای نمونهٔ جاری ذکر می‌کند. سازگاری دقیق را با مستندات همان انتشار بررسی کنید:
java -versionنصب وابستگی‌ها را مدیر سیستم انجام می‌دهد؛ حسابی که Kafka را اجرا می‌کند به عضویت دائمی sudo نیاز ندارد. مقدار حافظه و دیسک را با بار واقعی و retention انتخاب کنید؛ عدد ثابت ۴ گیگابایت تضمین ظرفیت همهٔ کاربردها نیست.
دریافت بسته و ساخت محیط جدا
بستهٔ باینری را از لینک دانلود Apache در راهنمای رسمی بگیرید و checksum یا امضای انتشار را بررسی کنید. نام فایل و پوشه باید با همان نسخه منطبق باشد. بسته را در پوشه‌ای خالی و متعلق به کاربر آزمایش استخراج کنید و وارد پوشهٔ استخراج‌شده شوید.
برای نمونهٔ فعلی، فایل تنظیم config/server.properties استفاده می‌شود. قبل از شروع، listener کاربر را به localhost روی ۹۰۹۲ و listener کنترلر را به localhost روی ۹۰۹۳ محدود کنید؛ مقدار advertised.listeners نیز باید آدرس قابل دسترس همان کاربر آزمایش باشد. پورت‌های این آزمایش را عمومی باز نکنید.
آماده‌سازی KRaft فقط روی فضای تازه
KRaft مدیریت فراداده را داخل معماری Kafka انجام می‌دهد. در آزمایش تک‌گرهی می‌توان نقش‌ها را ترکیب کرد؛ این شکل استقرار تحمل خرابی کلاستر چندگرهی را ندارد.
در فایل تنظیم، مسیر log.dirs را به یک پوشهٔ خالی و اختصاصی آزمایش با مسیر مطلق تغییر دهید. سپس یک شناسه بسازید و همان فضای تازه را آماده کنید:
LAB_CLUSTER_ID=$(bin/kafka-storage.sh random-uuid)
bin/kafka-storage.sh format -t "$LAB_CLUSTER_ID" --standalone -c config/server.propertiesفرمان format برای راه‌اندازی اولیه است؛ آن را راه‌حل عمومی خطای اجرای کلاستر یا مجوزی برای بازفرمت دادهٔ موجود ندانید. نسخه‌های متفاوت ممکن است فایل تنظیم یا گزینه‌های متفاوت داشته باشند.
شروع سرویس و ساخت topic آزمایشی
bin/kafka-server-start.sh config/server.propertiesاین ترمینال را باز نگه دارید. در ترمینال دوم و همان پوشهٔ Kafka، یک topic با نام مشخص بسازید:
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic hostnegar-lab --partitions 1 --replication-factor 1ضریب یک برای این آزمایش تک‌گرهی است و نسخهٔ دیگری از داده ایجاد نمی‌کند. آن را تنظیم آمادهٔ محیط حساس عملیاتی فرض نکنید.
آزمون نوشتن و خواندن
bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic hostnegar-labیک پیام غیرحساس بنویسید و با Ctrl+C از تولیدکننده خارج شوید. سپس پیام را بخوانید:
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic hostnegar-lab --from-beginningظاهر شدن همان پیام، آزمون اولیهٔ مسیر ارسال و دریافت است. اگر اتصال خطا دارد، لاگ broker، آدرس listener و advertised.listeners را بررسی کنید؛ صرفاً فایروال را خاموش نکنید.
پیش از استفادهٔ عملیاتی
این راهنما سرویس systemd دائمی یا کلاستر آمادهٔ تولید ایجاد نمی‌کند. برای آن مرحله، نگهداری داده، replication، امنیت ارتباط و احراز هویت، مجوزها، پایش و راه‌اندازی پس از بوت باید طراحی شوند. برای پایان آزمایش از توقف عادی پردازش استفاده کنید و دادهٔ مورد نیاز را بدون تصمیم روشن حذف نکنید.
مطالعهٔ مرتبط
بازبینی فنی: ۱۴ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
