خانه --> بسترهای پردازش توزیع شده --> پروتکل Gossip یا پروتکل شایعه روشی برای سازگاری سرویس دهنده ها

پروتکل Gossip یا پروتکل شایعه روشی برای سازگاری سرویس دهنده ها

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

 

پروتکل گوسیپ
نسخه های مختلف پروتکل Gossip یا شایعه

 

تاریجچه و مقدمه ایجاد پروتکل های شایعه:

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

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

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

یکی از مهمترین پروتکل‌هایی که در این زمینه استفاده میشود به اصطلاح پروتکل‌های شایعه نام دارد. بدین صورت که هر نودی وقتی شایعه‌ای را میشنود بصورتی انتخابی آن شایعه‌ به چندتا از نودهای همسایه اش انتقال میدهد. این رفتار، رفتار شیوع پیدا کردن بیماری‌های مسری هم هست. مقالات زیادی در این زمینه به چاپ رسیده ولی دو تا از پیاده‌سازی‌های متن بازی در این حوزه etcd و serf هستند که هر دو بر پایه gossip عمل میکنند. هر دوی این‌ها براساس «یک کلاغ چل کلاغ» عمل می‌کنند و بصورت کاملا توزیع عمل می کنند.

žgossip یک پروتکل ارتباطی peer-to-peer است که در آن گره ها به طور دوره ای اطلاعات مربوط به وضعیت فعلی خود و سایر گره هایی که آنها می دانند، مبادله می کنند.ž فرایند gossip هر ثانیه اجرا می شود و پیام های وضعیت فعلی خود را با سه گره دیگر در خوشه ای مبادله می کند. ž  گره ها اطلاعات خود را در مورد خود و در مورد دیگر گره ها که در مورد آنها شنیده اند، مبادله می کنند، بنابراین تمام گره ها به سرعت در مورد تمام گره های دیگر در خوشه یاد می گیرند.ž یک پیام gossip دارای یک شماره نسخه مرتبط با آن است، به طوری که در هنگام تبادل gossip ، اطلاعات قدیمی تر با وضعیت فعلی برای یک گره خاص جایگذاری می شود.

 در پروتکل برمبنای گوسیپ، هر گره در سیستم به طور متناوب اطلاعات را با زیرمجموعه ای از همتایانش مبادله می کند. انتخاب این زیرمجموعه نقش بسیار مهمی در توزیع وسیع گوسیپ دارد. در سطح ایده آل، هر گره باید اطلاعات را با همتایان انتخاب شده با پیروی  از نمونه تصادفی یکنواخت کلیه گره های در حال حاضر موجود در سیستم مبادله کند. این فرضیه منجر به تعیین  بسیاری از مشخصه های مطلوب پروتکل های بر مبنای گوسیپ مثل مقیاس پذیری، پایایی و کارایی و راندمان در مورد توزیع اطلاعات یا انباشتگی گردید. در عمل، اجرای این فرضیه نیاز به توسعه برنامه هایی دارد که هر گره از سایر گره های حاضر در سیستم اطلاع دارد. اما، فراهم نمودن جدول عضویت کامل برای هر گره، جدولی که نمونه تصادفی را از آن می توان انتخاب نمود، در سیستم دینامیکی در مقیاس بزرگ غیرممکن می باشد، زیرا حفظ و نگهداری چنین جداولی در حضور گره های ملحق شده و ترک کننده (  نامیده شده) موجب تحمیل هزینه های همگام سازی قابل ملاحظه ای می گردد. به ویژه، مطالعات اندازه گیری پیرامون شبکه های مختلف همتا با همتا نشان می دهد که یک گره اختصاصی (تکی) اغلب ظرف چند دقیقه تا یک ساعت وصل می شود. بدیهی است طرح های غیر متمرکز برای حفظ اطلاعات عضویت نقش مهمی در آرایش پروتکل های بر مبنای گوسیپ دارند. مقاله حاضر در مورد چکیده ای از سرویس نمونه گیری همتا صحبت کرده و چارچوب عمومی ، ساده و بر مبنای گوسیپی برای اجرای آن مطرح می کند. سرویس نمونه گیری همتا با استفاده از آن از برنامه جداشده و اجمالاً می توان گفت که از این سرویس در محیط های مختلف می توان استفاده نمود: توزیع اطلاعات، انباشتگی،تعادل بار و مدیریت شبکه. این سرویس به شکل تجرد درجه یک سیستم توزیع شده در مقیاس بزرگ ارتقاء یافته است. در اصل، نقش مهمی در سرویس نامگذاری در سیستم توزیع شده LAN سنتی ایفا می کند، چرا که شرایطی برای تعامل و برهم کنش گره ها فراهم می آورد. اصل عمومی پایه چارچوب پیشنهاد شده برای اجرای سرویس نمونه گیری همتا، بر اساس الگوی گوسیپ می باشد. به طور خلاصه، هرگره (۱) جدول عضویت محلی نسبتاً کوچکی در اختیار دارد که نگرشی جزئی پیرامون مجموعه کاملی از گره ها ارائه داده و (۲) به طور متناوب و با استفاده از روش گوسیپ جدول را تازه می کند. این چارچوب عمومی بوده و از آن می توان برای اجراهای عضویت بر مبنای گوسیپ جدید و شناخته شده استفاده نمود. در حقیقت، چارچوب معرفی شده با بسیاری از گونه های توزیع عضویت بر مبنای گوسیپ سرو کار دارد. این گونه ها عمدتاً در شیوه به روزدرآوری جدول عضویت در هر گره بعد از مبادله جداول در دور گوسیپ باهم تفاوت دارند.

 

پروتکل Gossip
عمل کرد هسته پروتکل Gossip

 

پروتکل Gossip
پکیج دیاگرام یک نمونه از پیاده سازی پروتکل Gossip

 

žتوجه داشته باشید در راه اندازی سرورهای پایگاه داده های توزیع شده مثل کاساندرا، در خوشه های متعدد در مرکز داده شامل حداقل یک گره از هر مرکز داده (گروه تکرار) در لیست seed وجود داشته باشد.ž تعیین بیش از یک گره seed در هر مرکز داده برای تحمل خطا توصیه می شود. در غیر این صورت، gossip در هنگام راه اندازی یک گره، باید با یک مرکز داده دیگر ارتباط برقرار کنند.

ž ساخت هر گره به عنوان گره دانه به دلیل افزایش نگهداری و کاهش عملکرد gossip توصیه نمی شود.ž بهینه سازی gossip مهم نیست، اما توصیه می شود از یک لیست seed کوچک (تقریبا سه گره در هر مرکز داده) استفاده کنید.

منابع:

https://ftaiani.ouvaton.org/GossipKit/main.html

http://blog.abyz.ir/tag/gossip-protocol/

http://tarjomefa.com/%D9%86%D9%85%D9%88%D9%86%D9%87+%DA%AF%DB%8C%D8%B1%DB%8C+%D9%87%D9%85%D8%AA%D8%A7+%D8%A8%D8%B1+%D9%85%D8%A8%D9%86%D8%A7+%DA%AF%D9%88%D8%B3%DB%8C%D9%BE

آدرس کانال تلگرام ما:

t.me/bigdata_channel
برای ورود به کانال بر روی اینجا کلیک کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *