Dev Perfects

Forwarded from Agora (Alireza)

اگر لندن یا آکسفورد زندگی می‌کردم الان تو راه پاب کلارکسون بودم :(
The Farmer's Dog

4 views17:49

Forwarded from Agora (Alireza)

مکانیزم Multi-Leader Replication و مصائب Write Conflict - بخش ۱
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ
نمیدونم چقدر راجع‌به مکانیزم Multi-Leader Replications توی دیتابیس‌ها می‌دونید. به‌طور خلاصه اینه که به‌جای این‌که یک نود مستر (Leader، Main یا هرچی) داشته باشیم که درخواست‌های رایت فقط روی اون serve بشند، چندین نود داشته باشیم که این کار رو برای ما انجام بدن. درواقع، Writeهایی که روی هر کدوم از نودها میان، روی باقی نودها Propagate می‌شن.

این کار یک‌سری مزیت داره، اولیش High Availabilityـه. اینطوری اگر یکی از نودهای مستر Fail بشه و به هر دلیلی نتونه به درخواست ما رسیدگی کنه، نودهای دیگه‌ای هستند که این کار رو انجام بدن.

مزیت بعدی Scalability و امکان Load Balancingـه. فرض کنید که تعداد رایت‌هایی که روی نود مستر می‌شه این‌قدر زیاده که I/O نمی‌تونه به همه‌ی درخواست‌ها جواب بده. تو این مکانیزم، ما می‌تونیم لود رو روی نودهای مستر دیگه که به‌طبع روی سرورها و دیتاسنترهای مختلف وجود دارند توزیع کنیم و Response Time رو بیاریم پایین. هر وقت هم که احساس کردیم این تعداد نود کافی نیست، می‌تونیم نودهای مستر جدید به سیستم اضافه کنیم.

با تمام این ویژگی‌های وسوسه‌برانگیز، اما هر آدم عاقلی شما رو تا جای ممکن از این‌که بخواید به این سمت حرکت کنید برحذر می‌داره. علت؟ پیچیدگی بالا و ریسک بالای Write Conflict و در ادامه Data Inconsistencyـه.

چرا این اتفاق می‌افته؟ فکر کنید یک Collaborative Editor درست مثل گوگل داک نوشتید. جایی که آدم‌های مختلف می‌تونن هم‌زمان با هم یک داکیومنت رو ویرایش کنن. یکی از سناریوهای محتمل که به ذهن خیلی‌ها حتما رسیده اینه:

توی خط اول داکیومنت نوشته:

Edited by Alireza

علی و رضا هم‌زمان با هم به داکیومنت دسترسی دارند و دارن این خط رو می‌نویسن. علی که می‌خواد این قسمت رو به‌نام خودش ثبت کنه، این رو این‌طور تغییر می‌ده:

Edited by Ali

درست همون موقع که علی این تصمیم رو گرفته، رضا هم برمی‌داره و اونو این‌طور تغییر می‌ده:

Edited by Reza

و هر دوی این تغییرات به سمت هر کدومشون ارسال می‌شه و اتفاقی که می‌افته اینه که:

درخواست تغییر علی قرار بود عبارت Alireza رو به Ali تغییر بده. وقتی رسیده سمت رضا، برنامه دیده که Alirezaیی در کار نیست که بخواد تغییر بده و فقط Reza وجود داره.
از طرف دیگه، وقتی درخواست تغییر رضا به کلاینت علی رسیده، خبری از Alireza که بخواد به Reza تغییر کنه نیست چون اون‌جا نوشته Ali.

این دقیقاً همون Write Conflictـه که راجع‌بهش صحبت می‌کردیم. همین مشکل دقیقاً تو سمت دیتابیس هم وجود داره. کلاینت ۱ درخواست رایت رو روی Node A ارسال می‌کنه. در همون زمان، کلاینت ۲ درخواست رایت رو برای Node B ارسال می‌کنه و هرکدوم از این نودها این رایت‌ها رو Propagate می‌کنن و باز هم Write Conflict.

برای رفع این مشکل چه کار می‌شه کرد؟ اولین و بهترین روش: پیش‌گیری! تا جای ممکن نباید سراغ این سناریو رفت. رفع کانفلیکت پیچیده‌ست و شما رو وارد یک Trade-off جدید می‌کنه.
اما واقعاً چه راهکارهایی برای این ماجرا وجود داره؟ چطور میشه حداقل در نهایت، به یک Convergent رسید؟

یک روش که احتمالاً به ذهن شما هم رسیده اینه که جدیدترین (آخرین Writeای که اتفاق افتاده) رو همیشه در نظر بگیریم. این یکی از روش‌های متداولیه که اتفاقاً توی سیستم‌های جدی‌ای مثل Cassandra هم پیاده شده (و تنها روشیه که به‌کار می‌ره). به این الگوریتم می‌گن Last Write Wins یا به اختصار LWW. برای پیاده‌سازیش، در کنار درخواست Write، یک Timestamp هم ارسال می‌شه. این‌طوری هر نود می‌تونه با مقایسه‌ی Timestampها آخرین رایت رو جایگزین مقدار قبلی کنه. مشکل این روش اما فدا کردن Durabilityـه.
این‌طور فرض کنید که توی چند تا کلاینت مختلف، به‌صورت هم‌زمان درخواست رایت ارسال شده و همه‌ی کلاینت‌ها فکر کردن درخواست اون‌ها موفق بوده. این در حالیه که فقط یکی از اون‌ها که دیرتر از بقیه ایجاد شده قبول شده و باقی در نظر گرفته نشدن. در سیستم‌هایی که هیچ‌نوع از دست‌دادن داده‌ای قابل پذیرش نیست، استفاده از LWW چندان مناسب به‌نظر نمی‌رسه.

روش‌های دیگه‌ای هم برای این ماجرا پیاده شده که می‌شه راجع‌بهشون صحبت کرد. ولی من تمام این‌ها رو گفتم که به این سه تا برسم.

7 views17:49