پارامترهای انتخاب کارگزار

هنگامی که مشتری می خواهد پیامی را از Apache Kafka ارسال کند یا دریافت کند ، دو نوع اتصال وجود دارد که باید موفق شود:

1. اتصال اولیه به یک کارگزار (بوت استرپ). این امر ابرداده را به مشتری باز می گرداند ، از جمله لیستی از همه کارگزاران خوشه و نقاط پایانی اتصال آنها.
2. مشتری سپس به یک (یا بیشتر) کارگزاران برگشتی در مرحله اول طبق نیاز متصل می شود. اگر کارگزار به درستی پیکربندی نشده باشد ، اتصالات از بین می روند.

آنچه گاهی اوقات اتفاق می افتد این است که افراد فقط روی مرحله 1 در بالا تمرکز می کنند و در مرحله 2 گرفتار می شوند. جزئیات کارگزار که در مرحله 1 برگشته است توسط تبلیغات تعریف شده است. دستگاه مشتری.

برای مطالعه بیشتر در مورد پروتکل ، به اسناد و همچنین این مقاله قبلی که نوشتم مراجعه کنید. اگر آجیل و پیچ و مهره پروتکل آخرین چیزی است که به آن علاقه دارید و فقط می خواهید برنامه هایی را با کافکا بنویسید ، باید ابر Climuent را بررسی کنید. این یک سرویس کاملاً مدیریت شده Apache Kafka در ابر است ، با یک تبلیغات تبلیغاتی.

در زیر ، من از مشتری وصل شده به کافکا در مجوزهای مختلف توپولوژی استقرار استفاده می کنم. این نوشته با استفاده از Python با Librdkafka (confluent_kafka) نوشته شده است ، اما این اصل برای مشتریان در تمام زبانها اعمال می شود. می توانید کد را در GitHub پیدا کنید. این بسیار ساده است و فقط برای نشان دادن روند اتصال خدمت می کند. این برای وضوح ساده است ، با هزینه برنامه نویسی خوب و عملکرد

یک نمونه مصور از مشتری کافکا که به یک کارگزار وصل می شود

بیایید تصور کنیم که دو سرور داریم. از طرف دیگر مشتری ما است و از طرف دیگر کارگزار تک خوشه کافکا ما است (لحظه ای را فراموش کنید که خوشه های کافکا معمولاً حداقل سه کارگزار دارند).

1. مشتری اتصال به سرور (های) bootstrap را آغاز می کند ، که یکی (یا بیشتر) کارگزاران موجود در خوشه است.
2. کارگزار به ابرداده باز می گردد ، که شامل میزبان و پورت است که به همه کارگزاران این خوشه می رسد.
3. این لیست همان چیزی است که مشتری سپس برای همه اتصالات بعدی برای تولید یا مصرف داده از آن استفاده می کند. آدرس مورد استفاده در اتصال اولیه به سادگی برای مشتری است که یک سرور bootstrap را در خوشه کارگزاران N پیدا کند ، که از آن به مشتری لیست فعلی از همه کارگزاران داده می شود. به این ترتیب ، مشتری لازم نیست همیشه لیست همه کارگزاران را بداند. دلیل نیاز مشتری به جزئیات همه کارگزاران این است که مستقیماً به یک یا چند کارگزاران متصل می شود که براساس آن داده هایی برای پارتیشن موضوعی وجود دارد که می خواهد با آن تعامل داشته باشد.

آنچه که اغلب اشتباه پیش می رود این است که کارگزار نادرست تنظیم شده و آدرس (تبلیغ شده. لیست) را برمی گرداند که مشتری نمی تواند به درستی به کارگزار متصل شود. در این حالت ، جدول زمانی به این شکل است:

1. مشتری اتصال به سرور (های) bootstrap را آغاز می کند ، که یکی (یا بیشتر) کارگزاران موجود در خوشه است
2. کارگزار یک نام میزبان نادرست را به مشتری برمی گرداند
3. مشتری سپس سعی می کند به این آدرس نادرست وصل شود و سپس شکست بخورد (از آنجا که کارگزار Kafka در دستگاه مشتری نیست ، این همان چیزی است که LocalHost به آن اشاره می کند)

در این مقاله برخی از سناریوهای مشترک قدم می زنند و نحوه رفع هر یک را توضیح می دهند.

فقط یک کارگزار؟

تمام این نمونه ها فقط از یک کارگزار استفاده می کنند ، که برای یک جعبه ماسه ای مناسب است اما برای هر چیزی که به یک محیط واقعی نزدیک شود ، کاملاً بی فایده است. در عمل ، شما حداقل سه کارگزار در خوشه خود خواهید داشت. مشتری شما در برابر یک (یا بیشتر) از این موارد بوت می شود و این کارگزار ابرداده هر یک از کارگزاران موجود در خوشه را به مشتری باز می گرداند.

سناریو 0: مشتری و کافکا در همان دستگاه محلی اجرا می شوند

برای این مثال ، من بستر های نرم افزاری را روی دستگاه محلی خود اجرا می کنم ، اما شما همچنین می توانید این کار را بر روی هر توزیع کافکا دیگری که به آن اهمیت می دهید اجرا کنید.

$ Confluent Status kafka… kafka [Zookeeper [Zookeeper [up] است

مشتری Python من در حال اتصال با تنظیم سرور Bootstrap از LocalHost: 9092 است.

این خیلی خوب کار می کند:

توجه: ابرداده کارگزار بازگشت 192. 168. 10. 83 است ، اما از آنجا که این IP دستگاه محلی من است ، بسیار خوب کار می کند.

سناریو 1: مشتری و کافکا روی ماشین های مختلف اجرا می شوند

حال بیایید اتصال به یک کارگزار کافکا را که روی یک دستگاه دیگر کار می کند ، بررسی کنیم. این می تواند یک دستگاه در شبکه محلی شما باشد ، یا شاید در زیرساخت های ابری مانند خدمات وب آمازون (AWS) ، مایکروسافت لاجورد یا Google Cloud Platform (GCP) در حال اجرا باشد.

در این مثال ، مشتری من روی لپ تاپ من در حال اجرا است و به کافکا در حال اجرا بر روی دستگاه دیگری در LAN من به نام ASGARD03 است:

اتصال اولیه موفق می شود. اما توجه داشته باشید که Brokermetadata که ما به عقب برگشته ایم نشان می دهد که یک کارگزار وجود دارد ، با نام میزبان LocalHost. این بدان معناست که مشتری ما از LocalHost استفاده می کند تا هنگام تولید و مصرف پیام به یک کارگزار متصل شود. این خبر بد است ، زیرا در دستگاه مشتری ما ، هیچ کارگزار کافکا در LocalHost وجود ندارد (یا اگر اتفاق می افتد ، برخی اتفاقات عجیب و غریب احتمالاً اتفاق می افتد).

و بدین ترتیب در حال گذر است:

بنابراین چگونه آن را برطرف کنیم؟ما می رویم و با سرپرست دوست داشتنی کافکا (که ممکن است ما باشد) صحبت می کنیم و سرور را برطرف می کنیم. برنامه های کارگزار (ها) را به گونه ای که تبلیغ شده است. ما در بالا دیدیم که در حال بازگشت Localhost است. بیایید برویم و این را برطرف کنیم. در سرور کارگزار من . Properties ، من این را می گیرم:

تبلیغ شده. لیست ها = schaintext: // localhost: 9092 شنوندگان = متن ساده: //0. 0. 0. 0: 9092

و تنظیمات تبلیغ شده را تغییر دهید.

Advertised. Listeners = schaintext: //asgard03. moffatt. me: 9092 شنوندگان = متن ساده: //0. 0. 0. 0: 9092

شنونده خود بدون تغییر باقی می ماند (به همه NIC های موجود ، در بندر 9092 متصل می شود). تنها تفاوت این است که این شنونده به مشتری می گوید که به جای LocalHost به آن در Asgard03. moffatt. me برسد.

بنابراین پس از اعمال این تغییرات در تبلیغات. لیست روی هر کارگزار و راه اندازی مجدد هر یک از آنها ، تولید کننده و مصرف کننده به درستی کار می کنند:

کارگزار ابرداده اکنون با یک نام میزبان که به درستی از مشتری حل می شود ، نشان می دهد.

سناریو 2: کافکا و مشتری در حال اجرا در Docker

اکنون می خواهیم وارد دنیای شگفت انگیز داکر شویم. Docker Networking به خودی خود جانوری است و من قصد ندارم آن را در اینجا بپوشانم زیرا شنوندگان کافکا به تنهایی برای هضم در یک مقاله کافی هستند. اگر فقط یک چیز را به خاطر می آورید ، بگذارید این باشد: وقتی چیزی را در Docker اجرا می کنید ، در یک ظرف در دنیای کوچک خود اجرا می شود. این چیزی است که به عنوان نام میزبان خود ، آدرس شبکه خود ، سیستم فایل خود به نظر می رسد. به عنوان مثال ، هنگامی که از کد در یک ظرف Docker می خواهید به LocalHost متصل شوید ، به خودش وصل می شود و نه دستگاه میزبان که در آن اجرا می کنید. این امر مردم را به خود جلب می کند ، زیرا آنها به لپ تاپ خود عادت کرده اند ، بنابراین به نظر می رسد که چرا کد در حال اجرا روی لپ تاپ نمی تواند به LocalHost متصل شود. اما ، به یاد داشته باشید ، کد روی لپ تاپ شما اجرا نمی شود. در یک ظرف روی لپ تاپ شما در حال اجرا است.

ما با ساده ترین جایگاه در اینجا شروع خواهیم کرد و هم کافکا و هم مشتری خود را در Docker در همان شبکه Docker اجرا خواهیم کرد. ابتدا یک Dockerfile ایجاد کنید تا مشتری Python ما را در یک ظرف Docker قرار دهید:

از Python: 3 # ما NetCat Cos را اضافه خواهیم کرد این یک ابزار عیب یابی شبکه بسیار مفید است که به روزرسانی مناسب را اجرا می کند ، نصب apt-get instal l-y netcat # نصب کتابخانه kafka python run pip install confluent_kafka # اضافه کردن اسکریپت ما اضافه کردن python_kafka_test_client. py / enterpoint ["پایتون" ، "/python_kafka_test_client. py"]

تصویر Docker را بسازید:

docker buil d-t python_kafka_test_client.

سپس یک کارگزار کافکا را تهیه کنید:

شبکه docker ایجاد rmoff_kafka docker ru n-network = rmoff_kafk a-r m-detac h-name zheokeepe r-e zheokeeper_port = 2181 confluentinc/c p-zookeeper: 5. 5. 0 docker ru n-network = rmoff_kafk a-r m-detac h-detach -

تأیید کنید که دو ظروف در حال اجرا هستید: یکی Apache Zookeeper ™ و یک کارگزار Kafka:

$ docker ps IMAGE STATUS PORTS NAMES confluentinc/cp-kafka:5.5.0 Up 32 seconds 0.0.0.0:9092>9092/TCP Broker ConfluentInc/CP-Zookeeper: 5. 5. 0 Up 33 Second 2181/TCP ، 2888/TCP ، 3888/TCP Zookeeper

توجه داشته باشید که ما در حال ایجاد شبکه Docker خودمان هستیم که بتوانیم این ظروف را اجرا کنیم تا بتوانیم بین آنها ارتباط برقرار کنیم. حتی اگر آنها روی لپ تاپ من در حال کار در Docker هستند ، تا آنجا که به هر ظرف مربوط می شود ، آنها در دستگاه های جداگانه قرار دارند و از طریق یک شبکه ارتباط برقرار می کنند.

بیایید مشتری را بچرخانیم و ببینیم چه اتفاقی می افتد:

$ docker ru n-network = rmoff_kafk a-r m-name python_kafka_test_client  -tty python_kafka_test_client: 9092

می توانید در ابرداده برگردانید که حتی اگر در ابتدا با موفقیت به کارگزار متصل شویم ، به ما می دهد که به عنوان میزبان کارگزار به ما برگردد. این بدان معنی است که تولید کننده و مصرف کننده شکست می خورند زیرا آنها سعی می کنند به آن متصل شوند - و LocalHost از ظرف مشتری خود است ، نه کارگزار.

برای رفع آن؟به کارگزار بگویید تا شنونده خود را به درستی تبلیغ کند. از آنجا که نام کارگزار کافکا در شبکه کارگزار است (از نام کانتینر آن به ارث رسیده است) ، ما باید این را به عنوان شنونده تبلیغ شده و تغییر آن تنظیم کنیم:

-e kafka_advertised_listeners = schaintext: // localhost: 9092 

-e kafka_advertised_listeners = plaintext: // کارگزار: 9092 

بنابراین اکنون کارگزار ما به این شکل است:

Docker Stop Broker docker ru n-network = rmoff_kafk a-r m-detac h-name broker  -p 9092: 9092  -e kafka_broker_id = 1  -e kafka_zookeeper_coect = keokeeper: 2181  -e  -e kafka_advertised_listeners: 9092  -e kafka_offsets_topic_replication_factor = 1  confluentinc/c p-kafka: 5. 5. 0

و مشتری فقط کاملاً کار می کند:

سناریو 3: Kafka در Docker آهنگسازی

در مورد پرچم های خط فرمان برای پیکربندی ظروف Docker پس از مدت کوتاهی نوع ناخالص می شود. خیلی بهتر استفاده از آهنگسازی Docker است. ظروف Docker را از بالا ابتدا خاموش کنید (Docker R M-F Broker ؛ Docker R M-f Zookeeper) و سپس با استفاده از این مثال به صورت محلی Docke r-Compose. yml ایجاد کنید.

اطمینان حاصل کنید که در همان پوشه مانند Docker-Compose. yml Run هستید:

docker-compose

شما می بینید که Zookeeper و کارگزار Kafka شروع می کنند و سپس مشتری تست پایتون:

خیلی خوب ، ها

می توانید پرونده های آهنگساز تمام عیار را برای Apache Kafka و بستر های نرم افزاری Confluent از جمله کارگزاران متعدد در این مخزن پیدا کنید.

سناریو 4: کافکا در ظرف داکر با مشتری در حال اجرا در محلی

اگر می خواهید مشتری خود را به صورت محلی اجرا کنید ، چه می کنید؟شاید این جایی باشد که IDE شما در آن ساکن است ، یا شما فقط نمی خواهید مشتری خود را docker کنید؟

بیایید مثالی را که در بالا به پایان رسانده ایم ، بگیریم ، که در آن کافکا در داکر از طریق Docker Compose در حال اجرا است. اگر سعی کنیم مشتری خود را به صورت محلی به آن وصل کنیم ، این کار با شکست انجام می شود:

$ python python_kafka_test_client. py localhost: 9092

آه ، اما بالاتر از ما از یک شبکه داکر خصوصی برای ظروف استفاده می کردیم و هیچ پورتی را برای دسترسی از دستگاه میزبان باز نکرده ایم. بیایید آن را تغییر دهیم و 9092 را در معرض میزبان قرار دهیم. من قصد دارم این کار را در Docker Compose YAML انجام دهم - اگر می خواهید آن را از Docker Run مستقیم اجرا کنید ، می توانید ، اما باید آهنگسازی Docker را مستقیماً به CLI ترجمه کنید (که یک فافل است و زیبا نیست و چراشما فقط باید از Docker Compose استفاده کنید پلتفرم های تجاری...