چرا ممکن است به تکرار نیمه سنکرون نیاز داشته باشید؟

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

معرفی

با توجه به این واقعیت که هارد دیسک تنها می تواند حدود 400-700 عملیات در ثانیه انجام دهد (که با rps معمولی در یک سیستم با بار بالا قابل مقایسه نیست)، پایگاه داده کلاسیک دیسک گلوگاه معماری است. بنابراین لازم است به الگوهای پوسته ریزی این انبار توجه ویژه ای شود.

در حال حاضر، 2 الگوی مقیاس بندی پایگاه داده وجود دارد: تکرار و تقسیم. Sharding به شما این امکان را می دهد که عملیات نوشتن را مقیاس بندی کنید، و در نتیجه، rps در هر نوشتن به ازای هر سرور را در خوشه خود کاهش دهید. Replication به شما امکان می دهد همان کار را انجام دهید، اما با عملیات خواندن. این الگوی است که این مقاله به آن اختصاص یافته است.

همانند سازی

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

با وجود سادگی ظاهری آن، چندین گزینه برای طبقه بندی پیاده سازی های مختلف این طرح وجود دارد:

• بر اساس نقش های موجود در خوشه (ارباب-ارباب یا ارباب-برده)
• توسط اشیاء ارسال شده (مبتنی بر ردیف، مبتنی بر بیانیه یا ترکیبی)
• با توجه به مکانیسم همگام سازی گره

امروز به نکته 3 می پردازیم.

تعهد معامله چگونه اتفاق می افتد؟

این مبحث مستقیماً به Replication مربوط نمی شود، می توان مقاله جداگانه ای در مورد آن نوشت، اما از آنجایی که مطالعه بیشتر بدون درک مکانیسم commit تراکنش بی فایده است، اجازه دهید اساسی ترین موارد را به شما یادآوری کنم. تعهد تراکنش در 3 مرحله انجام می شود:

1. ثبت تراکنش در گزارش پایگاه داده.
2. استفاده از تراکنش در موتور پایگاه داده
3. بازگرداندن تأییدیه به مشتری مبنی بر اینکه تراکنش با موفقیت اعمال شده است.

در پایگاه های داده های مختلف، این الگوریتم ممکن است دارای تفاوت های ظریف باشد: به عنوان مثال، در موتور InnoDB پایگاه داده MySQL 2 گزارش وجود دارد: یکی برای تکرار (Log باینری) و دیگری برای حفظ ACID (لغو/بازگردانی گزارش)، در حالی که در PostgreSQL است. یک گزارش وجود دارد که هر دو عملکرد را انجام می دهد (نوشتن پیش ثبت = WAL). اما آنچه در بالا ارائه شد دقیقاً مفهوم کلی است که اجازه می دهد چنین تفاوت های ظریفی در نظر گرفته نشود.

همانندسازی همزمان (همگام).

بیایید منطق اضافه کنیم تا تغییرات دریافتی را در الگوریتم commit تراکنش تکرار کنیم:

1. ثبت تراکنش در گزارش پایگاه داده.
2. استفاده از تراکنش در موتور پایگاه داده
3. ارسال داده به همه کپی ها.
4. دریافت تاییدیه از تمامی ماکت ها مبنی بر اینکه تراکنش روی آنها انجام شده است.
5. بازگرداندن تأییدیه به مشتری مبنی بر اینکه تراکنش با موفقیت اعمال شده است.

با استفاده از این روش، ما با تعدادی از معایب روبرو هستیم:

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

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

آیا می‌توانیم منتظر تأیید فقط از درصد معینی از گره‌ها باشیم، مثلاً از 51 درصد (نصاب)؟ بله، می‌توانیم، اما در نسخه کلاسیک، تأیید از همه گره‌ها لازم است، زیرا به این ترتیب می‌توانیم از سازگاری کامل داده‌ها در خوشه اطمینان حاصل کنیم که مزیت بدون شک این نوع تکرار است.

همانندسازی ناهمزمان (ناهمگام).

بیایید الگوریتم قبلی را اصلاح کنیم. ما داده‌ها را به ماکت‌ها «مدتی بعد» ارسال می‌کنیم، و «زمانی بعد» تغییرات روی کپی‌ها اعمال می‌شود:

1. ثبت تراکنش در گزارش پایگاه داده.
2. استفاده از تراکنش در موتور پایگاه داده
3. بازگرداندن تأییدیه به مشتری مبنی بر اینکه تراکنش با موفقیت اعمال شده است.
4. ارسال داده ها به ماکت ها و اعمال تغییرات در آنها.

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

اما شرط ریختن داده‌ها روی ماکت‌ها «مدتی بعد» می‌تواند منجر به از دست رفتن تراکنش و از دست دادن تراکنش تأیید شده توسط کاربر شود، زیرا اگر داده‌ها زمان تکرار نداشتند، تأییدیه برای مشتری در مورد موفقیت عملیات ارسال شد و گره ای که تغییرات به آن رسید HDD را خراب کرد، تراکنش را از دست دادیم که می تواند منجر به عواقب بسیار ناخوشایندی شود.

همانندسازی نیمه همگام

در نهایت به همانندسازی نیمه سنکرون می رسیم. این نوع تکثیر خیلی شناخته شده یا بسیار رایج نیست، اما به دلیل اینکه می‌تواند مزایای تکرار همزمان و ناهمزمان را با هم ترکیب کند، بسیار مورد توجه است.

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

1. ثبت تراکنش در گزارش پایگاه داده.
2. استفاده از تراکنش در موتور پایگاه داده
3. ارسال داده به ماکت ها
4. دریافت تأییدیه از ماکت مبنی بر دریافت تغییرات (آنها «مدتی بعد» اعمال خواهند شد).
5. بازگرداندن تأییدیه به مشتری مبنی بر اینکه تراکنش با موفقیت اعمال شده است.

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

اما با این رویکرد خطر خواندن فانتوم وجود دارد. بیایید سناریوی زیر را تصور کنیم: در مرحله 4، ما تاییدی از هیچ نسخه ای دریافت نکردیم. ما باید این تراکنش را برگردانیم و تأییدیه ای را به مشتری برنگردانیم. از آنجایی که داده ها در مرحله 2 اعمال شدند، یک فاصله زمانی بین پایان مرحله 2 و بازگشت تراکنش وجود دارد که طی آن تراکنش های موازی می توانند تغییراتی را که نباید در پایگاه داده وجود داشته باشد، مشاهده کنند.

همانندسازی نیمه همگام بدون ضرر

اگر کمی فکر کنید، فقط می توانید مراحل الگوریتم را برعکس کنید و مشکل فانتوم خواندن در این سناریو را برطرف کنید:

1. ثبت تراکنش در گزارش پایگاه داده.
2. ارسال ماکت داده ها
3. دریافت تأییدیه از ماکت مبنی بر دریافت تغییرات (آنها «مدتی بعد» اعمال خواهند شد).
4. استفاده از تراکنش در موتور پایگاه داده
5. بازگرداندن تأییدیه به مشتری مبنی بر اینکه تراکنش با موفقیت اعمال شده است.

اکنون ما تغییرات را تنها در صورتی انجام می دهیم که تکرار شده باشند.

نتیجه

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

همین. می بینمت در دوره!

منبع: www.habr.com