خانه / microservices / اسید و بازها و چالش سازگاری در سیستم های توزیع شده

اسید و بازها و چالش سازگاری در سیستم های توزیع شده

اسید و بازها و چالش سازگاری در سیستم های توزیع شده

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

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

ویکیپدیا سازگاری را بدین صورت تعریف می کند:

Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors cannot result in the violation of any defined rules.

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

 

سیستم های مانولیت یا یکپارچه

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

این چهار شرط که توسط Reuter و Härder ارائه شدند عبارتند از:

  1. Atomicity: این قید اشاره به این مورد دارد که تمام عملیات در سیستم بصورت “همه یا هیچ” در نظر گرفته می شود. به عبارت دیگر در یک تراکنش در حال اجرا در صورتی که هر بخش از آن تراکنش به هر دلیل با شکست مواجه شود کل آن تراکنش به عنوان شکست خورده در نظر گرفته شده و از آن چشم پوشی شود. جهت حفظ سازگاری خاصیت اتومیک بودن بسیار مهم می باشد.
  2. Consistency: این قید مهم اشاره به این دارد که هر عملیاتی که بر روی داده ها تاثیر گذار می باشد باید سیستم را از حالت سازگار فعلی به یک حالت سازگاری دیگر ببرد. در صورتی که عملیات مورد نظر باعث انتقال سیستم به حالتی شود که از برخی قوانین جامعیتی سیستم تخطی شود این عملیات مجاز شمرده نمی شود.
  3. Isolation: این مورد اشاره به این دارد که در صورت اجرای همزمان چندین عملیات با هم؛ این عملیات بر روی هم تاثیر نداشته باشند و بدون آگاهی و دخالت در کار هم به کار خود ادامه دهند.
  4. Durability: و در نهایت این قید اشاره به این موضوع دارد که هنگامی که عملیاتی در سیستم کامیت شد و به ثبت رسید نتیجه ی عملیات باید برای همیشه بدون تغییر باقی بماند حتی در شرایط غیر عادی مثل قطع برق و …. مگر اینکه توسط یک عملیات مجاز دیگر تغییر کند.

وجود شرایط بالا برای حفظ و برقراری سازگاری و درستی داده ها لازم و ضروری می باشد. هر سیستمی جهت تضمین این سازگاری باید ACID را تضمین کند. سیستم های RDMS از جمله این سیستم ها می باشند. نکات مهمی در ACID وجود دارد. از جمله اینکه شرط Consistency همواره و همیشه برقرار می باشد و سیستم هیچگاه نمی تواند وارد یک شرایط غیر سازگار(موقت) شود. در این شرایط در صورتی که بخشی از عملیات باعث سازگاری غیر موقت که ممکن این عدم سازگاری موقت توسط عملیاتی دیگر رفع شود؛ بشود  آن عملیات اجازه اجرا شدن را ندارد. به این شرایط اصطلاحا Strongly Consistency نیز گفته می شود. این رادیکال بودن در مورد شرایط دیگر از جمله Isolation نیز صادق می باشد. از آنجایی که تمام داده ها یک جا تجمیع می باشند بدست آوردن این شرط نیز می تواند بسیار راحت باشد.

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

 

سیستم های توزیع شده

در این سیستم ها بدلیل ماهیت توزیع شدگی سیستم و داده ها با مسئله ی Contest مواجه هستیم. بخصوص در شرایط توزیع شدگی سیستم در شبکه و مابین چندین سرور فیزیکی متفاوت. رویکردهای مختلف و متفاوتی جهت بررسی و پرداختن به مسائل Contest وجود دارد. از جمله روش 2PK یا تائید عملیات دو مرحله ای که نیاز به فرآیند رای گیری یا voting مابین تمام نودها جهت توافق بر سر عملیات انجام شده بین بخش های مختلف سیستم می باشد تا بدین صورت بتوان سازگاری را در کل سیستم حفظ کرد. بدلیل سرباری بسیار زیاد و همچنین شرایطی از جمله در دسترس نبودن شبکه؛ در عمل استفاده از الگوریتم هایی از جمله 2PK یا 3PK مناسب نمی باشد.

Eric Brewer اثبات کرد که در شرایط توزیع شدگی سیستم ها نمی توان همزمان به بیش از دو شرط از سه شرط زیر دست یافت. این تئوری که بعدها بنام تئوری بروئر(و بنام ایشان) نام گرفت شامل سه شرط زیر می باشد؛ که هر سیستم توزیع شده از این میان این سه شرط و بسته به اهمیت هر کدام به دوتا از این شرط های می تواند دسترسی داشته باشد. این تئوری البته بیشتر به تئوری CAP معروف و مشهور می باشد که سر واژه ی سه شرط زیر می باشد.

 

  1. Consistency: هر عملیات خواندن داده ها آخرین ویرایش داده ها را می خواند و یا یک خطا بر می گرداند.
  2. Availability: هر درخواست یک پاسخ (غیر خطا) را دریافت می کند؛ اما بر خلاف حالت قبل تضمین نمی کند که این داده برگشت داده شده آخرین تغییرات داده مذکور باشد.
  3. Partition Tolerance: سیستم حتی در صورتی که مشکلات جزیی در بخش هایی از شبکه بوجود بیاید و یا برخی درخواست های ارسالی قبل از دریافت و پردازش از بین بروند بکار خود ادامه می دهد.

 

 


