انتشار-اشتراک در پروتکل MQTT (جلسه دوم)

تاریخ انتشار : 2020/07/19

اهداف

در جلسه پیش با تعریف پروتکل MQTT آشنا شدیم. فهمیدیم که این پروتکل به دلیل داشتن ویژگی هایی همچون سبک وزن بودن، نگه داشتن پیام ها، و نیاز به پهنای باند کم مهم ترین پروتکل ارتباطی در اینترنت اشیا به شمار می رود. در این جلسه مفهوم انتشار-اشتراک در پروتکل MQTT را بررسی خواهیم کرد.

 

الگوری انتشار-اشتراک (pub-sub)

الگوی انتشار-اشتراک که به اختصار پاب-ساب (pub-sub) نیز نامیده می شود، یک جایگزینی برای معماری سنتی مشتری-سرور (client-server) به شمار می رود. در مدل مشتری-سرور، کلاینت یا همان مشتری مستقیما با یک نقطه انتهایی ارتباط برقرار می کند. برای مثال یک کلاینت یک درخواست به سرور (که نقطه نهایی در آن url مقصد می باشد) ارسال کرده و پاسخ را دریافت می کند. در مدل pub/sub، پابلیشر (انتشار دهنده) و سابسکرایبر (مشترک) هیچ ارتباطی با هم ندارند. در واقع، این دو حتی از وجود همدیگر اطلاع هم ندارند. ارتباط بین این دو توسط یک المان سوم (بروکر) شکل می گیرد. وظیفه بروکر فیلتر کردن پیام ها و تحویل پیام ها به مشترک یا همان سابسکرایبر مورد نظر می باشد. 

pub-sub pattern

شکل۱) الگوی pub-sub در پروتکل MQTT

 

مهم ترین ویژوگی الگوی pub-sub دیکوپلینگ یا جداسازی پیام از گیرنده (مشترک) می باشد. ابعاد مهم ویژگی دیکوپلینگ به ترتیب زیر است:

 

  • دیکوپلینگ فضایی: ناشر و مشترک نیازی به شناخت همدیگر ندارند. برای مثال آی پی یا پورت تبادل نمی شود.
  • دیگوپلینگ زمانی: ناشر و مشترک نیاز به عملکرد همزمان ندارند (در حالی که در الگوی مشتری-سرور هر دوی مشتری و سرور در یک زمان عمل میکنند به گونه ای که مشتری درخواستی ارسال می کند و سرور در همان زمان درخواست را تحلیل کرده و پاسخ را برمی گرداند).
  • دیکوپلینگ سنکرون: لازم نیست عملیات روی هر دو مؤلفه هنگام انتشار یا دریافت قطع شود.

 

به طور خلاصه، مدل pub-sub ارتباط مستقیم بین ناشر پیام و گیرنده ( مشترک) را حذف می کند. خاصیت فیلترینگ باعث میشود بروکر مشترکی که قرار است پیام را دریافت کند کنترل کند.

 

مقیاس پذیری

مقیاس پذیری الگوی pub-sub از رویکرد سنتی مشتری-سرور بهتر می باشد. این امر به این دلیل است که عملیات روی بروکر می تواند کاملاً موازی بوده و پیام ها را می توان به روش رویداد محور پردازش کرد. ذخیره سازی (کش کردن) و مسیریابی هوشمند پیام ها اغلب عوامل تعیین کننده برای بهبود مقیاس پذیری هستند. با این حال، مقیاس بندی میلیون ها اتصال باز هم یک چالش محسوب می شود. چنین سطح بالایی از اتصالات را می توان از طریق بروکرهای خوشه ای (کلاسترینگ) و با استفاده از متعادل کننده های بار (load balancers) مدیریت کرد. 

MQTT broker cluster

شکل۲) خوشه بندی بروکر MQTT

 

فیلترینگ پیام

واضح است که بروکر نقش اساسی در روند pub-sub دارد. ولی چگونه بروکر قادر است تمام پیام ها را فیلتر کند تا هر مشترک یا سابسکرایبر تنها پیام های مربوط به خود را دریافت کند؟ بروکر چندین گزینه برای این کار دارد:

 

گزینه ۱: فیلترینگ بر اساس موضوع یا تاپیک

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

 

گزینه ۲: فیلترینگ بر اساس محتوا

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

 

گزینه ۳: فیلترینگ بر اساس نوع داده

هنگامی که از زبانهای شی گرا استفاده می شود، فیلتر کردن بر اساس نوع پیام (رویداد) یک روال معمول است. به عنوان مثال مشترک می تواند به تمامی پیام هایی که از نوع عدد صحیح یا بولین یا هر نوع دیگری گوش کند.

 

با وجو مزیت های بسیار الگوی pub-sub، مواردی وجود دارند که قبل از استفاده باید از آنها آگاه باشید و در پیکربندی سیستم خود آنها را لحاظ کنید. برای مثال، شما باید از ساختار پیام ها از قبل آگاه باشید. در فیلترینگ بر اساس محتوا، ناشر و مشترک باید از تاپیکی که پیام روی آن رد و بدل می شود از قبل آگاه باشند. نکته دیگری که باید در نظر داشته باشید تحویل پیام است. ناشر قادر به فهمیدن اینکه چه کسی پیام را می گیرد نیست. در برخی موارد، ناشر حتی نمیداند آیا مشترکی روی تاپیک مورد نظر به پیام گوش می دهد یا خیر.

 

MQTT و الگوی pub-sub

موادری که در بالا بحث شدند، یک الگوی کلی از مدل pub-sub هستند. اکنون می توانیم به طور ویژه بر پروتکل MQTT به عناون پروتکلی که از مدل pub-sub استفاده کرده و از ابزارهایی برای حل چالش های این مدل استفاده کرده، متمرکز شویم. 

 

  • دیکوپلینگ فضایی: MQTT از دیکوپلینگ فضایی استفاده میکند. در اینجا نیز مشتری و مشترک نیاز به شناخت هم ندارند. هر کدام، از طریق آی پی یا نام هاست به بروکر متصل می شوند. 
  • دیکوپلینگ زمانی: اگرچه MQTT تقریبا به صورت ریل تایم (realtime) کار میکند، ولی در صورتی که یک کلاینتی آنلاین نباشد، پیام را ذخیره کرده و در هنگام آنلاین شدن کلاینت، پیام را به آن تحویل می دهد. (برای این منظور، لازم است کلاینت در هنگام آنلاین شدن به تاپیک قبلی سابسکرایب بوده و از کیفیت خدمات (QoS) بزرگتر از صفر استفاده کند).
  • دیکوپلینگ سنکرون: به طور کلی کتابخانه کلاینت ها به صورت غیرسنکرون یا غیرهمزمان کار میکنند. ولی برخی کتابخانه ها دارای API همزمان هستند. با این حال، جریان در حالت کلی غیرهم زمان است.

 

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

 

کیفیت خدمات (QoS) در پروتکل MQTT

برای حل چالش های مدل pub-sub، پروتکل MQTT از ویژگی کیفیت خدمات (QoS) استفاده می کند که دارای سه مرحله است:

 

  • کیفیت خدمات صفر: پیام صرفا ارسال شده و تحویل یا عدم تحویل آن را نمی توان تشخیص داد.
  • کیفیت خدمات یک: پیام ارسال شده و بروکر مطمئن است که مشترک حداقل یک بار پیام را دریافت کرده است.
  • کیفیت خدمات دو: پیام ارسال شده و بروکر مطمئن می شود که مشترک فقط و فقط یک بار پیام را دریافت می کند.

 

در رابطه با کیفیت خدمات در پروتکل MQTT در جلسات بعد بیشتر بحث خواهیم کرد.

QoS in MQTT

شکل۳) کیفیت خدمات در پروتکل MQTT

 

نتیجه گیری

در این جلسه با مفهوم الگوی انتشار-اشتراک در پروتکل MQTT آشنا شده و به مزیت های آن نسبت به الگوی مشتری-سرور پی بردیم. در جلسه بعد، با مفاهیم کلاینت و بروکر در پروتکل MQTT آشنا خواهیم شد. با ما همراه باشید.

برخی از مشتریان

لوگو شریف
لوگو آمد
لوگو شهرداری تهران
لوگو دانشگاه تهران
لوگو ساتکاپ
لوگو دانشگاه ارومیه
logofa