جمعه , ۳۰ فروردین ۱۳۹۸
خرید فالوور اینستاگرام خرید لایک اینستاگرام

مقدمه‌ای بر سیستم‌های توزیع شده – بخش دوم

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

  1. بخش اول
  2. بخش دوم
  3. بخش سوم

در بخش اول، به معرفی و بررسی ویژگی‌های سیستم‌های توزیع شده پرداخته شد و مقایسه‌ی کوتاهی با سیستم‌های متمرکز ارائه شد. در بخش دوم به بررسی بیشتر این سیستم‌ها خواهیم پرداخت.

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

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

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

برای طراحی سیستم‌های توزیع شده، باید چهار هدف مهم را در نظر گرفت. اگر این اهداف برآورده نشوند، طراحی و پیاده‌سازی سیستم به خوبی صورت نگرفته است و یا معماری توزیع‌شده مناسب نیست. این اهداف عبارت‌اند از:

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

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

تئوری CAP بیان می‌کند که به ازای هر جفت درخواست (درخواست نوشتن، و سپس خواندن)، سیستم می‌تواند تنها دو شرط از سه شرط مهم مطرح شده توسط این تئوری را ضمانت کند و شما نمی‌توانید هم‌زمان هر سه شرط را داشته باشید و باید یکی از آن‌ها را فدا کنید! این شرط‌ها عبارت‌اند از:

  • سازگاری (Consistency). این شرط تضمین می‌کند داده‌ای را که کاربر می‌خواند، حتما آخرین به‌روزرسانی آن داده باشد و همچنین همه‌ی سیستم‌های موجود در شبکه باید جدیدترین نسخه از آن داده را ببینند. حتی اگر عملیات خواندن و نوشتن آن داده در سیستم‌های مختلف انجام شود، باز هم آخرین و جدیدترین مقدار داده باید به کاربران نمایش داده شود.
  • دسترس‌پذیری (Availability). این شرط تضمین می‌کند که سیستم‌ها همواره به درخواست‌های کاربر جواب مناسب و در زمان مناسب را خواهد داد و هیچگاه جواب اشتباه و یا خطا به کاربر گزارش نمی‌شود. این شرط به هر دو درخواست خواندن و نوشتن اعمال می‌شود و دستور نوشتن همواره داده را به‌روزرسانی می‌کند و دستور خواندن همواره مقدار درست را به کاربر برمی‌گرداند. حتی اگر یکی از سیستم‌ها در شبکه از دسترس خارج شود، دیگر سیستم‌ها باید بتوانند همواره پاسخ درست و مناسب را به درخواست‌ها بدهند.
  • تحمل افراز (Partition Tolerance). این شرط تضمین می‌کند که در صورت وقوع خرابی در شبکه و ارتباط بین سیستم‌ها (مانند قطع ارتباط بین دو سیستم و یا تأخیر بیش از اندازه ارسال و دریافت بسته‌ها در شبکه) سیستم به کار خود بدون مشکل ادامه دهد. قطع یک ارتباط بین دو شبکه می‌تواند شبکه را به چند قسمت مجزا تقسیم کند (به عنوان مثال شبکه به دو بخش مجزا تقسیم شود که هر بخش بصورت جدا سیستم‌ها با هم در ارتباط هستند). این قطعی و خرابی می‌تواند تنها بین دو سیستم منزوی شود، و یا بخش بیشتری از شبکه گسترش یابد.

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

فرض کنید دو سیستم A و B در شبکه موجود باشند و یک داده با مقدار D1 بر روی هر دو سیستم قرار دارد. کاربر می‌خواهد این داده را به‌روزرسانی کند و در حالی که به A متصل است، مقدار داده را به D2 تغییر می‌دهد. B باید این مقدار جدید را از A دریافت کند تا هر دو سیستم جدیدترین نسخه از داده را در خود نگه دارند. به‌روزرسانی مقدار داده در B می‌تواند به دو شکل اتفاق بیافتد:

  • بعد از نوشتن مقدار جدید داده در A، در همان لحظه B مقدار داده خود را نیز به‌روز کند
  • B منتظر درخواست کاربر شود و زمانی‌که کاربر مقدار این داده را درخواست کرد، سپس مقدار جدید را از A دریافت کند و به کاربر نمایش دهد.

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

  • سیستم B همان مقدار قدیمی داده را به کاربر نمایش می‌دهد. در این روش دسترس‌پذیری تضمین شده است اما سازگاری نقض شده است.
  • سیستم B یک پیام خطای شخصی‌سازی شده و یا خطار عدم پاسخگویی در زمان مشخص (timeout) را به کاربر نشان می‌دهد. در این روش سازگاری تضمین شده است اما دسترس‌پذیری نقض شده است.

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

 

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

Avatar
کارشناسی ارشد نرم‌افزار از دانشگاه علم و صنعت ایران، برنامه‌نویس ارشد شرکت فناوران دانشگر. علاقه‌مند به سیستم‌های توزیع شده، معماری‌های مایکروسرویس و واکنشی، پردازش موازی و داده‌های جریانی. زبان‌های مورد علاقه: Scala, Go, Java

1
دیدگاه بگذارید

avatar
1 موضوع دیدگاه‌ها
0 موضوع پاسخ‌ها
0 دنبال‌کنندگان
 
بحث‌برنگیزترین دیدگاه
داغ‌ترین دیدگاه
1 نویسنده‌های دیدگاه
مرصاد آخرین نویسنده‌های دیدگاه
  مشترک شدن  
جدیدترین قدیمی‌ترین بیشترین امتیاز
اطلاع‌رسانی
مرصاد
Guest
مرصاد

خیلی خوبه. موفق باشید