BASE
اصطلاحی است که بر اساس CAP بنا نهاده شده است و در مقابل ACID قرار می گیرد. BASE سعی می کند با ارائه شرایطی به بحث سازگاری داده های در سیستم های توزیع شده بپردازد. اما ببینیم BASE چه شرایطی را در نظر می گیرد. BASE نیز سر واژه سه عبارت زیر می باشد.در سیستم های توزیع شده بر خلاف سیستم های مانولیت بدلیل ماهیت شبکه و اجتناب ناپذیر امکان وجود شکست در شبکه ما به ناچار شرط Partition Tolerance را خواهیم پذیرفت و در نتیجه معمولا انتخاب بین Consistency و Availability وجود خواهد داشت. در صورتی که Consistency  را به عنوان شرط دیگر انتخاب کنیم سیستم بهنگامی که نتواند عملیاتی را به هر دلیل از جمله وجود شکست های در شبکه به اتمام برساند time out یا پیغام failed بر می گرداند-ولی اگر پاسخ برگشت داده شود تضمین می شود که این پاسخ آخرین داده ی ذخیره شده می باشد. از طرف دیگر در صورت انتخاب Availability سیستم در هر شرایطی پاسخ صحیح بر می گرداند و این پیغام برگشت داده عملیاتی که اخیرا با موفیت ثبت شده است هر چند تضمین نمی کند که آخرین داده ثبت شده  باشد. سیستم های مدیریت داده انتخاب های مختلفی بسته به ماهیت خود بین این دو شرط دارند. غالبا سیستم های RDBMS  شرط Consistency و سیستم های NoSQL شرط Availability را مقدمتر می شمارند.

  1. Basically Availability: اشاره به قید و شرط Availability در تئوری CAP دارد.
  2. Soft State: بدین معنی که حالت سیستم ممکن است حتی بدون ورودی داده ها نیز تغییر کند. دلیل این مورد که شاید در نگاه اول عجیب به نظر برسد به شرط زیر بر می گردد.
  3. Eventual Consistency: بدین معنی است که ممکن است سیستم در لحظاتی از زمان بصورت موقت سازگار نباشد اما در نهایت پس از گذشت زمانی سیستم به حالت سازگار دست پیدا می کند. در این مورد مثالی را اشاره می کنم. فرض کنید یک بخشی از عملیات یک سیستم بدین صورت بود که باید برای هر ثبت سفارش برای مشتری سوابق آن نگه داری شود. با توزیع شدن سیستم طراحی شما بدین صورت شکل گرفته که قسمت ثبت سفارش در یک سرویس جدا گانه و بخش مشتریان و مدیریت آن در سرویس جداگانه انجام می شود. در اینحالت شما ابتدا سفارش را در سرویس مربوط به آن انجام داده و به ثبت می رسانید. تا اینجا درخواست ثبت شده؛ ولی بدلیل اینکه هنوز سوابق آن برای مشتری مورد نظر که در سرویس دیگر عملیات و داده های مربوط به آن مدیریت می شود به ثبت نرسیده است؛ سیستم موقتا به حالت ناسازگار وارد می شود. تا اینکه در نهایت پس از لحظاتی سوابق این سفارش نیز توسط سرویس مربوطه به ثبت برسد و مجددا سیستم به حالت سازگاری بازگردد.

 

نکته: در پایان باید اشاره کرد که برای دسترسی به Eventual Consistency اصطلاح دیگری بنام ACID 2.0 نیز وجود دارد. ACID 2.0 شامل یکسری اصول جهت رسیدن به Eventual Consistency در سیستم های توزیع شده می باشد. در اینجا قصد توضیح دادن و پرداختن به این مورد را نداشته و فقط هدف بیان کردن این مورد می باشد. این اصول شامل موارد زیر می باشد.

  1. Associative: بدین معنی که در سیستم های توزیع شده گروه مسیج ها مهم نیست و اجازه عملیات دسته ای بر اساس گروهی از مسیج ها نیز وجود دارد.
  2. Commutative: که اشاره می کند به اینکه ترتیب مسیج ها در یک گروه از دسته ها مهم نمی باشد.
  3. Idempotent: این قید بیان می کند که duplication یا تکرار مسیج ها مهم نمی باشد.
  4. Distributed: سیستم ممکن است توزیع شده باشد.

نتیجه گیری:

همانطور که مشاهده نمودیم در سیستم های مانولیت بدلیل یکپارچه بودن و تجمیع داده در یک محل سعی می شود با اعمال یکسری شرایط و در غیاب شرایطی از جمله مشکلات شبکه ای به بالاترین درجه اطمینان و سازگاری داده ها دست پیدا کنیم. این شرایط همانطور که بالا اشاره شرط عبارت بود از اعمال ACID. در سیستم های توزیع شده بدلیل ماهیت توزیع شدگی سیستم و همچنین وجود شرایطی از جمله ماهیت شکست پذیر شبکه حفظ سازگاری قوی از طریق الگوریتم هایی از جمله 2PK و موارد مشابه بدلیل سرباری بسیار زیاد در عمل مقرون به صرفه نمی باشد مهمترین تئوری در این زمینه تئوری CAP می باشد که اشاره به سه شرایطی دارد که در هر زمان نمی توان به بیش از دو شرط از این سه شرط دسترسی پیدا کنیم. BASE اصطلاح مهمی است که بر پایه تئوری CAP و در مقابل ACID جهت حفظ سازگاری داده های در سیستم های توزیع شده می باشد. Eventual Consistency مهمترین تفاوت BASE در مقابل ACID است که دارای Strongly Consistency می باشد.

Eventual Consistency نقش مهمی در اکثر سیستم های نرم افزاری امروزی بخصوص سیستم های سرویس بیس از جمله مایکروسرویس ها؛ ایفا می کنند که در مقاله ای جداگانه به بررسی دقیقتر آن و روش های پرداختن به این موضوع مهم می پردازم.

درباره ی masoud@admin

همچنین ببینید

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد. یکی از …

Say No to No Monolith

Say No to “No Monolith” Packages Principals با بیشتر شدن تمایل و گرایش به مایکروسرویس …

پاسخ دهید

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

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن