درک کارگزاران پیام آموزش مکانیک پیام رسانی با ActiveMQ و Kafka. فصل 1

خوش آمدید!

شروع کردم به ترجمه یک کتاب کوچک:
«درک کارگزاران پیام«
نویسنده: Jakub Korab، ناشر: O'Reilly Media, Inc.، تاریخ انتشار: ژوئن 2017، شابک: 9781492049296.

از مقدمه کتاب:
"... این کتاب به شما می‌آموزد که چگونه در مورد سیستم‌های پیام‌رسان بروکر فکر کنید، دو فناوری محبوب بروکر را با یکدیگر مقایسه و مقایسه کنید: Apache ActiveMQ و Apache Kafka. موارد استفاده و مشوق‌های توسعه را که توسعه‌دهندگان آن‌ها را به اتخاذ رویکردهای بسیار متفاوت در یک حوزه سوق می‌دهد، بیان می‌کند - پیام‌رسانی بین سیستم‌ها با یک کارگزار میانی. ما به این فناوری‌ها از ابتدا نگاه خواهیم کرد و تأثیر انتخاب‌های مختلف طراحی را در این مسیر برجسته خواهیم کرد. شما درک عمیقی از هر دو محصول به دست خواهید آورد، درک درستی از نحوه استفاده و عدم استفاده از آنها و درک آنچه که در آینده در نظر گرفتن سایر فناوری های پیام رسانی باید به دنبال آن باشید. "

قسمت های ترجمه شده تاکنون:
فصل 1 مقدمه
فصل 3. کافکا

من فصل های تکمیل شده را همانطور که ترجمه شده اند پست خواهم کرد.

فصل 1

معرفی

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

افراد معمولاً تماس بسیار محدودی با زیرساخت پیام رسانی دارند. آنها اغلب به سیستمی متصل می شوند که مدت ها پیش ایجاد شده است، یا یک توزیع را از اینترنت دانلود می کنند، آن را در PROM نصب می کنند و شروع به نوشتن کد برای آن می کنند. پس از اجرای زیرساخت در PROM، نتایج را می توان مخلوط کرد: پیام ها به دلیل خرابی از بین می روند، ارسال آن طور که انتظار داشتید کار نمی کند، یا کارگزاران تولید کنندگان شما را "آویز می کنند" یا پیامی را برای مصرف کنندگان شما ارسال نمی کنند.

آشنا به نظر می رسد؟

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

بدون درک عمیق از نحوه کار کارگزاران، مردم اظهارات به ظاهر منطقی در مورد سیستم های پیام رسانی خود می کنند، مانند:

• سیستم هرگز پیام ها را از دست نمی دهد
• پیام ها به صورت متوالی پردازش خواهند شد
• اضافه کردن مصرف کنندگان سیستم را سریعتر می کند
• پیام ها فقط یکبار تحویل داده می شود

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

این کتاب به شما می‌آموزد که چگونه در مورد سیستم‌های پیام‌رسان مبتنی بر کارگزار فکر کنید، دو فناوری محبوب بروکر را مقایسه و مقایسه کنید: Apache ActiveMQ و Apache Kafka. موارد استفاده و مشوق‌های توسعه را که توسعه‌دهندگان آن‌ها را به اتخاذ رویکردهای بسیار متفاوت در یک حوزه سوق می‌دهد، بیان می‌کند - پیام‌رسانی بین سیستم‌ها با یک کارگزار میانی. ما به این فناوری‌ها از ابتدا نگاه خواهیم کرد و تأثیر انتخاب‌های مختلف طراحی را در این مسیر برجسته خواهیم کرد. شما درک عمیقی از هر دو محصول به دست خواهید آورد، درک درستی از نحوه استفاده از آنها و نحوه استفاده از آنها و درک این نکته که هنگام در نظر گرفتن سایر فناوری های پیام رسانی در آینده به دنبال چه چیزی باشید.

قبل از شروع، بیایید به اصول اولیه بپردازیم.

سیستم پیام رسانی چیست و چرا به آن نیاز است؟

برای اینکه دو برنامه با یکدیگر ارتباط برقرار کنند، ابتدا باید یک رابط تعریف کنند. تعریف این رابط شامل انتخاب یک انتقال یا پروتکل مانند HTTP، MQTT یا SMTP و مذاکره در مورد قالب‌های پیامی است که بین سیستم‌ها مبادله می‌شود. این ممکن است یک فرآیند سختگیرانه باشد، مانند تعریف یک طرح XML با الزامات هزینه بار پیام، یا ممکن است بسیار کمتر رسمی باشد، مانند توافق بین دو توسعه دهنده مبنی بر اینکه بخشی از درخواست HTTP حاوی شناسه مشتری باشد.

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

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

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

نقطه به نقطه

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

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

اصطلاح "بادوام" برای صف ها به کار می رود. قابلیت اطمینان یک ویژگی خدماتی است که تضمین می‌کند سیستم پیام‌رسان پیام‌ها را در غیاب مشترکین فعال تا زمانی که یک مصرف‌کننده در صف تحویل پیام مشترک نشود، ادامه می‌دهد.

قابلیت اطمینان اغلب با اشتباه گرفته می شود ماندگاری و اگرچه این دو اصطلاح به جای یکدیگر استفاده می شوند، اما عملکردهای متفاوتی دارند. تداوم تعیین می کند که آیا سیستم پیام رسانی بین دریافت آن و ارسال آن به مصرف کننده، پیامی را در نوعی فضای ذخیره سازی می نویسد. پیام‌هایی که به صف ارسال می‌شوند ممکن است پایدار باشند یا نباشند.
پیام نقطه به نقطه زمانی استفاده می شود که مورد استفاده نیاز به یک اقدام یکباره روی پیام دارد. به عنوان مثال می توان به واریز وجه به حساب یا تکمیل سفارش تحویل اشاره کرد. بعداً بحث خواهیم کرد که چرا سیستم پیام رسانی به تنهایی قادر به ارائه یک بار تحویل نیست و چرا صف ها می توانند در بهترین حالت تضمین تحویل را ارائه دهند. حد اقل یک بار.

ناشر-مشترک

گابریلا شماره کنفرانس را می گیرد. در حالی که او به کنفرانس متصل است، همه چیزهایی را که گوینده می گوید، همراه با بقیه شرکت کنندگان در تماس می شنود. هنگامی که او کوک می کند، چیزی را که گفته می شود از دست می دهد. وقتی دوباره وصل می شود، او همچنان به شنیدن آنچه گفته می شود ادامه می دهد.

این نمونه ای از مدل پیام رسانی است انتشار-اشتراک. تماس کنفرانسی به عنوان یک مکانیسم پخش عمل می کند. فردی که صحبت می کند اهمیتی نمی دهد که چند نفر در حال حاضر در تماس هستند - سیستم تضمین می کند که هر کسی که در حال حاضر متصل است آنچه گفته می شود را می شنود.
در سیستم های پیام رسانی کلاسیک، مدل پیام رسانی انتشار-اشتراک از طریق پیاده سازی می شود تاپس. تاپیک همان روش پخش را به عنوان مکانیسم کنفرانس ارائه می دهد. وقتی پیامی به موضوعی ارسال می شود، توزیع می شود برای همه کاربران مشترک.

موضوعات معمولا غیر قابل اعتماد (غیرقابل تحمل). دقیقاً مانند شنونده ای که وقتی شنونده قطع می شود نمی تواند آنچه را که در یک تماس کنفرانسی گفته می شود بشنود، مشترکین موضوع هر پیامی را که در حالت آفلاین ارسال می شود از دست می دهند. به همین دلیل می توان گفت که تاپیک ها ضمانت تحویل را ارائه می دهند نه بیشتر از یک بار برای هر مصرف کننده

پیام‌های انتشار-اشتراک معمولاً زمانی استفاده می‌شود که پیام‌ها ماهیت اطلاعاتی دارند و از دست دادن یک پیام اهمیت خاصی ندارد. به عنوان مثال، یک موضوع می تواند خوانش دما را از گروهی از حسگرها یک بار در ثانیه ارسال کند. سیستمی که به دمای فعلی علاقه مند است و در یک موضوع مشترک می شود، اگر پیامی را از دست داد، نگران نخواهد شد - دیگری در آینده نزدیک می رسد.

مدل های هیبریدی

وب سایت فروشگاه، پیام های سفارش را در «صف پیام» قرار می دهد. مصرف کننده اصلی این پیام ها سیستم اجرایی است. علاوه بر این، سیستم حسابرسی باید کپی هایی از این پیام های سفارش را برای پیگیری بعدی داشته باشد. هر دو سیستم نمی توانند به پیام ها اجازه عبور دهند، حتی اگر خود سیستم ها برای مدتی در دسترس نباشند. وب سایت نباید از سیستم های دیگر آگاه باشد.

موارد استفاده اغلب به ترکیبی از مدل‌های پیام‌رسانی انتشار-اشتراک و نقطه به نقطه نیاز دارند، مانند زمانی که سیستم‌های متعدد به یک کپی از یک پیام نیاز دارند و برای جلوگیری از از دست رفتن پیام، هم قابلیت اطمینان و هم پایداری لازم است.

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

مدل‌های ترکیبی جدید نیستند و می‌توانند در اکثر سیستم‌های پیام‌رسانی، از جمله ActiveMQ (از طریق مقاصد مجازی یا ترکیبی که موضوعات و صف‌ها را ترکیب می‌کنند) و کافکا (به طور ضمنی، به عنوان یک ویژگی اساسی طراحی مقصد) استفاده شوند.

اکنون که برخی اصطلاحات اولیه و درک درستی از آنچه که می‌توانیم از یک سیستم پیام‌رسان استفاده کنیم، داریم، بیایید به جزئیات بپردازیم.

ترجمه انجام شد: tele.gg/middle_java

قسمت ترجمه شده زیر: فصل 3. کافکا

ادامه ...

منبع: www.habr.com