Data_Consistency
اول در این موارد بخون
- CAP
- BaSE
Synchronous = Strong Consistency
وقتی رپلیکیشن به صورت سینکرون انجام بشه، یعنی هر تغییری که روی Master ایجاد میشه، باید فوراً روی همه Replicaها هم اعمال بشه و تا زمانی که داده‌ها روی همه‌ی نودها نوشته نشدن، عملیات نوشتن کامل نمی‌شه.
🔹 نتیجه: همه Replicaها در هر لحظه دقیقاً یک نسخه از داده‌ها رو دارن.
🔹 معادل CAP: این روش به Strong Consistency نزدیکه، چون همیشه داده‌ها دقیق و یکسان هستن، ولی ممکنه سرعت و مقیاس‌پذیری رو کاهش بده.
🔹 مشکل: به دلیل این الزام، تأخیر بیشتری داریم، مخصوصاً اگه Replicaها توی دیتاسنترهای مختلف باشن.
Asynchronous = Eventual Consistency
وقتی رپلیکیشن آسنکرون باشه، تغییرات روی Master اعمال میشه و بعدش با یه تاخیر به Replicaها منتقل میشه. یعنی ممکنه یه Replica هنوز آپدیت نشده باشه و یه کاربر داده‌های قدیمی رو ببینه.
🔹 نتیجه: Replicaها ممکنه توی یه لحظه نسخه‌های متفاوتی از داده‌ها داشته باشن، ولی در نهایت با گذر زمان همه‌شون همگام می‌شن.
🔹 معادل CAP: این روش به Eventual Consistency نزدیکه، چون تضمین نمی‌کنه که همه نسخه‌ها همیشه یکسان باشن، ولی بعد از یه مدت همه سینک می‌شن.
🔹 مزیت: سرعت بالاتری داره و می‌تونه بهتر مقیاس‌پذیر بشه، چون نیازی نیست هر تغییر فوراً روی همه Replicaها اعمال بشه.
🔹 مشکل: ممکنه داده‌ها برای مدتی ناهماهنگ باشن، که توی سیستم‌هایی مثل تراکنش‌های بانکی مشکل ایجاد می‌کنه.
توی PostgreSQL یا MySQLمیشه از Replication Groups استفاده کرد و برای بعضی از جداول، رپلیکیشن رو سینکرون و برای بعضی آسنکرون کنی. تا توی یه کلاستر بشه جفتش رو هندل کرد